Reading Time: 6 minutes

The Default Schemas 4 Tridion project is my favorite pet Tridion project. And like my other pets, I hope other people like it as much as I do… and they forgive it for shedding so much. A good while back, I was tasked with setting up all the schemas for Tridion, without so much as having a clue when it would be implemented, or what the content models were. That inspired me to first whip up DS4T.  Then, I got inspired to make DS4T more atomic. And then, an over-caffeinated Frank documented it. Now, more recently, Tahzoo had three separate clients that wanted to build forms with Tridion. And all of a sudden, we all got inspired to whip up some form schemas.

Firstly: Credits Where They’re Due

Adding form schemas to the DS4T project was no easy task. We had a small self-made committee that collaborated (and butted heads) on what we thought these form schemas should look like. Jason Kaufmann, Chris Wall, Ashraf Nabih, Dara Keo, Shawn Webber, Brandon Bernard, and Josh Einhorn added a lot of valuable feedback. A lot of kudos go to those guys for meeting, sharing, collaborating, and content-porting. Default Schemas 4 Tridion is definitely  a community effort now thanks to these outstanding gentlemen. Seriously guys, thank you.

The Big Idea of Form Schemas

We looked to the W3C for inspiration on how to model our forms. And when I say, “we looked to the W3C for inspiration”, what I mean is, “Frank pulled up the specs from the W3C and whined about semantics like a 14-year-old Justin Bieber fan until he got his way.” So the Schema names and the fields are modeled after HTML elements that the W3C has created for forms. Let’s start from the inside out with this.

Field Schemas

There are four ways to receive an input from a user: a button, an input, a select box, or a textarea (yes, I know that visually there are more, but this is HTML here). So we have four content schemas:

• Generic Form Button Field
• Generic Form Input Field
• Generic Form Select Box Field
• Generic Form Textarea Field

Because these are content schemas, your content author can create her name field exactly once, and she can reuse it in as many forms as she likes. Many different forms share many similar fields, so you have the ability to reuse those fields across multiple forms, if you so wish.

Fieldset Schema

The W3C says that when you have a group of thematically related controls, you can wrap them in a <fieldset>. A fieldset is a…wait for it…set of fields. So, if you want to be all semantic, 21st-century-like, and all around a better looking fellow, you should group related fields together with a <fieldset> in your template, and let your content authors do that with a fieldset schema in Tridion. There are two solid use-cases for fieldsets: a collection of radio buttons, a collection of text fields to gather your address. A fieldset is also allowed to have its own, special kind of title, called a <legend>. This is an excellent way to group together “address” and “time of day” kinds of inputs.

Now, the magic here is that we have both an embedded Fieldset schema, and a content Fieldset schema. We had two reasons for doing this:

• It’s valid markup to nest fieldsets
• We can deliver more discrete control of layout by allowing the content author to set layout at fields and fieldsets.

Content Fieldsets

So, the content Generic Form Fieldset Schema has two fields:

1. Legend (a title for the collection of fields)
2. Fields (a Generic Form Embedded Field schema)

Legend is that title for the collection of fields. But your fields, there, are an embeddable schema. Why did we do that? Because, this allows the content author to set certain attributes of a field from the form, instead of the field. This was Josh Einhorn’s and Ashraf Nabih’s idea, and I think it’s a good one: let the field be syndicated, but let its usage be contained. So you can use the same name field all over the place, but you don’t have to inherit whether it’s required or not.

Embedded Fieldsets

The embedded fieldset has two different fields:

1. Width (a fraction of the form that the fieldset can take up)
2. Component link to a Fieldset

Form Schema

The Form Schema is where we put the pieces together. The form schema has quite a few different fields for the content author to manage:

• Title
• Subtitle
• Introduction (rich text)
• Custom Form Action (which you can use for the action attribute on the form)
• Label Location (where the content author decides if labels go on the top, or on the left)
• Fieldsets (an embedded schema)
• Disclaimer (a component link)

How a content author does it

1. A content author creates a button, an input, a textarea, or a select box. The content author sets on that field the type of input (text, password, email, tel, etc). The content author selects a label, a placeholder, and even a preset, or a custom validation (we created a category called Form Input validations. It contains some keywords which store common regexes)

   

2. A content author creates a fieldset component. She sets a title for the fieldset. She then adds fields, and links to her field components. Here she will decide if this particular field is required, disabled, and what width it should take up (from within that fieldset). I’m hoping Josh Einhorn will explain how he worked out the templating for these fractions in a blog post of his own. Because we’re using a CSS Grid, we can allow someone to place a field in a particular location of a form by creating blank fieldsets. It’s not the best approach, but we found it to be the most intuitive for content authors — since they think about layouts in tables, regardless of whether it’s a table that’s really doing it.

   

3. A content author creates her form. She adds title, subtitle, introduction to it. She also determines whether labels will display on top, or to the left. She adds a component link to a disclaimer. Then, she adds her fieldsets. She’ll select a width of the fieldset (relative to the form), and then add a component link to that fieldset.

   

 Finding the Schemas

Because they’re pretty different and special, they have their own folder, which is created at the 010 level, rather than the 000 level like the others. That way you can easily pull it out when doing the import.

 

The Other Pieces

This is a blog post that hopefully will be part of a series (though, every time I promise to do a series, I get distracted by something shiny and forget to do it). The Form Schemas are just part of the shenanigans. We also created an extremely flexible grid using a CSS preprocessor that made our “fractional layout” approach possible. When we prototyped, we used BEM to create an extremely well-controlled methodology for styling markup. Josh Einhorn used to be a civil engineer, and he whined like a 14 year old Justin Bieber fanFrank to get a CSS grid that was divisible by all these mathy-like numbers that he used in his templates. He had some silly excuse like making it intuitive for content authors. Lastly, we did some nifty things with JavaScript to handle form and field validations in a highly generic way. I’ll try to address how we did all these things in additional posts. If I forget to, just ask.

The Big Idea

Default Schemas for Tridion now includes forms. Fork it, import it, tell me what you think. I’ll get some updated documentation over there, I promise!