Question

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.

Answer 1

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.