The real user interaction happens here. Hence the following are important in design and organization.

  1. What information to be collected
  2. How much simple, or comprehensive
  3. Use of AJAX
  4. Automation
  5. Other several usability factors

Secondly, this is a crucial point for Joomla!, as currently the implementation doesn’t seem to support injection of additional fields into the form from a unified point (similar to CCK in Drupal). However it is expected to be provided with Joomla! 1.6 core, and hence it will be considered.

Third is the ability to feed form fields from a centralized point. For example a component X is creating a form with few text fields. By calling a function (getTaxonomyFields) it should be able retrieve a set of form fields from our library perhaps in html form and inject into their form at any place it seems appropriate. Later on submission of the form,  component X extracts the relevant fields and call a function (replyTaxonomyFields) and return the variables. In Joomla!, even presentation and logic are separated into "html.php" and ".php", and I wonder  how we could achieve something like this abiding by Joomla!'s design patterns.


The taxonomy mapping with an item can be done through following generic ways.

  1. A single select box - suitable for Categories (refer to Popular Structures) with limited number of leaves
  2. Textfield -  This is fundation behind free tagging  where leaves are created on the fly (when a term doesn't  already exist in the database). User enters the terms in a comma separated list.
  3. Auto-complete textfield - Suitable for tagging, but requires some additional work, especially in AJAX request handling and finding the matching terms. Optional under GSoC terms, but greatly beneficial.
  4. Hierarchical select box - suitable for channels, where selection on the first select box with the leaves from the first level will bring the second select box with the leaves in the second level (eg: However the complexity involved may push this as a separate project and will not be considered.

Points of interaction

Firstly the user must be able to specify the terms while creating / editing an object, for example content item. But it is essential, that taxonomy framework be flexible and simple. For example, if we are to use taxonomy framework for user grouping, say with a tree called 'tuser' com_user we must be able to inject form fields into user edit form. This might seem illogical when there is already such a grouping feature. Hence it is the components responsibility of providing the suitable form fields as it sees necessary, and when taxonomy library is in core this can be easily enforced. However there are two caveats.

  1. Already existing components might expect a built-in solution, from taxonomy framework, and we intend to support com_content under this context.
  2. Maintaining a uniformity among all taxonomy components.  This can be streamlined by feeding the blocks depending on the structure or precisely the properties of the trees involved from a centralized location, preferably taxonomy library (refer to 3rd suggestion above). Form fields will be passed in an array form so that rendering component could decide its presentation, for example the size of the select box or text-field, and formatted html string, so that it could directly put inside the form. 

Second point of interaction is where the item is displayed. For example, for a content item, we may want to display the associated terms along with the content. If taxonomy framework is used under the structures of category or keywords, it is quite essential that it is displayed to the user. For a book structure the component might prefer to display along the breadcrumbs or headers. Hence, the disposition is the responsibility of the component, with the following provisions.

  1. Providing support for existing modules, especially com_content (refer to suggestion 2)
  2. Secondly maintaining a uniformity.  For example, depending one the weight given to each leaf (refer to Database structure) it will sink or float. The lighter ones will be listed first under this context. Taxonomy library will return an array and html formatted string (there are two options as for the previous case) which can be used for this purpose.

Potential for other plug-ins targeting the following features (beyond our scope)

  1. Automation - opencalais integration
  2. Better user interaction - ability to pick terms in a fancy way, and Wordpress achieves this to some extent.


 An MVC based, admin component to manage forms. I intend to follow this :  and chapter 5 of Learning Joomla Extension Development. Therefore I intend to skip Joomla! based implementation details on that.

Backend forms

An MVC based, admin component to manage forms. I intend to follow this :  and chapter 5 of Learning Joomla Extension Development. Therefore skipping Joomla! Based implementation details on that.

Suggestions: As user interaction happens here, I would like to have your suggestions or references on the use of ACL here.

  1. tree_edit: edit / add a leaf, and its properties
  2. leaf_Edit : edit / add a leaf, and its properties

Note : controlled taxonomies can add / delete leaves only here.
Note: creating a tree is a two way process. One in backend where you could set the properties that determines the structure of the final taxonomy tree that is built and completely manual, and the other is in frontend where it is partly automatict.

  1. List_trees_overview : list of trees
  2. List_leaves_overview : list of leaves
  3. Tree_maps_overview : list of mappings between trees and extensions. The mapping is to be done in coding behind the screens and the list is only for reference and not expected to be used to create such a mapping
  4. Leaf_maps_overview: list of mappings between leaves and extensions object, for example com_content's article.
  5. Taxonomy_settings: Page to  edit global settings on taxonomy framework

Note: it determines the ability to create a taxonomy tree and leaf from the frontend, what properties should be exposed and default values for hidden properties.

Front end forms

  1. tree_edit: edit / add a leaf, and its properties
  2. leaf_Edit : edit / add a leaf, and its properties
  3. List_trees_overview : list of trees
  4. List_leaves_overview : list of leaves
  5. List_content_overview: list of content for a given leaf

Potential list of other components or extensions of the taxonomy component

  1. List of terms from an encoded url. For example a url like ( ?option=com_component&leaves=+1,2,3,4,5-8,34,21) can be used to create an include / exclude list, and we could display a clickable list of leaves or even the list of objects they are maped to.

Taxonomy Library

Utility functions to be exposed through a singleton class.


  1. Do you think it is a good idea to separate two classes, Tree and Leaf and provide the relevant functions in separate classes?
  2. I was trying to figure out how hooks work in Joomla! Is there a special pattern? Can you give me a link for tutorial or example hook? I am used to a hook implementation by calling  functions with extensionname_hookname(), so that all extensions implementing that function got called as in Drupal
  3. Finally, I don’t see any practical use of making this abstract class, cause the functionality is clearly defined. If you have any Joomla! specific patterns to be followed please let me know.
  4. Is there an event that we can subscribe to do cron tasks?


It must be noted, that it is the implementing component's responsibility to call delete or update methods on the events of 'item delete' and 'update' and taxonomy library will not be listening to such events. On the other hand, they could choose to implement hooks such as hookLeaf to listen to an event associated.

Module taxonomy

Module can extend the user experience and explained earlier in the proposal and other documents earlier. (beyond the scope of GSoC)

 Example list of potential modules

  • List of similar items by comparing the matching terms.
  • Tag clouds
  • Taxonomy menus
  • Faceted browsing
  • Exhibt
  • Cumulus