Metadata Child Items

In order to achieve flexibility in the design of your site, you may store metadata items as children of a primary content item. End users typically navigate only to primary content items, while the child metadata items may drive the presentation of the content or other aspects of the end-user experience.

Consider a requirement for business users to add any number of sidebar items to a web page. For purposes of simplicity, imagine that a sidebar item contains two fields: a title, and a link (i.e. a field that points to another Sitecore item). To address this requirement, your content tree may look something like this:

I. Article A
  a. Sidebar Item 1
  b. Sidebar Item n
II. Article B
  a. Sidebar Item 1
  b. Sidebar Item n
III. …

If business users can edit both a left and a right sidebar, your content tree may appear thus:

I. Article A
  a. Left Sidebar
    i. Sidebar Item 1
    ii. Sidebar Item n
  b. Right Sidebar
    i. Sidebar Item 1
    ii. Sidebar Item n

The benefit of this approach is that business users can add unlimited amounts of metadata (in this case, metadata that drives presentation logic) to each content item. The weaknesses of this approach are at least three-fold:

1. The Content Editor becomes increasingly complex and, as such, may be confusing to users who access it.
2. Non-technical business users will require more training to understand how to use content markers in WebEdit mode. In the example above, each web page will have several content markers, i.e. one for the content item itself and one for each of the sidebars.
3. Sorting becomes complicated. Business users can sort the sidebar items up and down using the sort commands in the item editor; but WebEdit mode lacks a Content Editor-style visualization of the sorting. This is not unique to the metadata child items scenario, but may decrease usability in an already usability-challenged implementation.

Even given these limitations, there are times where using metadata child items is the best possible solution.