Is it time to change the item structure of sitecore?

I hope with this blog to start a discussion about how we structure non-content items within sitecore. It is not about Component based architecture, that is just to set the context.

Sitecore item structure has always been very type orientated, see below. Where the content is structured by type instead of its logical grouping (component) i.e. you have to store the templates under the template folder, sub layouts under the sub layout folder, etc.

by type

For many years I have used component architecture where the logical grouping is more important than type i.e. Function before type. Use “Agile design principle”, where functionality is logically grouped based on cohesion. Focus on re-usability, maintainability and releasable.

by comp

It provides a good way to model a websites, as a website typically consist of one or more pages types, where each page type contains a number of components. The image below helps identify typical components.

break down

Each component usually consists of a number of non-content items i.e. layouts, templates, renderings, media, settings, look up values, etc.

Whist the visual studio project for the component can group the related files (C# classes, sub-layouts, layouts, XSLT’s, images, etc.)  prior to Sitecore 7.x this is not possible for template, layout, etc. items, they have to be stored under their respective root item, which causes items being fragmented throughout the item structure.

To assists in locating items related to a component, we are forced to use folder naming conventions to help track where a components items are located:

  • Templates                 /sitecore/templates/components/[COMPONENT NAME]/….
  • Sub-Layouts             /sitecore/layout/sublayouts/components/[COMPONENT NAME]/….
  • Renderings               /sitecore/layout/renderings/components/[COMPONENT NAME]/….
  • Layouts                    /sitecore/layout/layouts/components/[COMPONENT NAME]/….
  • Media Library          /sitecore/media library/components/[COMPONENT NAME]/….
  • Data source items (i.e. drop down values for the component) – usually specific to the implementation/component

SPEAK/ROCKS sets non-content items free!

Since the release of SPEAK and if you use Sitecore Rocks it is possible to store your template, layouts items etc. outside their respective root folder 🙂

This is in fact the philosophy and best practices for SPEAK where each application must be self-contained and store all templates, layouts, data source items, etc. under the root application item.

The only exception to this, is the dictionary items which must be stored under the dictionary item, please Sitecore can you fix this 🙂

This afore mention approach has the following advantages

  • Each component is self-contained an isolated from other components.
  • It is easier to maintain as all the items are grouped together and not spread out throughout the tree structure.
  • Easier to remove a component as you only have to delete a single root item.
  • Easier to move a component from one website to another, as you only have to take the root and its children.

One issue it does not help with is if a component modifies the Sitecore client as that is defined in the core database.

So if we move to a SPEAK based structure for non-content items it could be as follows:

  • Templates               /sitecore/components/[COMPONENT NAME]/templates/….
  • Layouts                    /sitecore/components/[COMPONENT NAME]/layouts/….
  • Sub Layouts            /sitecore/components/[COMPONENT NAME]/sub layouts/….
  • Renderings              /sitecore/components/[COMPONENT NAME]/renderings/….
  • Media                       /sitecore/components/[COMPONENT NAME]/media/…
  • Data Source values /sitecore/components/[COMPONENT NAME]/data source/….
  • etc.                           /sitecore/components/[COMPONENT NAME]/[…]/….

I have not had the opportunity to try this with a customer and the only issue holding me back is that it requires the use of Sitecore Rocks as the Sitecore client itself does not support templates/layout items outside of their folder.

I would love any feedback about the idea of moving templates, etc., out of their respective root folders for a web site, and not just for SPEAK applications.

3 thoughts on “Is it time to change the item structure of sitecore?

    1. alancoates Post author

      One of the major issue’s I have with MVC, is that controllers, have to be in a controllers folder, views in a view folder, etc.

      Why group by type, it reminds me of FORTRAN 77, where you have to use Hungarian notation, to declare the type.

  1. Pingback: Sitecore multi site and component architecture |

Leave a Reply

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

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

Facebook photo

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

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.