In today’s post, I’m going to talk about Sitecore Items. A Sitecore ‘item‘ is the basic building block for everything that makes up a Sitecore website. Forget about C# and HTML files for now, as Sitecore items have no relation to actual real files on a filesystem. A Sitecore ‘item‘ is a virtual object that lives within Sitecore itself (the database).
When you open up the Sitecore Editor, you will see a navigation tree. Every entity within this navigation tree is an item. The first item in the tree is called the ‘Sitecore root item‘ and everything else that makes up your website lives underneath it. This hierarchy is the quintessential example of a parent/child relationship. Each item can only have one parent, while any item can have multiple children. Underneath the main Sitecore item you have ‘content’, ‘media’, ‘layout’, ‘system’, and ‘templates’ (the use of each of these will be explained in the next tutorial), underneath these will be the things that make-up your website.
To help developers understand how ‘items‘ fit into the mix, most material on Sitecore compares ‘items‘ to object oriented programming ‘objects’. Like an OO object, items can be used to represent different things. Some items will represent content, some items will represent templates, some items may even represent settings, like an option for a drop-down list or an image. Items can even inherit from other items to prevent duplication, so one item might be constructed of 2 or 3 different items
This tree structure of different items is quite different to a lot of other CMS systems. Most other CMS systems, like Episerver for example, only allow content items/web pages items to be created within their hierarchy and nothing else. Having your whole system based on an only content model has its pro’s and cons. The pro’s of a content only structure is simplicity. It’s definitely easier for content editors and developers to understand the solution. In a content only tree structure, each item represents a page. The order of the tree, represents how the website will display, simple.
Things get a little bit more interesting when you want to store data. If, for example, you need to render a custom drop-down list on a page. The drop-down needs to display values that are configurable in the CMS, where do you put this data? In Episerver, you may need to create two new page templates called ‘Dropdowns’ and ‘DropdownValues’ which will live in the content tree. Technically, these values aren’t web pages, so you end up with a structure that can be quite messy. If you’re a bit OCD and you think in purist terms, you might not like the idea of having these settings as ‘content’ when in fact it’s just data.
Instead, if you wanted to store your dropdown settings in Sitecore, you could use two out-of-the-box ‘Setting’ data templates. The item wouldn’t live in the ‘content’ area either but in a more relevant area like ‘Layout’. If you’re reading this and thinking brilliant, ‘why doesn’t everyone do it like this?’ then I’ll try to explain why this approach isn’t always ideal in every situation.
If you have a simple project where you only want items to represent pages and nothing else, then having a complex tree made of up different types of objects can make it confusing and hard to find what you want quickly. The Sitecore tree is big and complex and finding items in the Sitecore tree can be frustrating at times. A good challenge to prove this is to try to update the WFFM (forms add-ons) email setting without having to Google it.
This added complexity is a common trade-off with Sitecore, as well as a great example about how different CMS systems are suited towards different companies. In general, with an object approach, you may need to create more ‘items‘ and perform more clicks compared to other CMS system, however, when you don’t restrict the types of objects to be created, you get a lot more flexibility, which will mean less effort in different scenarios.