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_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:
<br /><h1>@@Component.Fields.header@@</h1><br /><ul><br /> <!-- TemplateBeginRepeat name="Component.Fields.body" --><br /><li class="slide@@TemplateRepeatIndex@@"><br /><div><br /><h3>@@subheading@@</h3><br /><p>@@text@@</p><br /></div><br /></li><br /> <!-- TemplateEndRepeat --><br /> </ul><br />
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.
<br /> <Content xmlns="http://createandbreak.net/schema/FAQ"><br /><header>Some questions</header><br /> <body><br /> <subheading>How will this look?</subheading><br /> <text>What do you mean?</text><br /> </body><br /> <body><br /> <subheading>How will this look with a template?</subheading><br /> <text>It depends.</text><br /> </body><br /> <body><br /> <subheading>Oh what?</subheading><br /> <text>The template!</text><br /> </body><br /> </Content><br />
- 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!