Multiple Fields, Child Items or Global Items?

Certain content types may have repeating fields. For example, on your public website, every product may be displayed with three accessories. One way to address this requirement is to include fields in your template for each of your accessories. Imagine a template with the following structure:

Product
Title	Text
Description	Rich Text
Accessory One	Rich Text
Accessory Two	Rich Text
Accessory Three	Rich Text

The advantage of using this kind of template structure is that business users will find it easy to enter content. Clicking on a single content marker will allow them to update both the product and its accessories. Ease-of-use should not be underestimated as a benefit to this approach.

There are at least two shortcomings of the approach: 1) If the number of accessories varies per product, business users will need to enter the accessory information in the appropriate fields and ignore unused fields. If the number of accessories for products increases beyond three, the template will need to be modified to add an “Accessory Four” field. 2) The reusability of the data is limited. If two products reference the same accessory, the accessory description will have to be entered twice (i.e., once for each product).

One solution would be to create a structure of products and child accessories. Consider, for example, the following solution:

I. Products
  a. Product One
    i. Accessory A
    ii. Accessory B
    iii. Accessory C
  b. Product Two
    i. Accessory A
II. …

The content is structured to allow n accessories per product. Some products may have one accessory, while others may have ten. When business users create new products, the product master will be configured to create the appropriate number of subitems.

There are several weaknesses to this approach: 1) More work will be required of business users to edit the accessories, i.e. there will be one content marker for the product and additional content markers for each accessory. 2) Deleting a product necessarily deletes its accessories, which may or may not be desirable. 3) While the solution allows the business user to create any number of accessories, the content structure is not easily reusable. In particular, if a requirement exists to render a list of all accessories, your code would need to traverse the products section of the site, looking for content items that are based on the Accessory template. In simple circumstances this may not cause problems. If accessories are distributed throughout the site, however, this query would need to traverse all possible nodes where accessories may be descendants. This would introduce some complexity and possibly impact performance.

Yet another approach would be to list all accessories in a global area and reference those in the Product template. In this case, the product template may look like this:

Product
Title	Text
Description	Rich Text
Accessories	Multilist /sitecore/content/home/accessories

Business users will create new products and then select the appropriate accessories from the multilist control. The strength of this approach is that the accessories are easily-reusable content and the business user experience is straightforward.

The weakness of this approach is that it assumes that accessories are pre-entered under /sitecore/content/home/accessories. In other words, if an accessory doesn’t exist yet, there is no way to select it in the multilist control. For business users to create or edit accessories, they will run into similar difficulties as in the child-items scenario (i.e. more clicks to create both a product and its accessories). If accessories themselves are treated in the same way as other products, this may not be a serious issue, i.e. accessories must be created as products regardless of whether they are related to an already-existing product. In any case, items must be created before dependent relationships can be asserted. This can complicate the business user experience but may be addressable through training.