For several years I have worked on a number of different SDL Web 8 and Tridion implementations and on almost every single one I have wanted an elusive feature that is not available out of the box.
When you are preparing a website for content management, you invariably have to make a compromise between having style fields in the content schema metadata or in the component template metadata. There is a trade-off in either case because, if you put style fields in the content schema you’ll have to duplicate content for the purpose of styling – that’s BAD! However, the alternative results in potentially having LOTS of component templates for all the style variations. If you have fields for the block size, color, borders etc you can soon run into problems.
The solution to this would be to have the schema only model content and it’s metadata as intended. To have the component template metadata include instructions that dictate how it should be rendered. And to have style or theme fields on component presentation metadata – a structure that doesn’t exist until you combine a component with a suitable component template.
There is even a sensible place to curate these fields in the UI…
The component presentation metadata would feature as a contextual tab alongside the Component Presentation and Target Groups tabs and would be specific to the highlighted component presentation and stored with the component presentation in the CM data store.
Similar to how a component template can define it’s parameters schema or metadata schema, it should be able to define it’s component presentation metadata schema also so that the correct fields are presented accordingly. You might want different component presentation metadata for different component templates right?
This would require some architectural additions to the product but imagine being able to use an IComponentPresentation in DD4T or DXA to access the component presentation metadata with information about how to theme this particular template? The component template remains responsible for how it should be rendered but there is more information obtained when the content editor selected this component template to inform us how they want to use it for this particular occurrence.
This doesn’t break the way any of the concepts are currently applied or implemented but extends them with a new feature that would vastly improve the re-usability of components and/or component templates without limiting the flexibility in the rendering phase of content delivery.
We are often able to customize and extend the product with a wealth of excellent extension points from GUI extensions and CoreService APIs etc. However, because this would require some extension of the CM data store, it would be better suited as an extension to the core product opposed to a community developed extension.
Vouzamo's Blog 