Magnolia 5.6 reached end of life on June 25, 2020. This branch is no longer supported, see End-of-life policy.
This page provides a high-level overview of Magnolia apps.
Apps are important building blocks of Magnolia, providing segmented, task-oriented functionality to different users. Technically speaking, an app is simply a UI extension point. How you extend the UI depends on your needs and the needs of your users. Thanks to Magnolia's open architecture, the limits of the app approach are boundless, meaning you can tailor the experience of target work groups by customizing the UI and existing apps - and by creating new apps as needed.
All apps are implemented using the App framework, whether they are apps provided by Magnolia or your own custom-built apps. Because content is at the heart of Magnolia, there is a specific framework subset dedicated to creating apps that manage content; apps created using this framework subset are referred to as content apps. Some examples of content apps are the Pages and Assets apps, some non-content app examples are the Log Tools and About Magnolia apps.
Apps typically contain subapps. Generally, the app provides basic functionality such as how to open sub-apps and provide communication between subapps; whereas the subapps provide the functionality, for example, for managing content and operating on one specific workspace in the JCR. In the case of content apps, the standard subapps are the browser subapp and a detail subapp. Subapps are typically displayed to users as tabs.
Apps provide many advantages, both from a technical standpoint and for end-users.
Many apps are provided by Magnolia and can be used out-of-the-box. You can also customize these apps or create your own Magnolia apps from scratch.
See Choose the right app type for guidance in choosing whether to extend an app or create a new one.
Magnolia apps all provide the same look and feel, navigation and behavior because they all run in the same Magnolia Shell. Magnolia assists you in extending apps or creating new apps that follow the same rules so all users have a single point of reference.
From a developer point of view, questions about how to design website navigation and action menus become redundant as the navigation is ready made.
From an end-user point of view, standardization makes apps easy to use and learn. Since all content apps look and behave the same way, a user who has used one can quickly learn another, even if the apps operate on different content.
Apps run independently from one another. When you launch an app and then navigate to another app, the first app stays open until you come back and close it. If you navigate from an app to the app launcher, the icon for the open app is highlighted and the app remains visible in the background. This means you can switch from one app to another or the app launcher without losing any information (even if you didn't save before switching).
For example, an author editing a page in the Pages app and decides to include an image from the Assets app. The author may add a text and image component to the page and opens the Asset chooser dialog to add an image. The list of images available is sourced from the Assets app within the page editor.
Using apps, you can connect Magnolia to multiple third-party systems, tools and data sources. Although many apps use data stored in the Java Content Repository (JCR), you can use Magnolia apps to access data anywhere while retaining a familiar working environment for your users: they always work in Magnolia apps and the apps connect to the outside world. You can store content in a database, cloud storage or a Web service.
Some common examples of this are:
Your company uses Amazon S3 to store large assets: the Amazon S3 Connector module provides an app that allows users to manage assets in Amazon S3 while using them in Magnolia.
View a full list of third-party systems, tools and data sources Magnolia enables you to connect to on the Integration page.
Apps are well suited to developing tools for very specific purposes. Consider an app as a tool with a very narrowly focused interface that enables you to work on one set of closely related tasks or one specific set of data from a single location. An example of a task-oriented app is the Content translation app, where the app allows you to manually export and re-import page content in a translation-friendly format.
An app does not necessarily work on a single, physical data set (such as the pages of a site) but may cover multiple physical data sets required to solve the task or tasks it covers. In the case of content apps, the focused interface can be a tool that lets editors work on one task at a time, such as editing a page.
In addition to each app being intended for a specific purpose, you can organize the apps in Magnolia's interface into groups. In the example below taken from Magnolia's demo site, all the content apps are grouped in the Edit group and the Set Up group brings together all the administration apps. You can reorganize these groups, remove them and create your own in the app launcher layout.
Once you have apps, and have grouped them to suit your project, you can decide who gets to see what. With Magnolia's provisioning functionality you can decide which users see which apps or app groups depending on their role. Once logged in, different users see exactly what you want them to see. No clutter and no searching for apps.
For example, the screenshots below show the difference between what the superuser sees and what Eric (an editor) sees: