Voraussetzung: Entsprechende Templates in der Struktur Seite (“Page”) -> Bereich (bsplw. für Teaser, “Area”) -> Komponenten (die Teaser in diesem Beispiel, “Components”) -> Eingabemaske (für die Daten des Teasers, “Dialog”). Details zum Aufsetzen und Verknüpfen dieser Templates im letzten Post. Jedem Template außer dem Dialog wird mit dem Attribut “TemplateScript” ein Skript im Dateisystem zugeordnet (Dateiendung .ftl).
Nun sollen diese Skripte gefüllt werden. Wieder glänzt die “Dokumentation” nicht mit Details. Im Gegenteil: Ganze Bereiche werden verschwiegen, wichtige Details sind irreführend bis falsch, der Rest ist fragmentiert. Aber der Reihe nach. Im Folgenden benutze ich übrigens Freemarker, nicht JSP.
Das Page-Skript enthält eine komplette HTML-Seite. Ich hätte das gerne anders gemacht, zum Beispiel würde ich den <head> gerne auslagern, aber das ist eine extra Baustelle, die auch nicht offensichtlich dokumentiert ist. Deshalb: In diesem Beispiel ist die Page eine HTML-Seite, mit <body>, <head> und allem drum und dran. In das Skript muss im <head> ein Tag eingefügt werden, um das “Edit”-Panel zu aktivieren:
|
1 |
[@cms.init /] |
Im Body markiere ich den Teaser-Bereich mit
|
1 |
[@cms.area name="teasers" /] |
wobei “teasers” der Name des zugehörigen Content Knotens der Areas ist, siehe hier. Die Seite kann nun editiert werden; als editierbare Elemente wird der Teaser-Bereich angeboten. Dorthinein können die im Bereich erlaubten Komponenten (“availableComponents”) gesetzt werden. Per default, d.h. ohne jedes Skript, zeigt eine Area diese Komponenten dann an. Will man manuell eingreifen, etwa für umschliessendes HTML, dann kann man das Area-Skript wie folgt nachbauen:
|
1 2 3 4 5 |
<div id="myHTML"> [#list components as component ] [@cms.component content=component /] [/#list] </div> |
Die Komponenten schließlich sind stark mit ihrem “Dialog” (ihrer Eingabemaske) verknüpft, und hier beginnt die Magie. Es gibt tatsächlich kein funktionierendes Beispiel, wie man bsplw. ein Bild aus der Asset-Verwaltung im Dialog auswählen, und im Skript verlinken kann. Der Didaktik wegen erst der Dialog (Klick für große Ansicht):
Im Detail:
- Der Dialog wird in Magnolia 5 nicht mehr direkt in Tabs unterteilt, wie die Doku hier nahelegt. Stattdessen werden “actions” (Speichern, Abbrechen, etc.) und die eigentliche Eingabemaske (“form”) unterschieden (Quelle). Das hatte ich hier schon bemängelt 🙂
- Die “actions” sind ziemlich Copy&Paste
- Das Formular wird dann in Tabs unterteilt, es muss immer mindestens einen Tab geben.
- “headline”, “copy” und “button” (im Sinne von Buttontext) sind bei mir vom Typ TextFieldDefinition. Gut zu wissen: “rows” beschränkt die Zeilenanzahl nicht, es erweitert nur das Eingabefeld in der Maske. Es sind trotzdem mehr als “rows” Zeilen möglich!
- “bgImage” schließlich ist vom Typ LinkFieldDefinition:
- “contentPreviewDefinition” sorgt für die Vorschau des ausgewählten Bildes; dazu wird die “contentPreviewClass” auf info.magnolia.dam.asset.field.DamFilePreviewComponent gesetzt.
- “appName” ist analog zur Doku “assets”, “class” ist ebenfalls analog zur Doku, “label” ist Freitext
- “targetWorkspace” hat sich in Magnolia 5 ebenfalls geändert; statt “dms” muss es “dam” sein! Andererseits hatte es bei mir auch keine Auswirkungen, wenn ich das einfach weglasse^^
- “identifierToPathConverter” hatte bei mir keine sinnvollen Auswirkungen, so wurde zum Beispiel nie der Pfad zur Datei ausgegeben, vgl. unten
So, nun hat man Texte und ein Bild im Dialog der Komponente – wie spricht man diese im Skript der Komponente an? Die Texte sind einfach:
|
1 2 3 |
<h2>${content.headline!}</h2> <p>${content.copy!}</p> <a href="#">${content.button!}</a> |
Das Bild dagegen würde mit
|
1 |
<img src="${content.bgImage!}" /> |
nur den Pfad des Objekts in der Asset-Verwaltung ausgeben, etwa /myTeasers/teaser_1. Das wäre nicht mal eine URL zu der Grafik dahinter, wenn hier ein “.jpg” dranhinge. Stattdessen muss man den “Content” zu diesem Pfad erst auslesen, und dann in einen “Link” konvertieren:
|
1 2 |
[#assign bgImage = cmsfn.contentByPath("${content.bgImage}","dam")] <img src="${cmsfn.link(bgImage)}" / |
Hier ist interessant, dass “cmsfn” vom Typ TemplatingFunctions im Template-Skript zur Verfügung steht. Muss man wissen 🙂 Was jetzt vielleicht noch so verfügbar ist, weiß ich nicht, aber für Hinweise bin ich dankbar!
HTH
Hi HTH!
Sie haben mir soeben einen weiteren furchbaren Tag erspart. Ich war gestern schon sehr lange damit beschäftigt, das Bild aus der LinkFieldDefinition richtig in meinem template einzubinden. Schuld war nun letztendlich der identifierToPathConverter. Dieser war im Dialog noch immer gesetzt und dadurch wurden auch nicht die richtigen Daten geliefert.
Herzlichen Dank
🙂 Freut mich!
PS: “HTH” heißt “Hope This Helps”