Sitecore Content Tree Architecture

6
votes

Let's say there exists a presentational component in a project that renders an unordered list (called ListRenderer, perhaps.) We have a couple options of supplying data to any given ListRenderer on a page:

  1. Have a TreeList (or TreeListEx) field on the content item, and have ListRenderer read from it.
  2. Supply a DataSource (or other Parameter) to the ListRenderer via the presentation details.

I usually avoid #1 in my projects because it binds Sublayouts to templates, which gets quite messy. If you go down that path, eventually you'll have fields to support every potential sublayout in your project.

So my solutions tend toward option #2, which gets rid of that problem. It does, however, come with its own bag of questions. Where do I put these various "Lists" for a given ListRenderer to use? To maximize reuse and sharing, I usually create a components directory near the site root that contains all these types of things, if I predict the Lists will be shared. This seems less findable and harder to use for the content author, who suddenly have no idea where the source for their ListRenderer is unless they know how to crack open the presentation details (which is slightly advanced for my average user).

If I feel like Lists won't be shared, and are very specific to the page, I'll put them directly underneath the item in question. This has a tendency to muddle up the content tree, though, and any dynamically generated navigation sublayout then has to check for whether or not an item is an actual page before it generates the link to it. The more I work in Sitecore, the less I use this approach, but it seems easier for the content author. There is much easier access to information when you use this approach.

Is there any industry-accepted way of approaching this problem? It happens in projects all the time, and in my head I struggle to balance technical and content authorship concerns in situations like these.

2
sitecorehierarchysitecore6
The simple answer is NO, there is no industry standard. Everything you mentioned are common things even seasoned Sitecore developers consider often. It's largely based on requirements, e.g. if you support Page Editor for these modular sublayouts then you want approach #2 with a globally shared data source folder. If they are using the content editor and don't like presentation details, some times sub-items make it easier. You need to EITHER pick an approach and force it on each project OR define the approach per project based on requirements for editors (my preference) - Mark Ursino

2 Answers

7
votes

Great question. I've used all the techniques you mentioned, depending on the audience and specifics of the project. The problem is that, as with all things Sitecore, they are all valid ways of achieving the same goal and you will struggle to find one answer that will work in every situation.

I almost always use #2 as well, but some content author retraining maybe necessary and make sure you add in restrictions to what the content author is able to select as a target. I have (within the same project) structured the items near the root (in a shared content folder) and under the item in question, depending on what I felt would provide the best context.

Also, if other child pages would exist below the item as well as the list items, then I would put the list items in a separate folder (with a common "list items" icon") and re-order it to be the first item for separation and clarity.

If you want to use any kind of personalization and DMS then you will need the ability to switch out the datasource anyway so you shouldn't hard code locations.

You might also (if you have not already) want to consider using:

Convert Data Source Paths to IDs Using the Sitecore ASP.NET CMS
- Useful if you need to restructure your content at a later date

Queryable Datasource Locations
- Useful for multi-site situations when you need to make clones, or setting as the default datasource value in Standard Values when the lists are directly below the item but gives you the flexibility to change it.

I prefer using querable datasources personally, I find the xpath syntax more logical.

4
votes

As Mark has commented, there is no real industry standard.

I feel like this is something that needs improvement. Especially when you are using the DataSource option, things become less transparent to the editors and as the size of the site grows, so does the complexity.

All I can tell you is how I would do it, which is most likely much like how you are doing it.

1) For overview pages like news, events and faq items, I will put the items underneath the overview item and use the NewsMover shared source module to auto-create a hierarchy.

2) I will create a Global site that contains items that are shared across sites or pages. DataSource items for components will be put in here.

3) For components that are present on the standard values, I will add a list field to the template (for example, when you display related items on a content page)

Most often it's a logical choice and sometimes it's just a matter of taste.

I'd like to add that I've written a blog post on how to have datasource items created automatically for components that are set on standard values. That might help you if you are using those.

Edit: "I usually avoid #1 in my projects because it binds Sublayouts to templates, which gets quite messy. If you go down that path, eventually you'll have fields to support every potential sublayout in your project."

Today I've blogged about a method of hiding fields and sections in the content editor if there is no sublayout set on the item that requires those fields, which helps to prevent the mess of having a lot of unused fields on your items.