Over the years I have been involved in my fair share of “rescue” projects with Sitecore with the most common of issues being projects that do not adhere to the standards and best practices of Sitecore.
One of the biggest complaints I hear is the lack of complete Page Editor functionality and components not being testable. Sitecore themselves make it their business to push personalisation and this is one of the key selling points of the Sitecore platform and goes some way to justify the license costs. That said, the lack of adhering to best practices may work for some (ensuring the quickest turnaround time) however later on down the line this will unravel when clients wish to utilise “out of the box functionality” that Sitecore provides.
Also, I’ve heard worrying phrases such as:
They haven’t been shown that or told to use that feature of the Page Editor
They don’t or shouldnt use it like that
or even worse
I can’t see this ever needing to be tested or personalised
Two things I normally advise with in these circumstances:
- Never make assumptions on how a client with use the Page Editor. Whilst they may not wish to use its functionality now, they may wish to utilise it in the future – so why make these assumptions in the first place?
- There may be a future possibility that the client will employ someone who is well versed in Sitecore who wants to begin to utilise the out of the box features of the Page Editor. Wouldn’t it be embarrassing if they clicked the “Set Associated Content” button in the Page Editor on a component and were unable to create a new Datasource to see what it would look like with different labels? (this is built-in, every component should support this)
Fortunately the above can easily be addressed by ensuring that Sitecore’s best practices of using Datasources for almost everything (unless its Presentation Configuration, in which you may wish to consider Parameter Templates). In fact, I rigidly adhere to Datasources unless there is a good and valid case not to.
Common Problems with components:
- Not abiding to a Datasource at all – Components who get all of their data from the Context Item (which will be the Page). Bear in mind that the Context Item will be the Page – which normally means that there is a lack of separation of Site Information and Page Content.
- Hard wired Datasources – the data for a component is pulled in via a link directly to a Content Item. The issue with this is obvious, if the Datasource is recreated it will be assigned a new ID, hence the code that utilises it will need to be updated.
- Not restricting Datasources – Allowing “any” item to be bound as a Datasource that does not contain the correct fields that are expected by the component. Whilst the component might work, the Content Editor could break a component by assigning an inappropriate Datasource.
- Inappropriate usage of Datasources – Using Dataosources that contain “too much information” i.e. a Global Item that is bound to the majority of components, or a component that takes data from multiple content items – making if difficult to personalise the component as DMS is only capable of taking control over the Datasource (remember, we should be in the habit of allowing ALL components to be personalised – it’s no extra work!)
To address the above, I normally create a base class that contains a DataSourceItem property. This is then bound to the Item property of all the Sitecore controls on the page. This means that the component doesn’t care where there Datasource is being set as that’s not the concern of the Component. All the component should care about is that it is “given” data by Sitecore.
I have an example of a base class that can be used on GitHub in my Sitecore Toolbox Project:
When creating the Sublayout in Sitecore I always ensure that each component is coupled with its related Datasource Template (it’s a good idea to create the Datasource Template first to prevent bouncing from Sublayouts to Templates to create the Datasource Template and back to Sublayouts to assign it to the Component). This ensures that the data that is passed to a component is known by the component (and developer) and prevents the scenario where the component has to make a call to a different Content Item in Sitecore for its information (i.e. the component needing to be knowledgable about your IA).
Coupled with this, it is important to specify Datasource Location fields when creating the Sublayout in Sitecore. This will ensure that all Datasources that are suitable for this Component are located in one location improving the experience for the Content Editor.When these fields are provided, Sitecore will not allow an inappropriate Datasource to be bound to a component and the Datasource Location ensures that all Datasource Items are stored in a logical place in Sitecore.
If there is a situation where data is required from different nodes of the content tree, these can be provided via Droplinks in the Datasource Template o those locations – again, this ensures there is clarity and understanding of the data that the component requires to function. This also improves component testability as if the client wishes to perform any AB/MV testing, this will be possible by creating alternative Datasources.
Even if the Content Editor does not want to utilise MV testing, there are other ways to test a component. I’ve had a client want to create two pages with the same component on both, but each component pointing to two different Datasources. This method was required to show an example of a page that contains different content to the CEO to get approval on which content to use. This did require a small amount of rework (as the component pointed to the Context Item for its data) but after a little rework my client was very pleased with the capability and really started to “get” the power of Sitecore.
If the above is adhered to, this will go a long way to ensure that your components
So, just to recap
- Always use Dataources, they are very easy to use, and will save you rework in the future when you client wants to begin to utiilise other functionality of Sitecore (Testability/DMS etc.)
- Adopt “Assumption-less Design” i.e. Never assume anything in the Component. Always get you data from the Datasource (unless there is a very good reason not to – fortunately there are not many of these!)
- If you are finding that the Datasource is too large, it may be an indication that your component needs to be broken down into sub components.
Remember, as Developers it is our responsibility to design components that can be reused whenever required and to have the power to be testable and “personalisable” (is that a word?).
By taking this approach, you are not only ensuring that your clients gets Value for Money and can justify purchasing a Sitecore license, but also helps ensure the longevity of the components that you create 🙂
Feel free to leave any comments/questions 🙂