This feature proposal covers a lot of feature requests, coming from you in the support forum but also from Enterprise customers.
I am talking about Taxonomies
What is a taxonomy?
As a developer I have never used this term before but I have found several other products and competitors which use this term, so it seems to be a common concept in the field of data and content modelling. It basically the classification of things, that is typically defined in a hierarchical way, for example:
Here are examples of their usage:
- Content releases: Group your content items as they are to be published in upcoming releases.
- Projects: Organize content in projects and subprojects.
- Business-specific categories: Product categories, colors, localities.
- Website hierarchy: Use taxonomy to represent your website hierarchy and assign content items to their locations in the hierarchy.
Especially the last hierarchy is often used in web development.
Do we really need it?
This is a difficult answer, I would say yes and no:
- We can already model taxonomies and parent child relationships with references.
- We can already model simple taxonomies like colors with tags and “allowed-values”.
- References do not model any hierarchical relationship and restriction.
- Some features cannot be implemented when the hierarchy is not know, for example a reference selector that works like a wizard, where you first select the continent, then the country, then the city and so on.
For now I will formulate this very basic requirements:
- Define unlimited number of taxonomies per app.
- Taxonomies can be defined with a schema hierarchy or constant values.
- Products can be part of multiple taxonomies.
How to define taxonomies?
Taxonomies have a name and are defined in a tree like structure, e.g. level can be either a schema or a constant value.
When we have an example like localities we can use a mixed value where we just use constant names for the continents and then we define that a you can attach countries to continents and cities to countries. This reduces the number of schemas and content items, especially when we only need them as categories or to be referenced by other items. But can be problematic when you need to convert a constant name to a content item.
In other examples like product categories, we are probably fine a with a set of discrete values, for example
- Colors (red, green, blue, white, black…)
- Sizes (S, M, L, XL…).
How to work with taxonomies
You basically get a sidebar with the taxonomies, where you can switch between taxonomies and assign content items with drag and drop: