This page shows how to create an app that operates on data stored outside the JCR repository. The app uses the content app framework but stores data on the local file system. This is an example of connecting to a custom data source. Editors don’t have to leave Magnolia in order to work on third-party data.
Background
The data that content apps operate on is typically stored in the Java Content Repository (JCR). However, apps can also operate on data that resides outside the JCR.
Editing and viewing custom data is a common requirement. For example, editors may need to access product data in a remote ERP system in order to create content to sell the products. Such remote data can reside in a relational database, on the filesystem, in a Web service, or some other data delivery service. For convenience, you want to make the remote data available inside Magnolia in a familiar environment so editors don’t need to jump from one system to another.
This tutorial requires that you have some Java programming experience. You need a development environment and a basic understanding of Magnolia modules. You will work with interfaces originating from the Vaadin framework used to build the Magnolia UI.
Create a module
The app you are about to develop is called the File System Browser app. It is a simple app which connects to the file system and allows you to edit images from it.
The app needs to be deployed as a Magnolia module. Choose from the following options depending on your skill level.
Option 1: Clone the project in Git
Choose this option if you know how to work with Magnolia projects and Git. You get the module code on your local system and can edit it in your IDE.
Build the project into a JAR and deploy it to a Magnolia instance or run the project in your IDE. To run it in the IDE, add the module as a dependency in the POM file of your bundle, as described in the next option.
Option 2: Add the project as a dependency to your bundle
Choose this option if you want to add the project to your own Magnolia bundle. The module code will not be stored on your local system. Add the following dependency to your bundle:
Alongside the data source definition and item resolver, you need to implement data source providers to be used within browser presenter classes. Usually, you need to define:
A filterable (flat) data provider (info.magnolia.filesystembrowser.app.contentview.FSDataProvider) which implements item fetching by query.
A hierarchical provider which implements fetching of children of a given data element (info.magnolia.filesystembrowser.app.contentview.HierarchicalFSDataProvider).
Workbench is a view that displays a list of content items in a workspace. It is typically defined in the browser subapp.
The workbench contains a list of content views, such as tree, list and thumbnail — the most common view types available in a typical JCR content app. Other view types can be defined as well.
For each view type, you need to implement a custom presenter — a presenter attached to the right data provider. The following are the base presenter classes in the info.magnolia.ui.contentapp.browser package.
ListPresenter
TreePresenter
ThumbnailPresenter
Once you have implemented the classes, you must provide type-mapping of the presenters. This is done in the module descriptor.
Implementing action classes to operate on custom content
Your data source is now anchored in the content app and is ready to be used. The next step is to create actions and the Action bar so that the user of the app could work with the content items.
You can start with info.magnolia.filesystembrowser.app.action.DuplicateFileAction, for example. This action execute method takes a single item from value context (that is an item or a file which is selected in the browser) and duplicates it within the filesystem.
All parts of the app are now ready and the app’s configuration can be finalized in the app descriptor. See below a complete YAML definition of the fs-browser-app: