Best way to design embedded components in CMS(component inside component 3 levels)?

Question

Looking for best way to design embedded components (component inside a component up to 3 levels) in SDL Tridion.

Example:
Details (show/hide) is a parent component and list is an embedded(child) component, which can be used in any other component. The same list component can be used in any other component like tabs.

To represent this in JSON:

{
  "Component": {
    "Id": "tcm:123-1234567",
    "Schema": "Details",
    "Content": {
      "summary": "Something small enough to escape casual notice.",
      "text": "<a data-reference-id=\"123987\" "
    },
    "Metadata": {}
  },
  "ComponentTemplate": {
    "Id": "tcm:123-567-891",
    "Title": "Details"
  },
  "references": [
    {
   "123987": {
      "Component": {
        "Id": "tcm:223-1234568",
        "Schema": "List",
        "Content": {
          "text": [
            "item a",
            "item b",
            "item c"
          ]
        },
        "Metadata": {}
      },
      "ComponentTemplate": {
        "Id": "tcm:158-567-981",
        "Title": "List"
      }
    }
    }
  ]
}

In the above approach the drawbacks are additional processing of json to identify parent reference (for the 3 layers) and placing it back with correct mapping and when processing from UI connecting items.

Any other best approaches/practices can we use with support of embedded components?

Answer 1

I agree with Alvin in terms of it depending on the requirements. Is the content reusable (at any level), are there {strict} formatting rules around the presentation of lists

Reusable? If you find that the items you are using at the third level are reused then it may make sense to have these as individual components linked to the level above.

Format? If you have specific presentation rules that need to be enforced at the application level you may really benefit form the embedded model (in having explicit fields to present to the developer). An example I've seen here is where only the first n bullet points are shown on mobile devices - something we may have

• the editor "manage" - if we do through some class application (dependency on editors to apply the correct class to the correct item(s) - what if the number we wish to show changes ... a.l.l. that content)
• the developer add more complex code to irerate through content items to enumerate (dependency on code and probably precise formating from editor)
• the content model be such that the editor is presented with fields to populate - and the developer with a (consistent) list object they can easily parse and present according to presentation rules of the chanel

If the use-case is as simple as the one you describe above then I don't see the GUI/editor UX being detrimental enough to arrange around what would seem to be a sensible {embedded} model for the purpose.

Noting, however, the GUI itself isn't ideally designed when using embedded fields so the editor UX can be that they are dealing with a bulky view; often including a number of mainly redundant fields over time. An example of this happening could be through the addition of edge-case fields that are added at the preference to creating new embedded fields ... remembering the design of the GUI is that all embedded fields are shown expanded so, therefore, consume a great deal of vertical space.

I have a tendency to try to avoid RTF solutions (certainly with all formatting available) if possible for the simple reason they will be abused very quickly. Allowing users to format bullet types etc. can mean you quickly lose central control over the format/branding (e.g. if an editor wraps <li><ul> in <p> and another in <div> or requires some class or arbitrary design tag - then you're in the realms of presentation + content.

So the gist is ... it depends.

The requirements include the structure and reuse of the content the editorial complexity of the resulting GUI the design and rigidity to be applied or expected flexibility to the editors the technical requirements from the development team the business... are they happy for a fully designed, flexible, scalable solution or is the business priority to get it out of the door and potentially suffer the redesign pain later - it happens!

Answer 2

It depends on what you're trying to optimize, from a very flexible content model to something that's easier for editors.

You mentioned 3-levels deep and in general, I've found editors prefer flatter content models with fewer Components to create, manage, and assemble. For example, a list component for those bullet points might make sense, but that can be tedious if that's the only way for editors to create a list of items.

Recommendation: flatter model

If possible, I'd recommend either a paragraph or article-like Schema for the summary text and bullet points, both as part of a rich text format area. You could even have the "details" text come from a heading or subheading.

The display could then come from how or where the Component is linked from (e.g. from a specific type of Page, Region, or other Component). Otherwise the editor could select a template to get the "Accordion" treatment.

Alternatively, you might consider an accordion-specific Schema, though that feels more like a presentation decision than the definition of the content itself.

---

I wrote a bit more on content modeling in these posts, if it helps:

• https://www.createandbreak.net/2015/06/goldilocks-of-creative-design-from-cms.html
• https://www.createandbreak.net/2013/11/content-modeling-best-practices.html
• https://www.createandbreak.net/2012/09/tridion-information-architecture-part-1.html