Configured renderable definitions

Page, component and area definitions represent the static configuration for these objects. They are instantiated with the content2bean mechanism, so you can define and use your own subclasses if needed. This can be useful, for example, if your pages, areas or components need specific configuration that you don't want to expose to editors in dialogs: the same script and the same dialog can be re-used to render totally different looking components, for example. The definition instances must be stateless as they are reused across the system.


Renderable elements (pages, areas, components) can also take advantage of a model. This is a similar to the "action" in an action-based Web framework. Model classes are instantiated per rendering. As such, they can be used to perform actions based on input, load some data, or simply provide utility methods to the templates.

The following class diagram shows the relationships between the objects collaborating in the rendering of a template.

The sequence diagram below shows the template rendering process starting from when the request passes through the AggregatorFilter in Magnolia's filter chain.

Templating support objects

To simplify scripting, templating support objects are exposed to the template script. Each object provides direct access to important Magnolia classes.

contentCurrent content node, for example ${content.header!}
defCurrent RenderableDefinition (template or area definition object)
modelThe bean created by the renderer based on the modelClass defined in the component, area or template definition. The current content, definition and the parent model are passed to the constructor.
actionResultThe result of the model's execute method. This string can be used to determine the template (in the definition) or in the template itself.
cmsfnAn object exposing several methods useful for templates. See TemplatingFunctions .
stkfnSTKTemplatingFunctions makes additional methods available for use in STK templates
ctxCurrent Context . Depending on the type of request, a different implementation will be used but for a web request to a page this will be a WebContext instance. In a web request, you can use ${ctx.contextPath} to get the context path corresponding to the current request.
stateCurrent AggregationState .
i18nMessages from the current message bundle like the "Read on" message. i18n["key"]
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))