This page illustrates key Magnolia concepts. Find a description for each diagram on the linked pages.
| Thumbnail | Comment | Page |
| Magnolia uses Jackrabbit clustering to share content between instances. In the diagram, each Magnolia instance uses its own persistent storage for website, dam and config workspaces. But the comments workspace is stored in a clustered database. | |
| This diagram shows the building blocks you need to a create a custom content app. | |
| A content repository is designed to store, search and retrieve hierarchical data. The data is in a tree of nodes and properties. Properties may store simple values such as numbers and strings or binary data such as images. | |
| Java Content Repository (JCR) is a standard interface for accessing content repositories. It decouples content storage from content management and provides a common API for content reuse across the enterprise and between applications. | |
| Data store deployment option 1: Completely separate instances. Each instance has a dedicated database and runs on different physical hardware. This setup is good for zero downtime. | |
| Data store deployment option 2: Centralized database server. A centralized database server holds the copies of JCR repositories for each instance. But the instances run in separate virtual machines. This setup is performant but not disaster tolerant. | |
| Data store deployment option 3: Clustered data store. All public instances run in a cluster. | |
| Magnolia is distributed as two webapps: author and public. Editors work on the author instance publishes content to public instances which serve it to visitors. | |
| Each public instance can serve content targeted for a specific geographical area. For example, one instance serves visitors from Europe and another visitors from the U.S. | |
| Place secure and sensitive content on separate instances. This diagram shows a possible placement strategy where a public extranet instance resides on its own instance and has its own URL. | |
| Magnolia instance configurations start from a standard 3-instance setup and scale up. You can add any number of instances for load balancing and high availability. Public instances can subscribe to specific content such as intranet or extranet. | |
| Modules are independent and pluggable in the sense that you can add and remove them at will. Your module can have a dependency to Magnolia core, your templating kit, or another module. | |
| Package your modules and resources in a JAR or ZIP file and deploy to production in a controlled manner. The level of environmental control and testing required depends on your client. Consider segregating development, test and production environments. | |
| Rendering is the process where templates are merged with content. Rendering generates a stream of HTML that can be displayed in the browser. The rendering filter submits a content node to the rendering engine. | |
| Early execution of components. Sometimes components need to execute model code before page rendering starts. This is necessary for operations such as forwarding and redirecting. | |
| Object hierarchy in a JCR repository. A repository contains workspaces. Each workspace contains nodes under a single root node. A node contains properties which store values (data). | |
| Request processing and filter chain. In the Magnolia filter chain, filters are executed one-by-one until a filter decides that it can fulfill the request. | |
| Elements that make up the Magnolia template mechanism such as template definition and template script. | |
| Disaster recovery
Benefits:
|
Overview
Content Tools