This page is currently still left here so old links will continue to work, but the content is not updated any more.
Understanding the Need
Many scenarios require output-configuration. Here a few examples:
- You have a template that shows simple content, and sometimes the title should be <h1>, sometimes <h2>, etc. Instead of creating 6 different templates, it would be easier to allow simple configuration of the heading-tag. This kind of presentation-configuration is handled by the Presentation-entity.
- Your Title/Text/Image allows the user to place the image no the right or on the left side. Instead of creating multiple templates, let's just let the user configure the variation he wants. This too is handled by the Presentation-entity.
- A complex template like a Google-map can configure 10-20 different parameters. These should not be set in the address which we will show - because these parameters have nothing to do with the address itself. So we need a way to provide 10-20 input-fields, drop-downs etc. - but not mix it with the address itself. These 10-20 input fields would be handled in a Presentation-entity.
- The same piece of information - like the address of 2sic - could be shown on different pages. Each instance might have some presentation configuration that differs from the other ones. It would be impossible to configure this if the config-fields were in the address-entity. So we place them in a separate Presentation-entity.
Important: Presentations are 90% Stable, so use Defaults whenever possible
One thing we discovered, is that configurable templates can be annoying because often there is a default configuration which applies to 90%. For example, if you create a configurable heading-tag <h1> through <h6>, usually 90% of the cases need <h1> because this is used on every page. Such defaults are handled easily by providing the template with a default-presentation entity containing these common settings. These will automatically be used if not overruled.
So how does this work? Each template has data to show (the Content-entity), but it can optionally also have a presentation-data (the Presentation-entity).
Example: Using the Presentation to control the heading-tag in a template
These are the content types
- Simple Content - with the following fields
- Title (text, 1 line)
- Content (wysiwyg-text)
- Image (link to an image file)
- Presentation for Simple Content with the following field
- Heading (text, drop-down containing h1, h2, h3, h4, h5, h6)
The template configuration specifies the simple-content as the content type, and the presentation-for-simple-content as the Presentation-type. The user now has an additional section in the Edit-UI to configure the presentation.
The template would then contain the following fragment:
- Token: Instead of the classic <h1>[Content:Title]</h1>, it would have <[Presentation:Heading]>[Content.Title]</[Presentation:Heading]>
- Razor: Instead of the classic <h1>@Content.Title</h1>, it would have <@Presentation.Heading>@Content.Title</@Presentation.Heading>
Power-Feature: Using Default-Values in this Presentation
Now remember that probably 90% of all use cases for this will want an <h1> tag. It would be annoying to have to specify this every time, so please create a demo-entity and assign it in the template-configuration.
All Features of Presentation-Types
- Presentation-Types are optional, templates don't require them
- Default-Values are optional, but highly recommended
- Data / Values in a presentation-content-type are not indexed by the search
- Presentation-Items are unique for every use. So if you show a piece of content in many places, each occurrence can have different presentation-settings
- Content-Items can have a presentation...
- ...Lists can have their own, different presentation. This is used to configure the list (for example, how many items to show before paging)
- ...and Lists can also have their own default presentations for fallback
- The UI always allows the editor to revert back to the default-settings