In the previous articles (https://community.joomla.org/gsoc2009/gartheeban-ganneshapillai/862-taxonomy-extension-design-spec-and-api.html and https://community.joomla.org/gsoc2009/gartheeban-ganneshapillai/831-architecture-design-taxonomy-extension-project.html) I outlined the scope of the project, design specifications and API. Following a lengthy meeting with the mentors we came up with the following timeline.
- Taxonomy API, as a Joomla! library : deadline by June 10th, buffer upto 20th…
- Written by garthee
The real user interaction happens here. Hence the following are important in design and organization.
- What information to be collected
- How much simple, or comprehensive
- Use of AJAX
- 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.…
- Written by garthee
The primary objective of classification frameworks is to decouple categorization from object creation and management and provide a human friendly, visually recognizable, flexible alternative to search indices of objects. Starting from directory architecture used by virtually any operating system, methods of classification have been in use for long time, under the principle of decoupling classification from creation, management, storage and identification of objects.
Taxonomy classification, and its currently popular variation - tagging are widely used in many web frameworks and desktops. Gmail started it with replicating a folder structure, with the concept of placing an object virtually into more than one bucket perhaps following soft linking that existed in file systems for decades.
This has been given a new look when web services like Gmail and Flickr adopted taxonomy classification for a very specific purpose of classification of only few selected objects. For example, we could choose to apply the classification or live without it. Later similar classification concepts have been adopted to desktop applications such as iTunes, Explorer in Microsoft Vista OS, etc and web frameworks.
Apart from classification framework's primary objective of decoupling the categorization logic from content management, we will focus on the following indispensable entities in a web framework - scalability, reliability, extensibility and usability. This must also take the frequency of operations into account in determining the crucial factors. Implementation specific details are discussed under design considerations.
Database is normalized to 3NF to ensure extensibility while being scalable. Frequently used queries like relationships, object mapping and leaf membership are designed to be scalable. Reliability is achieved through both hooks on different states of an object and vice versa and possibly through cron tasks.
- Leaf : The atomic unit of taxonomy labeling, that will be associated with the items to categorize them. Here it is referred to as terms and tags interchangeably. Leaves might be called by many similar names and we name them alias.
- Alias: For example, university and college may mean the same thing and it is redundant and misleading to have two different labels for a single term. Hence university can be aliased with college so that there will be only one term that is - university, and whenever user specifies the term college, it will be interpreted as university.
- Tree: This is an umbrella unit for leaves that act as a bucket and define the properties, rules and interaction of the leaves underneath. It will have the following properties
- Hierarchy : The type of hierarchy involved (refer structure below)
- Controlled: Whether leaves can be created outside the admin forms (com_taxonomy)
- Relations: what type of relations are allowed: Only parent-child relationship, or peer-to-peer as well.
- Tree mapping : Trees are useless unless it is mapped to an object manager, such as a component. A particular mapping involves a tree and an extension. Further it defines the following rules
- Required: Whether each object must be associated with a leaf from this tree under this association
- Multiple: Whether multiple leaves can be associated with a single object
- Weight: The factor that determines the priority for a tree when an extension is calling for all associated trees or all associated terms for an object under that extension. Heavier weights sink.
- Leaf mapping: Guided by the tree mapping rules and the properties of trees, a leaf is associated to an object coming under the extension given in the tree mapping. This is also known as labeling or tagging.…
- Written by garthee
I am an undergraduate at University of Moratuwa, majoring in Electronic and Telecommunication engineering. I am also a Web2 and PHP developer in my leisure time with a passion towards scalable distributed systems that embrace and empower Web2.0, and it has become a full-time activity recently. I expect to embark…