Magnolia Apps (Teil 2) – Technischer Background an Hand der pages App

Im ersten Teil meiner Serie habe ich kurz skizziert, was eine Magnolia App ausmacht und welche Kategorien von Apps es gibt. In diesem zweiten Teil konzentriere ich mich auf das Thema Content App, da es aus meiner Sicht für uns Implementierer der Bereich mit der grösseren Auswirkung ist.

Startpunkt für den User und entsprechend auch für App Entwickler ist die Admincentral. Die Anzeige der Apps in der Admincentral wird konfiguriert in der Magnolia Config unter /modules/ui-admincentral/config/appLauncherLayout.

appLauncher

Magnolia Config: AppLauncher

Wollen wir eine neue (eigene) App registrieren muss an dieser Stelle ein entsprechender Knoten eingefügt werden. Über die Unterknoten „permissions“ kann definiert werden, welche Rolle ein Benutzer benötigt damit eine Gruppe von Apps angezeigt wird. Desweiteren kann auf Gruppenebene definiert werden, welche Farbe die Gruppe im admincentral hat, bzw. ob sie immer geöffnet dargestellt werden soll (Property: permanent).

Der Name der App, die hier definiert wird, wird reflektiert durch den Namen der App also beispielsweise /modules/pages/apps/pages@name in der Magnolia Config.

Wie eine Content App aufgebaut ist kann man sehr gut an Hand der pages App in der Magnolia Config nachvollziehen (/modules/pages/apps/pages/subApps):

pagesAppConfig

Magnolia Config: Pages App

Wie man im Screenshot schön sieht, ist eine Content App weiter in subApps strukturiert. Die browser subApp dient in diesem Zusammenhang dazu, die Daten in Form einer Liste oder eines Baumes darzustellen, welche Darstellungsformen es gibt wird unter workbench/contentViews definiert. Die detail subApp dient der Datenerfassung und -bearbeitung. Hier sieht man auch gut, welche Standard Content App Klassen Magnolia zur Verfügung stellt. Nämlich im Fall der Browser Sub App die Klasse info.magnolia.ui.contentapp.browser.BrowserSubApp, die ihrerseits von der Klasse info.magnolia.ui.framework.app.BaseSubApp ableitet.

Unterhalb der Knoten actions und actionbar lassen sich mögliche Aktionen auf den Daten definieren, die genauso von einer Magnolia Standard Klasse ableiten sollten. In dem Fall wäre das die Klasse info.magnolia.ui.api.action.AbstractAction.

Wichtig ist der Knoten „contentConnector“. Dieser definiert, welche Daten in dem Browser oder auch im Detail angezeigt werden sollen. Zur Definition können NodeTypes in Workspaces definiert werden. Über den „rootPath“ kann zusätzlich definiert werden, dass die App auf tieferliegende Knoten innerhalb eines Workspaces zugreift. Auch hier bietet Magnolia die Flexibilität, für jede subApp einen anderen „contentConnector“ zu definieren, wie z.B. in der Security App .

Fazit:

Für Entwickler ist es wichtig, die Struktur in der App Konfiguration zu kennen um eigene Apps entwickeln zu können oder auch, um Standard Apps zu erweitern. Kennt man diese, ist das Entwickeln eigener Magnolia Apps nicht zu komplex. Zudem bietet auch Magnolia hier sehr gute Dokumentationen welcher sich jeder App Entwickler einmal ansehen sollte:

https://documentation.magnolia-cms.com/display/DOCS/Apps

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>