Combining content: concepts

There are two methods for combining content:

  • Nested / Linked content, whereby the linked item is independent and may be shared by a number of assets that all link to it.
  • Inline content, which forms part of the whole and is indivisible from it, thereby providing reuse of structure but no reuse of content.

Nested / Linked Content allows the user to create and add other content types to an existing content item; for example the user may wish to compile a carousel made up of several different image slides. This approach to linking otherwise independent content allows for re-use, by making the linked content available via the Content Library as an individual content item. One effect of this is that an update to the linked content will be reflected in all the content that links to it; e.g. all carousels that show a particular image slide will change if the image slide is updated. In technical terms, this is like linking objects "by reference" in an association arrangement.

Inline Content works by embedding one content type within another one by (the developer) embedding one schema within another one, which in technical terms is like linking the objects "by value" in an aggregation / composition arrangement. It is applicable to simple compositions where a particular set of fields and validation are required for inclusion in a particular content type but without the values being shared across multiple content objects.

Inline content never exists in its own right independent of the containing content, and so cannot be reused via the Content Library in the production view of Dynamic Content.

When to Use Each Kind of Included Content

When deciding between nested content and inline content, the things you should consider include:

  • Granularity: Do you merely want to break down a big unwieldy content schema into smaller parts for clarity, and to factor out potentially reusable definitions? This would be inlining.

  • Reuse: Do you also want the content items defined by these sub-schemas to be shared among multiple content items? This would be nesting or linking.

  • Ownership / Lifetime: Do the items defined by the sub-schemas somehow "belong" to the containing schema, such that they should cease to exist at the same time? This would be inlining.

In the context of the Content Authoring workflow, it is the developer who determines what schema structures get reused through inlining whereas it is the content editor who decides what content gets reused via nesting / linking.