Will Price, as a Tridion Jedi Master, must have sensed the schemas on my mind.
He mentioned a very classic-looking, near-famous schema, which includes the typical headline, date, subheading, and text fields.
I want to expand on embedded schema, repeating fields, and the resulting design flexibility from using them together.
Specifically in this part:
- Subheading, a text field
- Body, a rich text field
We can create an embeddable schema (set  schema type to Embeddable Schema and preferrably change the root node to anything but “Content” to avoid naming conflicts). We end up with a mini section of semi-structured content:
- Body
- Body_heading, a text field
- Body_content, a rich text field (possibly repeating)
Add this as a repeating embeddable schema and we can then use a simple layout template that takes advantage of the repeating structure to create a variety of scenarios.
- Visual or interactive presentation such as:
- Multiple “right rail” content types, but authored in a single component
- A tabbed-navigation view
- Accordion-style vertical or horizontal tabs
- Tablet or mobile “swiping” interfaces
- Question-and-answer format (FAQ)
- Lists as ul, ol, or any other repeating format
Authors can still use a single “body” section to enter rich text, but if they group up content into sections we can use the following markup or similar:
<h1>@@Component.Fields.header@@</h1>
<ul>
<!-- TemplateBeginRepeat name="Component.Fields.body" -->
<li class="slide@@TemplateRepeatIndex@@">
<div>
<h3>@@subheading@@</h3>
<p>@@text@@</p>
</div>
</li>
<!-- TemplateEndRepeat -->
</ul>
This is based on the following component source. Authors simply press the “+” icon to add new sections, which can easily be re-ordered, updated, or removed.
<Content xmlns="http://createandbreak.net/schema/FAQ">
<header>Some questions</header>
<body>
<subheading>How will this look?</subheading>
<text>What do you mean?</text>
</body>
<body>
<subheading>How will this look with a template?</subheading>
<text>It depends.</text>
</body>
<body>
<subheading>Oh what?</subheading>
<text>The template!</text>
</body>
</Content>
Add your favorite CSS and/or JavaScript to create whatever you need design-wise. In terms of trade-offs, consider the following.
- Con: If you re-use a single embeddable schema, individual fields don’t have domain-specific names. This works great with subheadings and clear sections (e.g. paragraphs), but what happens with repeating images, titles, or links?
- Primary image, primary heading, and primary link might make sense.
- But as you get to the third image or section of text, you introduce “intellectual overhead” from an author perspective. “So what does the third link do on the site?” Or just across templates?
- Pro: However, this is flexible because it lets authors add additional links and the setup can be used across schemas, reducing template variation (by re-using the same-named fields for DWT). Multiple schema gives you options to control schema-based security and workflow better.
- Depends: Changes to this embeddable schema affect all schema that use it, so updates can be handled in one place. This is great for global changes but bad if we want to make slight changes between versions.
When in doubt, always test. Don’t make schema changes in production!
Update: added the qualified path in the DWT example. Thanks, Mihai!
Good writing, Alvin! I like this simple approach, yet very powerful.
One comment, leaning towards the best practices realm: try using fully qualified DWT variables, such as Component.Fields.header, instead of Component.header. This will improve readability of the DWT code and avoid name clashes. One could argue that it also improves performance, by reducing the ‘search space’ for the Dreamweaver Mediator, although I don’t think it’s going to make any noticeable difference.
The fact becomes even more apparent in the repeat structure name=”body”. If you had another package item called ‘body’, the mediator might get confused as to which variable your refer to. So I would use Component.Fields.body instead.
Gents, any ideas why using Embeddable schemas might be considered *not* a best practice?
Personally, i find them an essential tool for code reuse. But somehow current client wants to avoid them. So wanted to know the rationale.
Hi Taras, qood question.
I also like embeddable schemas for reuse as well as a consistent author experience and easier development maintenance. We also need them for repeatable groupings of fields, otherwise we might have link1, alt1, link2, alt 2 or worse, link (repeatable) then alt (repeatable).
How many times have we heard something like, “Yeah, it’s always two tabs,” to later find out it needs to be two to five instead? Or imagine a requirement to remove “underline” ability across all schemas (much easier with embeddable schemas).
A client might want to skip them for the following scenarios (IMO):
1. Separate editorial schemas have different needs. For example, the Article links to a Banner component (that links to a Multimedia), whereas the Biography might link directly to a Multimedia component.
2. They have separate development teams and/or authors with different needs. For example, Marketing material may have more rich text options than other content (possibly plain text for different authors). Each development team must own the differences in their schemas, though.
3. They need very different descriptions for fields. Preferably they’d use the same field names to simplify template development.
4. A grouped set of content should be its own component, rather than an embeddable.
I think these should be informed choices. After understanding what embeddable schemas offer, customers can choose to avoid them. If not for everything, at least consider them for fairly generic sets of fields such as “link” (title, internal link, external link), “body” aka “paragraph” (subheading and text), and maybe “image link” (multimedia link and alt text).
Ultimate flexibility has a cost–the client won’t notice it until the next major change.
I shared a little more on schema design in these posts:
– http://www.createandbreak.net/2012/12/when-near-duplicate-sdl-tridion-schemas.html
– http://www.createandbreak.net/2012/09/tridion-information-architecture-part-1.html