Here we provide some essential information about important classes and interfaces in the Magnolia CMS API. These are good starting points. For more detail see Javadocs.

• Magnolia Context / Aggregation State
• Content API
• Components and modules
• Templating

Magnolia Context / Aggregation State

Context is an abstraction layer representing the environment of the current process. This can be a request process, a scheduled task or a command execution in the workflow. The context provides access to the most important components like hierarchy managers, current user, context attributes and parameters, response object and so on. The context is initialized at the beginning of each process: request, workflow step, scheduler command etc. The context attributes will have a different meaning based on the environment. In case of a request the attributes are request attributes and request parameters. Magnolia CMS implements context using a thread-local class.

• MgnlContext. This static helper class is the programmer's entry point to work with the current context.
• getInstance() Returns the current context.
• getUser() Returns the current user.
• getHierarchyManager(workspace) HierarchyManager is an entry point into the content hierarchy.
• getAttribute(name) Returns a named context attribute. In case of a request, this can be a request parameter, request attribute or session attribute.
• getWebContext() Returns the Web context if the current thread is processing a request.
• getAggregationState().
• WebContext. Context interface specialized for servlet requests; knows about HttpServletRequest and HttpServletResponse. Should be used as little as possible as it makes the calling code dependent on the servlet API. Use MgnlContext instead if possible.
• getRequest() Returns the current servlet request object.
• getResponse() Returns the current servlet response object.
• AggregationState contains information about the current request and rendering process. It is mostly initialized by the Aggregation filter.
• getOriginalURI() Original URI is the URI as requested by the client.
• getCurrentURI() URI as mapped by Magnolia CMS at a given point in processing. This value is for instance changed by the i18n filter, virtual URI mapping etc.
• getMainContent() The content with which we start the rendering process. In general this is the page node.
• getCurrentContent() The content that is processed at the moment. First this is typically the page, then a paragraph and so on.

Content API

The JCR API is wrapped inside Magnolia CMS API. You can use the JCR API as such but the Magnolia CMS API is in some cases more programmer friendly. It is simplified and independent from the JCR API. We strive to align the two APIs as well as possible.

• HierarchyManager: Magnolia CMS representation of a workspace or repository. Using the HierarchyManager you can retrieve content objects such as pages or configuration nodes. It is equivalent of the JCR Session interface.
• getContent(path)
• getContentByUUID(uuid)
• save()
• Content: Represents a node in the repository. This can be a page (type mgnl:content), a paragraph (type mgnl:contentNode) or any other kind of content. Equivalent of JCR Node interface.
• getContent()
• getChildren()
• getChildren(type)
• getNodeData(name)
• setNodeData(name, value)
• NodeData: Represents a single JCR value. Equivalent of JCR Property interface.
• getString()
• getLong()
• getStream()
• MetaData: Provides access to properties such as creation date and author.
• getCreationDate()
• getIsActivated()

Components and modules

• Components. Entry point to the ComponentProvider interface. ComponentProvider is responsible for providing components, singletons and new instances. Magnolia CMS Beans and managers are provided by this class.
• getSingleton(interface/class). Convenience method for retrieving a component.
• ModuleRegistry. Holds instances and definitions of modules.
• getModuleInstance(name). Returns the module's instance. This is useful for modules of known type.

Templating

• RenderingEngine. Entry point for the rendering.
• render(content, definition, writer). Render the content by using the passed definition.
• render(content, writer). Determines the definition from the content automatically.
• RenderableDefinition (Template/Paragraph Definition). Abstract rendering definition used for templates and paragraphs.
• getName() Name of the paragraph or template definition.
• getType() Defines the renderer to use. For instance JSP or Freemarker.
• getDialog() Dialog assigned to this paragraph or template.
• RenderingModel. The model used in the rendering process. It is instantiated for each rendering and ties the current content and rendering definition together. Concrete classes provide helper methods used in the template script. The execute() method is executed before the rendering starts, a useful place to execute any business logic. The model is available in the template script under the named model.
• getParent() Parent model. Most often the model of the page rendering.
• getContent() Content we are currently rendering.
• getDefinition() Definition used for the current rendering. This is either a paragraph or template definition.
• execute() Executed before the rendering starts.
• TemplateRenderer. Responsible for generating the actual response from request data and a template. A typical JSP implementation will simply forward the request to the JSP through request dispatcher. You can bind a specific implementation to a template type.
• renderTemplate(content, template, writer). Generates the actual output using the selected template.
• ParagraphRenderer. An interface to render paragraphs of content.
• render(content, paragraph, writer)