Category tree

[sveetch]

Is your feature request related to a problem? Please describe. There is only a single level of categories.

Describe the solution you'd like Category could have a parent category and so a category could have many category children.

This would result to a tree of categories. It is very basic to implement in model but more difficult to implement well in rendering and views.

We will need some performant enough code to render a category tree without making too many big querysets.

Did Category URL will have to consume multiple name to get a high URI ? This would need to validate every category name for correct relationship. Like for "Camembert" category, with parent category "Cheese", the url could be /cheese/camembert/.

There may be some missing points for this subject yet.

[sveetch]

I think since tags features is on the way into a 0.5.x release, multiple categories in an article become counterproductive, especially with category tree where the multiplicity will lead to very complex queryset.

Also there is a question about the article listing from a top category should be recursive to its children or not.

[sveetch]

The article listing should not be recursive into category children, such as "Cheese" only list its direct article and not the ones from "Camembert". However, a convenient method may exists to recursively retrieve all article from a category and its children, but it would be only for further specific usages. The category tree feature may be released without this.

[sveetch]

Work is on the way for this on branch category_tree.

django-treebeard has been chosen to manage parenting instead of simple foreign key to avoid performance issue with querysets about parenting because simple foreign keys would lead to as many queryset as they are items in the tree, instead some tree management like with treebeard just need one and have better method to navigate in tree.

However treebeard is not something easy to implement and we also have many things to manage aside because the parenting tree is almost creating a new tree structure aside the translation one. Basically the two tree cannot collaborate in content display, we will only be able to display parenting tree when we are listing only a single language at once.

Admin todo

We will have to adapt queryset related to category but first treebeard parenting management have to be done in admin so we are able to continue on front usage.

• [x] Add django-treebeard to requirements and install into sandbox;
• [x] Add treebeard use on Category;
• [x] Fix tests that may fail because of new Category fields;
• [x] Add 'parent' virtual field on admin form to manage parenting (we cannot use the shipped admin list from treebeard since of multiple languages, it have to be done only in the detail form for now);
• [x] Clean 'parent' value to avoid breaking constraints: parent is always on the same language, when changing language it must be checked again possible current parent language and select category cannot be a children of current category;
• [x] Excludes possible current category children from 'parent' field listing (parent selecting its child as parent lead to broken tree and orphan circular reference);
• [x] Add proper test around parenting behavior cases;

Front todo

• [x] Keep Category detail url with the short direct slug url, the detail url for children won't include all the categories path (aka Cheese > Camembert won't be /cheese/camembert/ but instead /camembert/);
• [x] Opposed to the URL, the breadcrumbs should include the full category tree path;
• [x] List view will only display the root categories;
• [x] Children category will be listed from their parent category detail;
• [x] Article detail display still be unchanged since it won't need to introduce tree, it still just list its direct related categories if any;

API todo

API should still work well without anything more but the parent and children should be displayed in Category detail.

[sveetch]

Done in v0.9.0