[33]Section/Category Manager
Posted: Sat Feb 16, 2008 1:53 am
1. Introduction
1.1 Scope
The scope of this document is a first draft of a change to the section/category system to normalize the database structure and simplify the usage for the users.
1.2 Objective of the document
The objective is to give a basis for a discussion about the described changes to the section/category system in Joomla! 1.6.
1.3 General remarks
1.4 Definitions
1.5 License
GNU GPL
2. What is the current issue?
The system of Section and Categories is not flexible enough and as long as we don't move to a node based scheme, we have to cope with the current idea behind this.
For new users the system of a number of sections and categories in a flat structure is fairly complicated to grasp. The system for handling both these concepts is also unnecessary complicated by providing two components to administrate them and by a lacking graphical representation of the structure.
The other problem is the description of the sections and categories. The system provides the possibility to add descriptions to the head of the overview pages, but these descriptions neither save who wrote them, nor when they were written and they are not parsed by the content plugins.
3. What are the proposed improvements?
The improvements are three fold:
3.1 Interface improvements
The interface to configure the sections and categories should be merged and more represent the tree like structure that is behind it. To improve the overview, the categories should be hidden like the tree structure in the Windows explorer.
When creating new sections or categories, the screen allows to select either to create a section or to select the section the new category should belong to. The description should be removed from that screen, too. Instead of that there should be an optional button to add a description.
3.2 Normalization of the database scheme
Instead of saving the description in the section or categories table, the tables should just be linked to the content table, which allows to use com_content and normal articles as description. This allows for a smaller interface in com_section and com_categories, and editing descriptions and articles would happen in the same place, as well as the handling of the description could be done the same way as articles in com_content. In com_categories and com_section, a button would be added "Add description", removing the editor field below.
3.3 Parameters for categories
The database table has a field for parameters for categories, too, which should be used. Currently the functionality for parameters for categories and sections is not implemented.
4. Technical realisation
4.1 Interface changes
Besides the obvious changes, it should be possible to access the category manager the same way the configuration manager for third party extensions is used.
For the graphical changes, see this example using mootools: http://madhatted.com/2008/1/11/the-joy- ... table-sort
Also, maybe with the use of ajax and a small interface, the whole editing/new screen could be saved.
4.2 Normalization of the database scheme
For the normalization of the database scheme, we reuse the description field in #__categories and #__sections to hold the ID of the article in #__content. In #__content a row is marked as being a description text by adding a 1 to the field parentid for a section and a 2 for a category.
4.3 Parameters for categories
The category manager reads an XML file in the extensions directory. To define different kinds of XML parameter files, a new URL parameter is added. The rendering of the parameters is done via the normal functions of JParameter.
5. Intention
The interface for categories and sections should become simpler and more flexible.
6. Effects on...
6.1 Users
The negative effect on the users will be, that they will have to learn a new interface. However, the overall usage should be simpler through this.
6.2 Effects on 3P extensions
Third party extensions will have more flexibility with the new set of parameters available for them. It should be payed attention to backwards compatibility here.
6.3 Effects on Performance
There should be no negative effects on performance.
1.1 Scope
The scope of this document is a first draft of a change to the section/category system to normalize the database structure and simplify the usage for the users.
1.2 Objective of the document
The objective is to give a basis for a discussion about the described changes to the section/category system in Joomla! 1.6.
1.3 General remarks
1.4 Definitions
1.5 License
GNU GPL
2. What is the current issue?
The system of Section and Categories is not flexible enough and as long as we don't move to a node based scheme, we have to cope with the current idea behind this.
For new users the system of a number of sections and categories in a flat structure is fairly complicated to grasp. The system for handling both these concepts is also unnecessary complicated by providing two components to administrate them and by a lacking graphical representation of the structure.
The other problem is the description of the sections and categories. The system provides the possibility to add descriptions to the head of the overview pages, but these descriptions neither save who wrote them, nor when they were written and they are not parsed by the content plugins.
3. What are the proposed improvements?
The improvements are three fold:
3.1 Interface improvements
The interface to configure the sections and categories should be merged and more represent the tree like structure that is behind it. To improve the overview, the categories should be hidden like the tree structure in the Windows explorer.
When creating new sections or categories, the screen allows to select either to create a section or to select the section the new category should belong to. The description should be removed from that screen, too. Instead of that there should be an optional button to add a description.
3.2 Normalization of the database scheme
Instead of saving the description in the section or categories table, the tables should just be linked to the content table, which allows to use com_content and normal articles as description. This allows for a smaller interface in com_section and com_categories, and editing descriptions and articles would happen in the same place, as well as the handling of the description could be done the same way as articles in com_content. In com_categories and com_section, a button would be added "Add description", removing the editor field below.
3.3 Parameters for categories
The database table has a field for parameters for categories, too, which should be used. Currently the functionality for parameters for categories and sections is not implemented.
4. Technical realisation
4.1 Interface changes
Besides the obvious changes, it should be possible to access the category manager the same way the configuration manager for third party extensions is used.
For the graphical changes, see this example using mootools: http://madhatted.com/2008/1/11/the-joy- ... table-sort
Also, maybe with the use of ajax and a small interface, the whole editing/new screen could be saved.
4.2 Normalization of the database scheme
For the normalization of the database scheme, we reuse the description field in #__categories and #__sections to hold the ID of the article in #__content. In #__content a row is marked as being a description text by adding a 1 to the field parentid for a section and a 2 for a category.
4.3 Parameters for categories
The category manager reads an XML file in the extensions directory. To define different kinds of XML parameter files, a new URL parameter is added. The rendering of the parameters is done via the normal functions of JParameter.
5. Intention
The interface for categories and sections should become simpler and more flexible.
6. Effects on...
6.1 Users
The negative effect on the users will be, that they will have to learn a new interface. However, the overall usage should be simpler through this.
6.2 Effects on 3P extensions
Third party extensions will have more flexibility with the new set of parameters available for them. It should be payed attention to backwards compatibility here.
6.3 Effects on Performance
There should be no negative effects on performance.