Web pages created with Magnolia CMS are based on templates. Templates ensure that page structure and presentation remain consistent while the content varies from one page to another. For example, an event template helps you generate event pages that look and feel the same but display a different event each.
The system generates pages by merging a template with corresponding content from the repository. The position and inclusion of each page element is defined by the page template. The template allows authors to choose from a number of different components in a single area of the page.
Pages, areas and components
Note! The diagram shows the detailed JCR view on the left. This is not how authors see content. The user interface for authors and editors hides much of the complexity, providing a user-friendlier way to manage pages, areas and components.
- An article about basketball in the New York Times Sports sections has the following page properties:
titlerendered as an H1 element on the page, "Bulls and the Thunder Make a Stand".
authorrendered on the dateline.
abstractto provide an introductory paragraph.
maincollection which contains components.
subtitleelement "THUNDER 101, LAKERS 96".
Magnolia CMS templating mechanism consists of the follow components:
- Template definition makes a template script available to the system by providing a name for it. It is the configuration for the template script. For instance, it defines the model class to use.
- Template script renders the content. The script is written in FreeMarker, JSP or a custom templating language. The script instructs the renderer where to place the content on the page and also contains placeholders for content attributes such as headings and images.
- Dialog is used to enter and edit content. It is a customized HTML form with fields for entering text and meta data and selecting images.
- Content for the page, area or component is retrieved from the repository. It may contain text and references to images that need to be rendered. The content node meta data assigns it to a particular template definition. This way the rendering engine knows which template definition applies to the content. Through the definition, it can then choose the correct renderer. Note that the reference to a template definition is only a suggestion. It is also possible to use something else to render the content. You might define an alternative template when rendering content for a mobile device, for example.
Below you find a more detailed map of relationships between the elements that make up the template mechanism. Starting at the top left corner, a template definition defines the template script used to render the content. The location of the script is given in the
templateScript property. The template definition also assigns a dialog definition in the
dialog property. The dialog definition is a group of configuration nodes just like the template definition. It defines what tabs and fields should be present in the dialog.
The template definition further defines a
modelClass. Model is a Java program that holds your business logic. The model can do any task required such as execute a Google search or calculate an insurance policy. It holds the results of the logic execution and passes them to a renderer.
The renderer includes the results on the page as instructed by the template script. The script tells the renderer where to place the content. It contains placeholders for content attributes such as headings, images and the results of the business logic execution.
A Web page is the output of the rendering process where template and content are combined.
The following class diagram shows the relationships between the objects collaborating in rendering of a template.