Apache Sling Models – Teil 2 – Hands-On

Mit der neuen Erweiterung Apache Sling Models bietet Apache Sling unter anderem die Möglichkeit über Annotations Objekte mit Inhalten des Repositories zu befüllen. In diesem Hands-On wird erklärt, wie Apache Sling Models anhand konkreter Beispiele in der aktuellen Version Adobe AEM 5.6.1 eingesetzt werden kann und was dabei zu beachten ist. Eine Einführung in das Thema gibt es im ersten Teil dieser Blog-Serie.

Apache Sling Models ist neu
Apache Sling Models ist ganz frisch und daher noch nicht praxiserprobt. Dieses Hands-On ist eine Aufforderung diese Erweiterung zu testen. Wie gut sich diese in der Praxis bewährt, wird sich noch zeigen.

Benötigte OSGI-Bundles
AEM 5.6.1 bringt die OSGI-Bundles für Apache Sling Models nicht mit. Die entsprechenden Bundles müssen daher installiert werden. Apache Sling Models selbst besteht aus den folgenden beiden Bundles:

org.apache.sling:org.apache.sling.models.impl:1.0.0
org.apache.sling:org.apache.sling.models.api:1.0.0

Damit die Models direkt in JSPs verwendet werden können, gibt es eine Erweiterung der Sling JSP Scripting Taglib um den Tag sling:adaptTo. Damit dieser Tag verwendet werden kann, muss das entsprechende Bundle in AEM 5.6.1 mit der aktuellsten Version aktualisiert werden:

org.apache.sling:org.apache.sling.scripting.jsp.taglib:2.2.0

Die URI der neuen Version der Taglib unterscheidet sich von der älteren und enthält neu keine Versionsnummer mehr. Die neue Taglib muss wie folgt registriert werden kann (beispielsweise über ein global.jsp).

<%@taglib prefix="sling" uri="http://sling.apache.org/taglibs/sling" %>

Eigenes OSGI Bundle anpassen
Damit die Models durch die neue Erweiterung in einem eigenen OSGI-Bundle verarbeitet werden können, müssen im Manifest des Bundles die Models respektive Packages angegeben werden:

<Sling-Model-Packages>
 com.namics.example.sling.models
</Sling-Model-Packages>

Code-Beispiel
Im OSGI-Bundle kann nun ein POJO erzeugt werden, welches mit den entsprechenden Annotations zum Sling Model wird.

@Model(adaptables = Resource.class)
public class Example {

    @Inject
    private String title;

    public String getTitle() {
        return title;
    }

}

Dieses Beispiel lässt sich nochmals vereinfachen. Es wird keine konkrete Implementierung des Models benötigt, ein Interface genügt:

@Model(adaptables = Resource.class)
public interface Example {

    @Inject
    public String getTitle();

}

In einem entsprechenden JSP kann dann auf dieses Objekt zugegriffen werden:

<%@include file="/apps/sling-models-example/global.jsp" %>
<sling:adaptTo adaptable="${resource}" adaptTo="com.namics.example.sling.models.Example" var="model"/>

<h2>${model.title}</h2>

In einer entsprechenden AEM-Komponente mit einem Dialog, welcher eine Property title schreiben kann, kann Apache Sling Models dann konkret getestet werden. Der Titel wird automatisch anhand des Namens der Methode oder Attributes geladen, soweit dieser über @Inject annotiert ist.

Dokumentation
Der folgende Link zu Apache Sling bietet weitere Details zu Apache Sling Models.

Erstes Fazit
Apache Sling Models ist eine interessante Erweiterung von Apache Sling. Sie bietet gute Möglichkeiten, um Adobe AEM/CQ Code besser zu strukturieren und die Qualität in Projekten zu erhöhen. Zudem lässt sich Apache Sling Models über ein Service Provider Interface (SPI) auch für projektspezifische Belange erweitern.

Apache Sling Models – Teil 1 – Vorstellung

Apache Sling ist ein Web-Framework und Basis von Adobe CQ/AEM. Es bietet eine nahtlose Integration zum JCR-Repository Apache Jackrabbit über die eigene Resource-API. Mit der neuen Erweiterung Apache Sling Models bietet Apache Sling nun die Möglichkeit über Annotations Objekte mit Inhalten eines Repositories zu befüllen oder auch OSGI-Services zu injizieren. Über einen JSP-Tag lässt sich ein solches Objekt erzeugen und in einem JSP-Template darauf zugreifen.

Welche Probleme löst Apache Sling Models?
Apache Sling Models basiert auf dem Adapter-Interface von Sling. Damit lassen sich beliebige Objekte in andere transformieren (adaptTo), soweit die entsprechende Transformation unterstützt wird. Dies wird auch durch Apache Sling Models verwendet. Ein Sling Resource-Objekt, welches beispielsweise Properties eines Blog-Eintrages enthält, kann mit resource.adaptTo(Example.class) über Sling Models direkt in ein entsprechendes POJO transformiert werden. Das POJO selbst hat abgesehen von Annotations keine Abhängigkeiten zum Sling Framework. Es lässt sich so beispielsweise besser mit JUnit testen und wird insgesamt einfacher.

Aktuelle Praxis
In unseren aktuellen Adobe AEM/CQ-Projekten werden ähnliche Ansätze, wie Apache Sling Models bietet, bereits verwendet. So verwendet Namics seit einigen Jahren eine eigene, auf Annotations basierendes Bibliothek. Ein wichtiger Vorteil für uns ist da die Trennung von Code und Templating. Die JSPs können ausschliesslich als Templates verwendet werden und die Logik ist in Java-Code enthalten. Dies erhöht die Code-Qualität einerseits durch das Design, andererseits auch durch bessere Testing-Möglichkeiten.

Beispiel
Das folgende Beispiel zeigt, wie ein einfaches Sling Model aussehen und verwendet werden kann.

@Model(adaptables=Resource.class)
public class Example {

@Inject
private String title;
}

Example example = resource.adaptTo(Example.class);

Im zweiten Teil dieser Blog-Serie wird das Beispiel näher erklärt und gezeigt, wie die ersten Schritte mit Apache Sling Models in AEM 5.6.1 durchgeführt werden können.

Pathmarks – Kleines Helferlein für AEM/CQ mit Google Chrome

Der Adobe Experience Manager (AEM) respektive CQ ist ein mächtiges System. Entsprechend vielfältig sind die Funktionen und alle sind irgendwie über URL-Pfade erreichbar. Wer mit AEM respektive CQ entwickelt oder mehrere Instanzen und Umgebungen (Produktion, Test, Integration, Entwicklung etc.) betreut, ruft daher auf den jeweiligen Systeme immer mal wieder dieselben Pfade auf. Die Hostnames (und/oder Ports) ändern sich natürlich, die Pfade bleiben aber dieselben. Einige Pfade sind irgendwann im Gedächtnis präsent, von einigen ist bekannt, wo im System ein Link darauf vorhanden ist und bei anderen, wo in der Dokumentation der gewünschte Pfad zu finden sein könnte. Es gibt aber immer auch mal die Situation, wo auf einem System das Ziel bekannt ist, der Weg allerdings neu gesucht werden muss.

Mit der Google Chrome Extension Pathmarks gibt es ein praktisches Helferlein, welches diese Suche nach dem gewünschten Pfad stark erleichtert. Anstelle eines klassischen Bookmarks speichert die Erweiterung nur die Pfade. Egal in welcher AEM oder CQ Umgebung – mit einem Klick auf den gespeicherten Pfad wird die Zielseite in der aktuellen Umgebung geöffnet.

Der aktuelle Pfad einer geöffneten Seite lässt sich mit der Erweiterung direkt speichern und zuvor auch editieren. Die einzelnen Einträge lassen sich per Drag-and-Drop umsortieren. Über die Options-Seite der Erweiterung stehen die gespeicherten Pfade ausserdem im JSON-Format zur Verfügung. Die Einstellungen können so einfach zwischen Entwicklern ausgetauscht werden. Über die Tastatur lässt sich schnell zwischen den Pfaden navigieren und den gewünschten auswählen.

Natürlich eignet sich diese Extension für Google Chrome auch für beliebige andere, web-basierte Systeme.

Pathmarks im Chrome Web Store

Suchtiefe der AEM CQ Volltext-Suche bei Seiten-Inhalten

Die integrierte Volltextsuche von AEM CQ nach Seiten (cq:Page respektive cq:PageContent) besitzt eine wenig bekannte Einschränkung. Die Suche findet nur auf vier Node-Ebenen innerhalb des PageContent-Nodes (jcr:content) statt.

Diese Einschränkung fällt oft nicht auf, da eher selten eine tiefere Node-Struktur anzutreffen ist. Es gibt aber Fälle, wo komplexe Komponenten tiefere Strukturen aufweisen und die Inhalte dann mit der Volltextsuche nicht mehr gefunden werden. Beim Testen ist die Wahrscheinlichkeit eher klein diesen Fall zu erkennen. Daher ist es wichtig diese Einschränkung zu kennen und in der Entwicklung bei der Verwendung tieferer Node-Strukturen zu beachten. (mehr …)

Erster Blick auf Launches in Adobe CQ 5.6

Adobe wird in CQ 5.6 die neue Funktion Launches zur Verfügung stellen. Mit Launches können mehrere Versionen von Seiten oder ganzen Bereichen parallel bearbeitet und später veröffentlicht werden. Im Februar kann beispielsweise bereits an einem Frühlings- und Sommer-Launch einer bestimmten Seite gearbeitet werden. An der aktuellen Winter-Version können weiterhin Anpassungen gemacht und live geschaltet werden.

Erster Blick auf Launches

Namics konnte im Rahmen des Adobe CQ 5.6 Beta Programmes einen ersten Blick auf Launches werfen. Ein neuer Launch kann im Siteadmin erstellt werden. Beim Erstellen ist definierbar, ob eine Seite, oder ein ganzer Seiten-Bereich für den neuen Launch verwendet wird. Technisch ist ein Launch eine Kopie der Original-Seite (angelegt unter /content/launches). Ein Launch kann wahlweise als Live-Copy konfiguriert werden und damit sind auch Funktionen des Multi-Site-Managers nutzbar.

Eine Launch-Version wird wie eine normale Seite bearbeitet. Im Sidekick kann zur gewünschten Launch-Version gewechselt werden. Über die neue Funktion Promote Launch wird eine bestimmte Launch-Seite veröffentlicht.

Für die Administration der Launches steht in CQ 5.6 zudem eine neue Oberfläche (aufrufbar über /libs/launches/content/admin.html) zur Verfügung. Damit können bestehende Launches konfiguriert und auch wieder gelöscht werden.

Launches in bestehenden Projekten?

Wir haben uns gefragt, ob sich Launches auch bei einem Update von einer älteren CQ-Version auf CQ 5.6 verwenden lassen? Dies ist grundsätzlich möglich, hängt aber jeweils auch vom entsprechenden Projekt ab. Damit sich die Launches verwenden lassen, benötigt eine Page den cq:infoProvider für Lauches. Im entsprechenden Node launches wird eine Property className mit dem Wert com.adobe.cq.wcm.launches.impl.LaunchesInfoProvider benötigt. Je nach Projekt-Setup muss dies im Projekt-Code oder via CRX DE konfiguriert werden. Anschliessend können Launches verwendet werden.

Bei bestehenden Projekten muss zudem berücksichtigt werden, dass die Launch-Version im Pfad /content/launches als Kopie des Originals abgelegt wird. Automatisch generierte Bereiche, wie beispielsweise eine Navigation können je nach Umsetzung daher im Launch nicht sichtbar sein.

Fazit

Launches ist eine sehr interessante neue Funktion von Adobe CQ 5.6, welche für die Content-Pflege grosse Vorteile mit sich bringt. Wir können uns vorstellen, dass gerade auch kritische Veröffentlichungen (beispielsweise von Geschäftszahlen) davon profitieren können. Die Integration in bestehende Projekte im Rahmens eines Updates wird auch möglich sein und wir sind gespannt auf den ersten Einsatz in der Praxis.

Weitere Artikel zu Adobe CQ 5.6 Beta: Adobe CQ 5.6 Commerce – Einkaufen mit CQ