Content and presentation separated – part 2

Following up on my previous post about content and presentation separation , I realized that separating presentation and content is extremely important, if you want to utilize some of the new features in Sitecore such as the page editor and the new rule engine . These features let the end user meddle with the presentation which gives quite a few nice features. For instance an editor can add a rendering to a given page in a rich and intuitive GUI and set up rules for a visualization of a certain rendering.

The problem, as earlier discussed, is what to do with “presentation content”. With presentation content I mean settings or similar. For instance take a rendering where you want to present a list of news, which are all descendants of a specified root item. This rendering needs the following settings: How many news items to show, a root item, a read more link etc. Normally I would put these properties on a template as fields. However this would bind the presentation to content and the sublayout or rendering would only work on an item, which is derived from that template. As the end user can now meddle with the renderings and add or remove them at will, he will have to know the dependencies to different templates, which is practically impossible. 🙂


So what is the solution to this problem? Well as fare as I can figure out, you need to use the datasource and parameter properties on the rendering instead. However this introduces some issues when it comes to usability, as it is now the end user who needs to set these properties. Sitecore has a really rich and user friendly interface for altering content, but for some reason the UI for setting properties on a rendering/sublayout is rather hopeless. There is only one field type – a simple text field. So when you need to set an external or internal link you need to enter it as simple text. No lookups, nothing. Further there is no way, to my knowledge, to create validators for these fields, so you aren’t able to help the editor.

So for this to work Sitecore needs to implement a better UI or use the content editor to allow editors to configure renderings. I sort of figure it would be quite nifty, if there was created an item, whenever you add a rendering. The item should be based on a specific template for the rendering type, which would mean you could create different templates for different types of renderings and thereby control which parameters would be needed. This should be completely transparent for the editor, which wouldn’t notice that an actual item was created, except he would get the user friendly interface of the content editor.

This would give better usability and thereby allow a better separation of content and presentation (and the content needed by the presentation).


The end user issue doesn’t stand alone. Recently I implemented a sublayout, which should read some parameters. If I have done this in a best practice way, I must admit, that the API for reading parameters is completely hopeless. Check it out on SDN. What? Is this really the easiest way? Further the parameters data type is a concatenation of strings much like query parameters. This is quite frustrating as you have to parse the string or use the .net UrlString class to extract a specific parameter.

Adding all this together and adding different validation of the parameters made my class turn into one long unreadable mess.


The conclusion? If you want to separate content and presentation you lower the capabilities and usability for the editor and make your code one big mess. Either that or I am doing something completely wrong.

If Sitecore really wants the editors to meddle with presentation, they should really improve the UI and API for sublayout parameters and similar.


6 thoughts on “Content and presentation separated – part 2

  1. commodore73 says:

    > the API for reading parameters is completely hopeless.

    If I understand correctly, you can use something like this to get the parameters and data source passed to a sublayout:


    You can either use it as a helper, or your sublayout can inherit from it and all of its properties are set automatically. I think this currently has a bug (logic in constructor should move to OnInit because this.Parent is null in constructor – I’m not sure how this ever worked, so possibly a change in the dynamic response engine). I will try to get that SDN page updated.

    Sitecore 6.1 introduces parameters templates, which let you use Sitecore data template definitions to control the presentation Control Properties dialog for each control. This makes it a lot easier for a user to enter parameters. You could also store the parameters as fields in the item instead of layout details, and just retrieve those field values in code.

  2. Bo Kehlet Jørgensen says:

    You’re completely right, it sucks and as you’re pointing out it’s getting worse. The new upcoming OMS add-on and the new Rule engine uses renderings for adding rules, tracking and god knows what.

    I’m trying not to use the page editor simply because it’s not user friendly. If I’m not using it I’m missing out on the cool new stuff, but then again no editor can figure out how to use it anyway. Yes, it needs a new UI.

    Anyway, I still don’t know if I’m fond of items getting unique when adding a new rendering to it???

  3. One thing to notice is – despite parameter templates et al – that content/presentation separation comes at a cost to the customers. We partners will in the future spend more time setting up the ability for editors to configure the presentation. A configuration option most customers will want – mainly because of OMS. My bet is that we are going to have a hard time explaining the additional cost – especially because of the Sitecore out-of-the-box rethoric.

  4. @commodore73: Untill now we mostly define parameters as fields on the templates, but this doesn’t allow the editors to add renderings and layouts dynamically to everysingle type of template. I think it is unrealistic to expect the editors to know which templates they can add presentations.

    @Bo: I agree with you. It is not nice to place renderings on items. It will add additional costs for maintaining the solution. A cost which is rather hard to explain customers. However I am getting more fond of allowing customers the option on specific pages like the frontpage. This needs to have a very dynamic presentation, which the editors want to be able to modify, so it may be needed on some solutions.

  5. Pingback: Looking forward to Sitecore in 2010 « Molten Core

  6. Pingback: Looking forward to Sitecore in 2010 | cmsnewstoday.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s