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.

(mehr …)

Magnolia Apps (Teil 1) – Einführung – Yet another App definition?

Seit der Einführung des App Store durch Apple im Jahr 2008 hat sich der Begriff „App“ für Anwendungssoftware etabliert und wird meistens mit „Mobile App“ assoziert. Mittlerweile wird der Begriff aber auch für Web-Anwendungen und sogar Desktop-Anwendungen verwendet.

Auch Magnolia bietet ab der Version 5 (mittlerweile auch schon seit zwei Jahren) die Möglichkeit „Apps“ zu entwickeln. Was aber heisst das im Magnolia Kontext? Kann man mit Magnolia jetzt Anwendungen fürs iPhone bauen? Was für Arten von „Magnolia Apps“ gibt es überhaupt, wo liegen die Unterschiede und welche verwendet man wann? (mehr …)

Umgebungsspezifische Konfigurationen in Magnolia CMS

Einführung

Wenn ich ein grösseres Magnolia Projekt mit verschiedensten Instanzen aufsetze (local development, development, staging, integration, production), stellt sich früher oder später die Frage,  wie ich verschiedene Konfigurationen kontrolliert auf die verschiedenen Instanzen installieren kann.

In diesem Blog Post zeige ich einen einfachen Lösungsansatz auf, der sich beliebig erweitern und auf projektspezifische Bedürfnisse abstimmen lässt.

Problemstellung

Magnolia bringt out-of-the-box bereits einen Mechanismus mit, der umgebungsspezifisches Einspielen von XML Bootstrap Files erlaubt. Dieser Mechanismus ist aber beschränkt auf die Initialisierung des JCR Repositories und erlaubt deshalb weder das Einspielen von Updates via XML Files, noch eine Interaktion mit Java Code.

Im Laufe eines Projektes kommt oft der Punkt, an dem ich ein Update / Delta Task nur auf einem oder mehreren bestimmten Systemen ausführen möchte. Dazu zählen zum Beispiel das Ändern des SMTP Server im Mail Modul, oder das Aktualisieren eines Subscribers. Zudem kann es auf der lokalen Entwicklungsumgebung sinnvoll sein, bei jedem Neustart des Systems einen Teil der Konfigurationen neu zu schreiben, um die Entwicklung auf einem sauberen Stand zu starten oder Änderungen von anderen Entwicklern im eigenen Repository zu sehen.

Lösungsansatz

Im magnolia.properties File wird ein neues Property magnolia.environment definiert, welches den Namen der Umgebung beinhalten wird.

magnolia.properties

...
magnolia.environment = <env_name>
...

Dieser Lösungsansatz erfordert lediglich, dass für jede zu unterscheidende Umgebung ein eigenes magnolia.properties File existiert, was aber in grösseren Projekten weitgehend der Fall sein sollte.

Das neue Property wird durch eine simple Java Hilfsklasse ausgelesen, und erlaubt auf einfache Weise das Unterscheiden der verschiedenen Umgebungen, insbesondere der lokalen Entwicklungsumgebung. 

(mehr …)