sh4nks/flaskbb — pull request #2 by RJacksonm1 (2013-10-15 19:11:49+00:00)
Title: Subforums

I noticed you were planning to implement the unread posts feature after the topic tracking feature, so I jumped ahead and made a stab at subforums.

I made some relatively large changes with this branch, so it might be worth discussing a few of them before merging it into your master. The most notable change is the deletion of the "Category" model, which is explained below.

Let's go over my notes from each commit, and explain the changes a bit further:

----

```
Remove Category model, replacing with parent/child relationships on the Forum class.

TODO: Top-level forums should be categories, but for now we have an explicit is_category boolean - this is because I'm not sure how to get the 'parent' form to contain a "Null" option. Once we can get a "Null" option in the parents list, we can replace the is_category boolean code with "parent is None" checks.
```

I was originally implementing subforums alongside categories, but I thought it seemed unnecessary to have both a 'category_id' and 'parent_id' field on the Forum model. Looking at the Category model I thought it doesn't do anything special that the Forum model does not do, and it's only their as a hierarchy object; seeing as the subforum code was hierarchy-related code I thought there would be relatively little harm getting rid of the Category model and just tweaking the Forum model to replace it's function, so that's what I did.

As the TODO in the commit's note says, the explicit `is_category` can be replaced with a comparison to None for parent. We just need to figure out how to add a Null/None option to the `parent` field for the edit/new forum form to denote "category" or root-level forum status. I was not sure how to do this myself.

On the topic of "category" vs "root-level forum" - I kept to the purpose of "category" by (with a later commit) adding validation so topics cannot be submitted to categories, however I'm not sure I see the purpose for that restriction. What is the harm in just allowing root-level forums instead of categories - i.e. removing the "no posts in categories" restriction?

----

```
Subforum-related template tweaks.

- Categories are now just interpreted as forums, there is no category-specific view.
- Forums on "index" view list their immediate subforums; same with subforums on "forum" view.
- Forum model has helper function "get_breadcrumbs", that navigates up through the parent hierarchy and returns a list of all the parents - top-most parent [category] first through to Forum's immediate parent last.
```

The first change simply means I got rid of the `category.html` and it's associated route in `forums/views.py`. I did this because the `forum.html` and `category.html` templates would otherwise share a lot of code - only being different in the `topics` section; this can be changed just by adding a check for is_category into the `forum.html` template (which is done in the cleanup commit).

The next change I worded kind of weirdly. It is basically meaning that each forum on the `index.html` template will display it's immediate children below it's description as "Subforum: 1, 2, 3, ..."; and the same for subforums on the `forum.html` template.

The final change was solving the problem that with subforums the breadcrumbs could have many parents to iterate through, and it would be tough to update those breadcrumbs via the template because Jinja2 doesn't support a `while` operator, and even if it did it would return results in the wrong direction. I solved this with a line of code under the forum view, but realised it would be needed elsewhere - so I moved it to the model as a helper function.

---

```
Cleanup subforum changes
Fix example data creating topics in categories.
Don't render "posts" table on categories, and hide the new topic button.
Added a check to new_topic that redirects requests away if the new_topic's forum_id is a category.
```

These are just some fixes to things mentioned above, that I did not think about when working on the bigger changes.