Currently, dotCMS has the concept of variants in another form - as languages. In fact, you could almost just run with our language functionality and use it to provide persona-ized content. We need to expand the concept of languages to include other variations of content such as “Mobile Friendly” or “European Visitor”
Variants are like branching in a VCS - only the content that is changed for that variant needs to be persisted and you can only “branch” from a root branch. See variant hierarchy below.
Additionally, we build a tool to merge one variant with another branch. What this means is that editors can create lightweight variants that can act like change sets and be merged into the main branch when the editors are ready to publish.
A site visitor can only have one variant, which gets overwritten when the visitor actions match another ruleset or the view_token is passed in via url
Variant Editor / Creator
Simple Crud interface
view_token - varchar - a token that can be passed in via url to change the variant.
small_icon - binfile to represent the variant. Think language flags. Can be stored in the db
big_icon - binfile to represent the variant. Can be stored in the db
Variants should be a permissionable, I believe. This will be important when leveraging them for VCS. An editor can only see/manage the variants they have access to.
Site Editors will be able to select what variant they are viewing a page as (just like we do with languages). We will need to remember the last variant they were viewing as and keep that value in session and use it wherever appropriate, like the content search screen.
When editing content and a the user wants to make a copy for a personalized “variant”, they just select the variant from the drop-down list (just like languages now). The system asks if they want to copy the content (from the variant they were previously viewing) and away they go.
To discuss - potentially content inheritance is going to be too error prone and we should avoid. By content inheritance, we mean:
You have a piece of News content for the main site with a title called “Baby Monitors for a Smart Nursery, but Parents Are Still Better.” among its many properties. A user selects that and chooses to make a mobile variant of the article and chooses to only overwrite the tile to a shorter mobile friendly “Smart Baby Monitors Suck” or whatever. When that piece of content is retrieved, it has all the properties of its parent article but has the overwritten title and when an editor updates the news story on the parent content, it would be updated in the mobile version as well.
We can always come back and do this when we improve the content model.
(If we can do away with this, fine. If we need to make it multilevel, fine)
Two level hierarchy - Root level and their children
Children cannot be specified as the parent of another variant - only variants without parents can be parents.
We will still need a “Default” variant if none is set. Can be set in config - no UI