Magnolia 4.5 reached end of life on June 30, 2016. This branch is no longer supported, see End-of-life policy.
A component is the smallest block of content that editors can edit, delete and move as a single unit on the page. At its simplest a component may be just text. However, a component can contain almost anything: a related image, a list of links or a teaser to another page. Components render content entered by editors in dialogs.
A basic component has three building blocks:
/<module name>/templates/components
folder.templateScript
property of the definition.dialog
property of the definition.Component properties common to all components are defined by the ConfiguredRenderableDefinition class as extended by the ConfiguredTemplateDefinition class. If specific subclasses are used, additional properties can be available.
You can use these common properties in any component definition:
Property | Description | Valid values |
---|---|---|
| Defines the concrete Java class to instantiate. | Fully-qualified class name. This property needs to be in appropriate Magnolia class syntax. |
deletable | Determines if component can be deleted. Set to false to prevent editors deleting the component. | true (default), false |
| Component description. Type a literal value or retrieve the value from a message bundle using a key. The message bundle is defined in the | No limitations. Conventional alphanumeric characters are recommended. Otherwise a properly defined key. |
| Path to the dialog associated with the component. |
|
| Message bundle used for the component. | Any properly defined message bundle. This value should match the message bundle set in the dialog definition. |
| Class that contains business logic for the component. The class needs to implement the
RenderingModel
interface. The renderer creates a bean based on the | Fully-qualified class name. This property needs to be in appropriate Magnolia class syntax and specifically refer to the |
moveable | Determines if component can be moved. Set to false to prevent editors moving the component. |
|
| Determines which renderer to use. Out of the box, Magnolia supports JSP and Freemarker renderers. The type for STK components is |
|
| Path to the template script used by the component. Template scripts can be stored on the file system of the webapp, in the | Conventional syntax for path definitions. |
| Title of the component. Type a literal value or retrieve the value from a message bundle using a key. The message bundle is defined in the | If typed, no limitations. Conventional alphanumeric characters are recommended. Otherwise a properly defined key. |
writable | Determines if component can be edited. Set to false to prevent editors editing the component. | true (default), false |
In the skeleton below, mandatory properties are red and optional properties are black.
Parameters can be made available to the template script in the /<component name>/parameters
node of the component definition. These properties can have arbitrary names. For example, the catCloud
component includes divClass
and headingLevel
properties.
This is how the parameters
are rendered by the categoryCloud.ftl
script.
[#-------------- RENDERING PART --------------] [#-- Rendering: Category Cloud --] <div class="${divClass}" ${divID}> [#if has_categories] [#if catCloudTitle?has_content]<${def.headingLevel!"h3"}>${catCloudTitle}</${def.headingLevel!"h3"}>[/#if] <ul> [#list categories as item] [#-- Macro: Item Assigns --] [@assignItemValues item=item /] <li class="${itemLevel}"> <a href="${itemLink}" >${itemDisplayName}</a> </li> [/#list] </ul> [/#if] </div>
Each Magnolia module can provide its own components. You can reuse and extend them to provide your own.
Here's a list documentation relevant to components: