ZOO - CCK Komponente für Joomla!

Templates und Overrides von ZOO

Für die Darstellung von Artikeln nutzt ZOO eigene Templates, welche sich im Template-Ordner der Frontend Komponente befinden (/components/com_zoo/templates/). Die mitgelieferten Templates sind auf die ebenfalls mitgelieferten Artikeltypen zugeschnitten. So ist das "Produkte"-Template auf die Ausgabe von Artikeln des Typs "Products" hin entwickelt worden. Der Name des Templates kann frei gewählt werden. Erst bei der Erstellung des Menüpunktes wählen Sie welcher Katalog/Kategorie mit welchem Template dargestellt werden soll.

Im Template Ordner von ZOO befinden sich verschiedene Dateien, welche für die Darstellung von Katalog-, Kategorie- oder Artikelansichten genutzt werden. Möchte man die Darstellung der Inhalte beeinflussen, muss man natürlich an die Templates gehen. Entweder man erstellt für ein Kundenprojekt ein neues Template, oder man erweitert ein Vorhandenes. Um die, teils mitgelieferten, Templates der ZOO-Komponente nicht direkt anfassen zu müssen, bieten sich Overrides an. Aber auch bei neu erstellten Templates sind die folgenden Techniken anwendbar. In diesem Fall kann man die Overrides direkt im neu erstellten ZOO Template Ordner anlegen.

Was sind Overrides?

Im Prinzip ermöglichen sogenannte Output-Overrides eine Beeinflussung der Ausgabe von Inhalten, welche aus einem CMS wie Joomla! kommen. Wenn Sie sich beispielsweise einen Artikel im Frontend Ihrer Website ansehen, wird dieser, wie es bei Webseiten üblich ist, mit Hilfe von XHTML-Strukturen dargestellt. Wenn Sie als Template Ihrer Website das bei Joomla! mitgelieferte "Purity" nutzen, werden Sie feststellen, dass ein Artikel-Titel wie folgt ausgegeben wird: 

<h2 class="contentheading">Google freut sich</h2>

Das ist ziemlich OK. Das liegt daran, dass hier ein Template Override am Werk ist. Das Purity-Template beinhaltet nämlich ein Override u. a. für die Ausgabe von Artikeln. In diesem Override wird der darzustellende Inhalt möglichst suchmaschinenfreudlich und semantisch sinnvoll ausgegeben. Das Override, welches hier zum Einsatz kommt, befindet sich im Verzeichnis /templates/ja_purity/html/com_content/article/ und heisst default.php. Es ist zuständig für die Darstellung eines einzelnen Artikels. Wenn Sie diese Datei löschen (oder besser umbenennen), funktioniert die Darstellung des Artikels zwar weiterhin, allerdings wird z. B. der Titel nicht mehr so optimal ausgegeben:

<table class="contentpaneopen">
<tbody>
<tr>
        <td width="100%" class="contentheading">Google freut sich (nicht)</td>
</tr>
</tbody></table>

Das liegt daran, dass wir nur das Override gelöscht haben. Joomla! greift bei Nicht- Vorhandensein eines solchen auf die komponenteneigene Ausgabe von Inhalten zurück (hier der View von com_content). Um nicht zu weit in das MVC-Prinzip abzutauchen, sei hier nur erwähnt, dass bei Joomla! eine Datei die Darstellung von Inhalten erledigt, welche als "View" also Ansicht bezeichnet wird. Diese beinhaltet kaum Funktionalitäten, dafür aber umso mehr XHTML, um Inhalte auszugeben. Durch diese Abstraktion kann man nun einen View durch einen anderen ersetzen. Das nennt man einen Override.
Overrides sind also keine vitalen Funktionsgruppen des Systems. Sind sie nicht vorhanden, wird die Standardausgabe genutzt. Sie helfen jedoch einerseits volle Kontrolle über die Ausgabe von Inhalten zu haben (ohne an die Joomla! Innereien zu müssen) und ermöglichen andererseits das individuelle Stylen von Inhalten anhand beliebiger Bedingungen.
Dieser beider Prinzipien bedient sich ZOO für die Darstellung seiner Inhalte in vollem Umfang.

Eine ausführliche Definition der Override Technik von Joomla! kann in einem Blogeintrag, welchen ich für das Schweizer Joomla! Portal unter dem Titel "Ein Königreich für ein Override" geschrieben habe, nachgelesen werden.

Kategorie Overrides

Die Override-Möglichkeiten bei ZOO sind ausgesprochen vielfältig. Im Prinzip lässt sich jede Content-Konstruktion auf verschiedenen Ebenen durch Overrides beeinflussen. Das ist gut, wenn fähige Leute am Werk sind, die wissen welches Override in welches Verzeichnis gehört und warum ein Artikeltyp-Override von einem Itemoverride überschrieben wird. Ich würde aber behaupten, dass für einen normalen User die komplexen Override Möglichkeiten nicht handhabbar und wahrscheinlich auch nicht verständlich sind.
Dies sehe ich nicht als Nachteil, da hohe Flexibilität einen gewisse Komplexität vorraussetzt. Falls weniger bewanderte Nutzer ZOO eingesetzen wollen, werden sie sich gar nicht auf die Overrides Ebene begeben, sondern die bei ZOO mitgelieferten "von der Stange"-Templates nutzen.

Override Prioritäten
Overrides basieren auf einem Prioritäten Konzept. Bei dem oben erwähnten Override für einen Artikel, handelt es sich um ein Template-Override. Ist dieses Override im richtigen Verzeichnis des Templates, ersetzt es den Standard-View von Joomla!. Das Template-Override hat also eine höhere Priorität bei der Darstellung von Daten als der Joomla! interne View. Dieses Prinzip wiederholt sich bei ZOO an verschiedenen Stellen. Man kann ein allgemeines Override definieren, welches den Standard-View ersetzt. Dann kann ein Katalog basiertes Override erstellt werden, welches das Vorige überschreibt. Schließlich kann sogar ein ID basiertes Override erstellt werden, welches die höchste Priorität hat und alle vorigen überschreibt.

Wer bei ZOO aus dem Vollen schöpfen will, wird an eigenen Overrides nicht vorbeikommen. Hier gibt es einige Handgriffe, die zwar logisch sind, in der Handhabung so manchen Nutzer aber etwas verwirren werden. Nehmen wir als Beispiel einen Menülink, welcher auf den ZOO Katalog Downloads verweist. Denken Sie daran, dass ein Katalog die oberste Ebene einer beliebigen Struktur von Kategorien ist. Innerhalb dieses Katalogs befinden sich verschiedene Artikel, die wir zuvor angelegt und dem Katalog zugeordnet haben.

Bei der Erstellung eines Menüpunktes müssen wir uns für die darzustellende Kategorie und für das Template entscheiden, welches die Inhalte dieser Kategorie darstellen soll. Logischerweise nehmen wir hier das mitgelieferte Download-Template. Wenn wir uns die Seite anschauen, sehen wir, dass die Artikel im entsprechenden Download-Look dargestellt werden. Schön. Nun wechseln wir (noch immer in der Bearbeitung des Menüpunktes) auf das Template Blog Classic. Die Artikel erscheinen nun in einem anderen Layout. Soweit so klar.

Nun erstellen wir ein Override. Im ZOO Override Verzeichnis für Kategorien templates/IHRTEMPLATE/html/com_zoo/category/ erstellen wir ein Verzeichnis mit dem Namen downloads. Darin werden die nötigen Override-Dateien gelegt. An dieser Stellen reichen einfach die catalog.php und die category.php. Um einen Effekt zu sehen, tippen wir ein paar Worte in das Katalog-Override catalog.php. Wenn wir nun die Seite neu laden, sehen wir, dass die Artikel nicht mehr im zuletzt festgelegten Look des Templates "Blog Classic" dargestellt werden. Das Override hat zugeschlagen! Die Zeichen, welche Sie eingetippt haben, sollten irgendwo erscheinen. Nun gehen wir zurück in die Bearbeitung des Menüpunktes und wechseln das zugewiesene Template Blog Classic auf ein beliebig anderes, beispielsweise auf "Downloads". Was tut sich im Frontend? Nichts! Warum?

Das erstellte Override im Verzeichnis Downloads hat eine höhere Priorität, als das im Backend zugewiesene Template. Da unser Override im Verzeichnis downloads liegt, wird es als Override für alle Ansichten des Katalogs Downloads benutzt, und dieser ist ja immer noch verlinkt. Wir können im Backend also soviele Templates zuweisen, wie wir wollen. Es bleibt ohne Effekt. Nun könnte man denken, wenn innerhalb des Katalogs Downloads eine Kategorie Plugins liegt, bräuchten wir nur ein Override, welches wir in ein Verzeichnis plugins legen, um hier ein Override für die Kategorie Plugins zu haben. Nix da Baby!

Das Downloads-Override bezieht alle Kategorien mit ein, welche sich im Katalog Downloads befinden, also auch die Plugin-Kategorie. Um Kategorien zu stylen, welche sich in einem Katalog befinden, muss man einen anderen Weg gehen. Und zwar muss das entsprechende Override unter Einbeziehung der Kategorie-ID direkt in das Override Verzeichnis gelegt werden. Diese Datei könnte dann category_14.php heißen, falls die Plugin-Kategorie die ID 14 hat. Teuflelszeug! (aber sexy).

Artikel Overrides

Oben sprach ich über die Katalog- und Kategorie Overrides. Genauso funktioniert es natürlich auch mit einzelnen Artikeln. Hier hat man ebenfalls die Möglichkeit, einen Artikel-Override auf drei verschiedenen Ebenen zu erstellen. Beeinflussen lassen sich die Ansicht für einen Artikel aller Kataloge, die Ansicht für einen Aritkel eines speziellen Typs (z. B. Download, wobei die Konvention anders ist als bei den Kategorien) und ein Override für die Ansicht eines speziellen Artikels (wieder ID basiert). Wie bei Overrides üblich, überschreiben die tieferliegenden Schichten die höherliegenden.

Element-Overrides

Zu guter letzt gibt es da noch die Element-Overrides (o ja!). Damit kann die Ausgabe eines einzelnen Elements, also z. B. das Feld Filename bei einem Download-Artikeltyp, beeinflusst werden. Die Element-Overrides können in zwei Stufen erstellt werden. Einmal auf Basis des Elementnamen und dann auf Basis des Artikeltyps.

Falls Sie mir bis hierhin folgen konnten, können Sie sich vorstellen, dass all diese eigentlich logischen Aspekte für einen Standarduser schwer nachzuvollziehen sind. Ich persönlich stoße mich nicht so sehr daran, da ich die dadurch gewonnene Freiheit gerne in Anspruch nehme. Es wäre aber zu überlegen, ob eine etwas einheitlichere Override-Verwaltung, welche sich in den Kontext der verschiedenen Ebenen fügt, für manchen Nutzer aufschlussreicher wäre.

Obwohl ich bei der Erstellung von Overrides auf Dateiebene (welche man bei ZOO machen muss) keine Schwierigkeiten habe, habe ich z. B. bei bContent eine minimalistische Templategenerierung, in der die festgelegten Elemente rudimentär vorgegeben werden, und einen Editor eingebaut, in dem man die Templates auf einfache Weise editieren kann (bContent nutzt ebenfalls Templates aber auf ganz andere Art).
Besonders bei Projekten, welche auf einem entferntem Server liegen, nervt es auf Dauer ständig, auf Dateiebene die verschiedenen Overrides hin und her schieben zu müssen. Ein paar kleine Änderungen direkt im Backend durchzuführen, steigert die Effizienz deutlich.