Reading Time: 5 minutes

You’re a front-end developer. You’re writing for a component template. You hand off HTML for a back-end developer to write a view. The back-end developer looks at it, goes cross-eyed and starts muttering to himself. You explain it. He says, “yeah, Tridion can’t do that.” You read my last post; you’d know that there’s a good chance that Tridion can do that, but he starts rambling on about XSLT filters, metadata, and a broker database. How do the fields in schemas actually work? What can they do? Why does the Tridion architect smell like whisky and bad decisions at 10:00am on a Tuesday?

Let’s answer all of these questions.

1. There’s 6 kinds of schema

Content Schema

A schema that makes a component. In the screenshot, it’s the one that’s just called “Schema” (naming things is hard ¹).

Multimedia Schema

A schema that lets you add binaries in Tridion. “Multimedia” doesn’t mean images and video, it means, “anything that should be treated as a file”

Metadata Schema

Metadata schemas contain information about the content. It’s like of like data that the hipsters would call… meta ².

Embeddable Schema

A schema that you put inside of another schema. It’s a way to keep your schemas DRY.

Parameters Schema

The weird one; I’ve only seen it used a handful of times. It’s a way to pass data into templates. Parameters schemas don’t apply to content, or anything editorial.

Bundle Schemas

It’s what the name says. A bundle schema enables you to make bundles. And bundles are… for another blog post. On someone else’s blog.

2. Embeddable Schemas are for “objects” and “partials”

Say you have a news article, a press release, and an interview component, and they all need to show the date, time, and author. Rather than manually writing the same 3 fields in every schema, you make an embeddable schema, and put that in your content schema.

Why it matters for front-enders

You have 3 different things showing the same pattern of content. So now, you can keep your code DRY by using same markup every time that embedded schema gets used. Now the back-end developer loves you because he can create a “partial” in his MVC app and tie it directly to this embedded schema. You then control the varying looks of this pattern by targeting this “object” at the component-template level.

The most common things to become embedded schemas are:

• Paragraphs (Rich Text Fields): At least one RTF field, sometimes gets a title, sometimes an image, sometimes it’s all repeatable
• Paragraph-level images: A multimedia image link, a caption, sometimes a position (so it can float left, right, or be centered)
• Calls to Action (CTAs): the text, a link, how it should look (more buttony, more linky), sometimes an image
• Headers: A title, a subtitle, an optional image, sometimes a date and time, sometimes an author

If you love you some HTML5 semantics, then you could easily equate most of these to a new semantic element

Embedded Schema	Semantic Container
paragraph	<div class="rtf"> </div>
paragraph image	<figure class="figure figure--left"> <figcaption> </figcaption> </figure>
CTA	<aside class="cta">
header	<header class="header"> <h1 class="header__title"> </h1> <h2 class="header__subtitle"> </h2> </header>

3. Metadata schemas are the non-content content.

Maybe calling metadata schemas “hipster data” isn’t the most helpful description. Howsabout I try with bullet points?

• Content Schemas contain content for the end user
• Metadata Schemas contain content for the Tridion user, or for the web app
• Content Schemas are used only for making components, components which are added to pages and published
• Metadata schemas can be applied to anything in Tridion

Take note that metadata schemas are applied to things, while content schemas make things . A metadata schema… modifies a thing. My inner grammar nerd wants to tell you that the metadata schema is Tridion’s adverb.

Why it matters to front-enders

There’s many different places in Tridion where information about content can influence or affect the front-end:

• Pages: title, description, meta tags, special CSS, special JS
• Structure Groups: navigation titles, special rules for when to display in navigation, cute icons
• Categories and Keywords: Icons for images, hex values for color names, validation rules for input fields
• Folders: If you manage all your CSS or JS in Tridion, then a metadata field
• Publications: global CSS files, global JS files, definitions for generic class names

Often, we answer the question, “is this content content or metadata content?” along the lines of, “is this for the end user, or is this for the Tridion user?” Some Tridion Architects are very serious about never crossing streams.

4. It’s bad to cross schema streams

You know what happens when you cross streams:

If there’s one reason why putting content in a metadata field can trigger tirade of tongue-lashings from a Tridion architect, it’s Dynamic Publishing. If you think you need a metadata field to store something that isn’t necessarily “metadata-ish”, first find out if the implementation uses dynamic publishing ³. Changing the role of metadata from, “information about content” to, “more content” has technical challenges and repercussions beyond just the template.⁴.

Another, more important reason to hold off on putting that image in a metadata field is the user. Tridion offers an inline, in-site editing tool called Experience Manager (XPM) ⁵. Site edit enables users to edit fields that come from the content schema, not the metadata schema. If you want to put an image, icon, or even field that toggles layout or grid in a metadata field, then the user won’t be able to edit that from XPM.

TL;DR

There’s actually more than four things a front-ender should know about Tridion Schemas. But four is a good starting point.

• There’s six kinds of schema. Know what they are and when to use them
• Embeddable Schemas are a good match for small, reusable blocks of code
• Metadata and metadata schemas are where you put information that isn’t necessarily content, but is necessarily useful.
• Know the difference between content and metadata