Categories and Keywords on steroids

Requirement

Instead of maintaining many categories each with a limited set of keywords, the customer wanted to be able to use one category, containing a hierarchy of subcategories, each in turn containing the appropriate keywords.


In the Schema definition, for each field, that uses a category, it should be possible to select one of the subcategories as the root.  
When editing or creating a component based on this schema, the list of keywords should be limited to the keywords which are hierarchically below the configured subcategory.
When the field definition does not have a subcategory defined, it should use the default behavior, to show the full list of keywords for the category.

Implementation

To mimic the requested behavior, keywords are treated as a subcategory. By selecting a keyword, it will be used as the Root element.
This alternative Root is stored with in the schema definition, as part of the field description.
Each field can have its own optional root keyword definition.

The implementation of this functionality consists of two CM GUI extensions.

The Schema Editor contains an additional control which allows the administrator to select a Root keyword.
This control is only visible when "Values will be selected from a List" and "Category" are selected

The Component Editor is extended to be Root Keyword aware and generate and show lists limited by this new root as can be seen in the two screenshots below

 

Finally here is an example of how the definition is stored in the Schema

<xsd:element name="subCategoryPG1" minOccurs="1" maxOccurs="1" type="category:SuperCategory">
<xsd:annotation>
<xsd:appinfo>
<tcm:ExtensionXml xmlns:tcm="http://www.tridion.com/ContentManager/5.0">
<RootKeyword xmlns="http://www.tridion.com/ContentManager/5.0" Id="tcm:12-880-1024"></RootKeyword>
</tcm:ExtensionXml>
<tcm:Size xmlns:tcm="http://www.tridion.com/ContentManager/5.0">1</tcm:Size>
<tcm:listtype xmlns:tcm="http://www.tridion.com/ContentManager/5.0">select</tcm:listtype>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
Parents
  • The maintenance tasks saved would then include at least:

    - Creating a (new) Category versus a new "branch" in the existing category

    - Not needing to set a new Category to at least read for all users (since permissions are already set)

    - Slightly simpler synchronization across DTAP

    I think this means you also have trade-offs such as:

    - Higher chance for conflict between Keyword titles/names (which need to be unique, I believe)

    - Flatter granularity of permissions (and management) for managing these keywords

    I'd guess this would be a good fit for "system-wide" classification rather than Keywords meant to control editorial flow or display logic (e.g. checkboxes for navigational display).

    The closest editorial experience I could imagine to this without an extension would be to use the Tree view against a Category with nested keywords but the starting Keyword set as a default. The difference is it seems this solution wouldn't allow a user to select other "branches" of the "Super Category," right?

Comment
  • The maintenance tasks saved would then include at least:

    - Creating a (new) Category versus a new "branch" in the existing category

    - Not needing to set a new Category to at least read for all users (since permissions are already set)

    - Slightly simpler synchronization across DTAP

    I think this means you also have trade-offs such as:

    - Higher chance for conflict between Keyword titles/names (which need to be unique, I believe)

    - Flatter granularity of permissions (and management) for managing these keywords

    I'd guess this would be a good fit for "system-wide" classification rather than Keywords meant to control editorial flow or display logic (e.g. checkboxes for navigational display).

    The closest editorial experience I could imagine to this without an extension would be to use the Tree view against a Category with nested keywords but the starting Keyword set as a default. The difference is it seems this solution wouldn't allow a user to select other "branches" of the "Super Category," right?

Children
No Data