Don’t Fight The Framework – Sitecore Presentation

So, continuing on the theme of the previous posts, in particular Don’t fight the framework part I I thought it would be a good idea to cover the presentation side of Sitecore in a little more depth, with a particular focus on how bad decisions can affect implementation in the future. I chose this topic because from day 1 (as an umbraco and e-commerce developer and beforehand) it has been my belief that one of the most important part of any system is the users (lets face it – fantastic architecture with a crumby user interface means its only the dev’s that use the software – did someone say Oracle).

I could probably write another 10 – 20 posts just on the subject of the presentation side of Sitecore, but I have tried to distil some of the key points for this series and in particular the common pitfalls and/or lack of knowledge that leads us to make bad decisions (as with all these sorts of posts – of course – I too have been guilty).

This is one of THE most important dialogs in Sitecore:

presentation

In order to do this I am first going to run through the elements I will be talking about with a brief description of what they do and some of their basic pitfalls (if any).

Data Sources
Data sources are simple – they are a link between your presentation component and a single item (or in the case of SC7 forward potentially a query) that allows you to retrieve content from Sitecore which the user has specified is in some way important to the control. Think of it as such – a Call to Action might well need a global item, an image control – an image, a small news carousel – a root news item upon which we can get its children as the cause for display.

I like to consider datasources as a form of dependency injection for our renderings / sublayouts (as are rendering parameters – but different use case).

Firstly – make sure that they are setup correctly and the template type is correct.

A big gotcha with Datasources though… in many versions of Sitecore they have been implemented based upon the item path, change the item name or location and you risk breaking the link (though I believe this might be fixed in late versions I still haven’t gotten around to checking).

Rendering parameters
Rendering parameters are in essence a bunch of name value pairs that are associated specifically to the instance of the presentation you are using, you can (as you will see in parameter templates below) use these to define content in an extremely similar manner to Data Sources above.

Rendering parameters have a similar use case to data sources with a few differences.

  1. As it stands at present, you cannot personalise rendering parameters using Conditional Renderings the out of the box functionality (maybe the rules engine can do it – but it needs investigating.
  2. Rendering parameters are stored in the form of a querystring style string, as such – I wouldn’t recommend using them for Rich Text fields (see rendering parameter templates – below), this also means you have to deal with is as string values, not field types

Parameter Templates

Ok – so – following on from rendering parameters, we can utilise rendering parameter templates to give rendering parameters a more user friendly UI than the default name value pair that the default parameters use. They are however stored in the the same place and as such subject to the rules above.

In order to implement these – you simply need to create yourself a template inheriting from [ path to rendering base ] and set it as the ‘Parameter Template’ on the rendering / sublayout definition item. As with all items, remember that you can inherit from your new template to change standard values and you can duplicate your rendering definition to utilise different rendering parameters. This allows you to create independant ‘Auto rotate gallery’, ‘User Gallery’ and a’Triple Item Gallery’ utilising the same actual code.

Placeholder Settings
These allow you to control in short… what can go where. I will likely write a further post on this as a whole as I found the information on this subject not forthcoming and its kinda glossed over in many instances.

And on to the main event!

Ok – so sure – this has been a whirlwind refresher (or introduction) to the basics of Sitecore presentation, now lets consider in the context of how it has / will be implemented in Sitecore, again with a focus on use cases.

Static sublayout / renderings
I see this one a lot – some solutions I have worked on have like 2 – 3 sublayouts defined in the presentation settings in total per page. This (in my opinion) is not the best way of looking at Sitecore solutions, and I’ll explain why.

Whilst there are notable exceptions to this, the general state is as follows: anything you add as a static reference to a sublayout or renderings forces you have to perform a release to change, anything you put in Sitecore you can manipulate easily. Standard values, layout delta’s are all available to you all the time. If you for example, opt to add your header / navigation ( or as I have seen – the breadcrumb ) as a hard coded sc:sublayout (or the MVC equivalent), then what happens when you come to develop say – your homepage – where often these days you have different navigation? If you use dynamic presentation this problem disappears, and if you never ever use different presentation – no harm done – you have only had to go through the extra pain of creating 1 Sitecore item and setting the standard values on a low level template – a worthy trade off for the future flexibility it provides.

One of the biggest complaints I find from corporate clients is that they will ask ‘Can you just change the copyright text?’ (or any other seemingly simple change for that matter. If you have followed the approach as we have described in this series (building using Dictionaries / and dynamic presentation in particular), then one of the most satisfying things to be able to respond with as a developer is – ‘Sure, and so can you’ – with a big friendly developer smile (trying not to be smug).
Flip this on its head, and hard code values in your sublayouts / renderings or the reference to the rendering itself then you are often forced to say ‘I can, but I will need to fill out a change request, pass it to the guys in systems, create a package and inform the business of downtime..’
Time is money to your client just the same as it is to you, and the frustration of waiting 2 – 3 weeks for UAT, the DBA’s, the Systems guy who’s on holiday & his wife’s cat’s vet appointment, leads again the client to question why
they chose Sitecore – since it’s (in this instance) not really any better than a straight MVC implementation and has no doubt been a lot more expensive. Add to this, once an opinion is in the clients head – for example – ‘it always takes my (developer / vendor – delete as appropriate) like ages to do the simplest of changes’, you will probably find it a difficult opinion to change.

Standard values apply to presentation too
All to often we use standard values to control both presentation and values for our newly created items. I am personally of the opinion that you can create versions of your templates SOLELY to control their presentation. Take a ‘News Article’ it’s perfectly feasable that you might want to create an inherited ‘Press Release News Article’ which has a particular call to action by default. This also provides other benefits when looking at selecting items from Lucene from example,
its very very common as a solution to attempt to retrieve all items with that derive from ‘News Article’ template (see my previous post on not [ Template Inheritance ]) and particularly also retrieve all items derived from ‘Press Release’ with the ability to interchange these use cases at will.

I have seen many solutions where additional fields are used to support presentation, but its much rarer to see additional templates to support the presentation.

Note though – once presentation is changed on an inherited template, it is a COPY, they do not use Layout Delta’s to maintain it. There is a blog post floating around the internet to attempt to correct this, in my experience, it carried issues and is also potentially (in my opinion) a step too far.

Use data sources over rendering parameters
This is a quick point, in short, data sources come with some powerful features out of the box in Sitecore, notably the ability to Personalise using Conditional Renderings. With rendering parameters this is more difficult to do (by no means impossible)
So – generally, if you need

Avoid spaghetti logic
In short, if you find yourself doing something like ‘if(item.TemplateName == ‘fred’){}else if(item.TemplateName == ‘harry’){} then you should think again ;).

Renderings are items too
Try to remember to think of renderings, rendering parameters as actual items in Sitecore, not things on screen. They support inheritance just the same and as such, you can easily create multiple renderings / sets of parameters with subtly different behaviours simply by manipulating Sitecore.

Set up your renderings / sublayout items correctly
We as developers usually have admin rights on our Sitecore installation, the user does not, try to ensure that you have given the user the ability to select what they need to from the locations in Sitecore that they need to without having traverse too much in the tree if possible.

The Page Editor has feelings too!
Ok – so, those who have been working with Sitecore a while, we like the Content Editor – its (mostly at least) our friend. As we have gone on – we have become a little more used to Sitecore Rocks maybe. Again – this deserves a post
in it’s own right, and it will probably get one in time – however…. In part following on from Pt IV and in part new, the number of times I have found developers ignore the page editor experience altogether is untrue. Sitecore have
given us so much to make life easy – especially post Sitecore 6.6 with the additions they have made to the page editor experience. So in this I will cover off just a little of the types of things that get missed.

  1. Fields that cannot be seen – this is usually the likes of Page Meta Data, the Page Title, Tagging etc. The easiest way I have found to make this happen is simply to create a control that is hard coded into your layout (good use case
    for hard coding) that does not display if the page is not in edit mode. Within this control, simply add the relevant Sitecore presentation controls (be it from MVC rendering or sublayout).
  2. Repeating content – this is often the likes of an FAQ section with children. Consider the fact that users will want to be able to add new content, move items up or down, remove items etc
  3. As spoken about in [ Pt 4 ] the users will probably want to be able to change things like ‘To search, please do something and click go’. You should implement some sort of dictionary system to allow for this (and globalisation ideally)

More than anything though – forget these kind of simple points and it probably lead to the users abandoning the Page Editor and probably leave them feeling short changed on the Sitecore solution they felt they were sold.
As far as I know, the page editor is here to stay, and when implemented properly can make your Sitecore solution a pleasure to work with and lead to happy customers.

Setting up placeholder settings
This deserves a [ post ] in its own right, but in short, key tips here are simple, you can be as granular or widespread as you like, for example, you can set the placeholder key for the settings to take place globally, or you can
specify no placeholder key and use the placeholder settings section of the dialog (particularly on the standard values). In my experience (quite a few big name sites now), I have found that it pays to think of placeholder settings
as groups of allowed controls etc rather than ‘these controls are allowed in this placeholder. Too often in sites I used to find myself changing 5 sets of placeholder settings cause the user would now like to add a call to action or
sponsored article control to the main section, but in our infinite wisdom, we had implemented it based on key. So then the ‘Partner’ page has a subtley different key to the ‘News’ page and the ‘Content hub page’ cause we have been
trying to be helpful. Its in many cases much easier to think of this in terms of a set of placeholder settings called ‘Main Section’ that you apply using standard values.

I guess the closest thing I can liken the approach to is my approach to CSS – The more global you define things (define something for a{} or .classname{}), the more likely you are to have to override for edge cases. Sometimes the widespread approach
suits, sometimes it pays to be a bit more granular, I have started to err on the granular side more and more often.

Conclusion
In keeping with this series title, you can already see how much the MVP framework decision may have hurt your solution by missing out in all of the powerful out of the box features that Sitecore gives you. Even if this isn’t the case,
things like the decision to use rendering parameters when you need to personalise, spaghetti logic when you could implement using a data source or rendering parameters means that you could be introducing design smells at a presentation level.
With this in mind, you could well argue that this is possibly where you as a developer should spend most of your effort – not your code (though that is important also). The better the Sitecore presentation the likely better Sitecore solution.

Related Articles

This article is part of the Don’t Fight The Framework Series

Advertisements

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s