Content classes for builders
Part 2, chapter 17. A content class is a type of content: Article, Event, Product. Its attributes are the fields, each of a datatype (one line of text, rich text, image, relation...). Everything a builder does with templates rests on this model, so a little care here saves a lot of template code later. The step-by-step creation of a class is in The content model and editing content.
The terms
| Term | Meaning |
|---|---|
| Content class | a type: name, identifier, attributes |
| Attribute | one field of a class: name, identifier, datatype, required or not, translatable or not |
| Datatype | what kind of value an attribute holds (ezstring, eztext, ezxmltext, ezimage, ezobjectrelationlist ...) |
| Content object | one piece of content of a class, with versions and translations |
| Node (location) | a place of an object in the content tree; one object can have several |
The datatypes offered when you add an attribute are content.ini [DataTypeSettings] AvailableDataTypes[]; extensions
add theirs (eztags adds a tags field, for example).
Identifiers are the contract
The class identifier (article) and the attribute identifiers (title, intro, body, image) are what templates,
overrides and fetches use:
{$node.data_map.title.content|wash}
{attribute_view_gui attribute=$node.data_map.body}Match[class_identifier]=articleSo choose them once, carefully:
- lower case, letters, digits and underscores; English words that say what the field is,
- never rename one that templates use (rename the human name instead; the identifier can stay),
- the same identifier for the same meaning in every class (
title,image,intro), so one template part can draw the image of an article, a news item and an event alike.
The object name pattern
Each class has an object name pattern such as <title> or <first_name> <last_name>. It builds the name shown
in the tree, in lists and in URLs. Use the attribute that people recognize the content by; URL aliases are made from
the name.
Containers
A class marked container can have children. Folders, frontpages and sections of a site are containers; articles
usually are not. A builder's lists (fetch( 'content', 'list' )) only make sense below containers.
Good models are boring
| Prefer | Over |
|---|---|
| one class per real kind of content | one class with a "type" selection that changes everything |
| a relation attribute to shared content (an author, a location) | copying the same data into many objects |
| rich text for long text | many small text fields for paragraphs |
| a datatype that exists | a new datatype, until you are sure (see Datatypes) |
Model the content as editors think about it; the templates follow.
Classes in an extension
A class made in the administration lives in the database. To ship it with an extension (so another installation can create it), there are two ways:
- export it as a package (
Setup > Packages, class export) and put the package in the extension; see Packages, - write it as a script that creates the class: the RAD wizard Content extension (
/setup/contentextension) writes one for you (RAD tools).
Related pages
- Previous: Caching and templates
- Next: Sections, roles and access for builders
- The content model and editing content
- Class groups
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.