Magnolia 4.5 reached end of life on June 30, 2016. This branch is no longer supported, see End-of-life policy.
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.
To simplify scripting, templating support objects are exposed to the template script. Each object provides direct access to important Magnolia classes.
content | Current content node, for example ${content.header!} |
def | Current RenderableDefinition (template or area definition object) |
model | The 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. |
actionResult | The result of the model's execute method. This string can be used to determine the template (in the definition) or in the template itself. |
cmsfn | An object exposing several methods useful for templates. See TemplatingFunctions . |
stkfn | STKTemplatingFunctions makes additional methods available for use in STK templates |
ctx | Current
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. |
state | Current AggregationState . |
i18n | Messages from the current message bundle like the "Read on" message. i18n["key"] |