A Missing Field Type - Part 1

If you haven’t read my post from last year about Sitecore’s Items, Fields, Versions, and Languages I would recommend that you do it first. In this post i will make an argument that Shared, Unversioned, and Versioned is not enough and we need another field type - Workflowed. Even if only for one particular field.

Shared

Shared fields are very basic. Value of a shared field has no language variance and no history. It cannot be workflow controlled and it cannot be restored to a previous value. You probably rarely use them on content items managed by the authoring teams exactly for the reasons outlined. You will find them, however, on the Standard Template and throughout the Sitecore internals in general.

Things that are inherently global and stable, things that an item either has or doesn’t have, things that never vary across translations, things that don’t change how an item is rendered - these are the qualities of a shared field. Good examples - __Is Bucket and __Enforce version presence. Bad example - __Renderings.

Unversioned

Unversioned fields are rare these days. Value of an unversioned field will differ across translations but it still has no history and no workflow support. Same qualities as Shared basically plus a per-language variance. An attribute of an item has to be textual or otherwise different per language and yet be global and stable to warrant an unversioned field. Good example - __Short description from the Help section.

Versioned

The bread and butter of content items. Supports language translation, has history, and is subject to a workflow. What’s not to like? The majority of the fields you create should be versioned. Well, at least they should have history and workflow support and what other choice you have then, right?

Having both language and version angles can sometimes produce friction. You can have former without the latter (the Unversioned fields) but not the other way around. If you need history and workflow - and you do almost always need it - you have to also deal with the fact that each language translation has its own value.

Workflowed

I feel that we need one more field type. Unversioned fields add the language (translation) dimension to the Shared fields. Versioned fields add the version (history and workflow) dimension to the Unversioned fields. What if I wanted history and workflow support without language variance? What if there was a Workflowed field type that was subject to a workflow and supported history rollbacks but didn’t have the language angle? Basically, a version dimension added to the Shared fields.

A field without a language angle represents something that is the same across all translations. If you use Shared field type you subject yourself to accidental publishing of new values while everything versioned is still in the draft state. If you use Versioned field type you have to maintain the same value for all translations contract.

Why is it a problem? Next time on this blog. Stay tuned for Part 2.