Unser Partner Tom Bohacek realisiert mit seiner Firma B01 zeitgenössische Online-Kommunikationsmittel. Er ist spezialisiert auf opensource CMS und unterstützt seine Kunden vom Konzept bis zum Launch mit seiner Erfahrung und exklusiven Komponenten zur Umsetzung von Communitys, Shops, Portalen und Webseiten.
Nun hat Tom uns eine spannende Abhandlung zum Thema Template Overrides für Joomla! 1.5 geschrieben, welche Ihnen den Begriff "Override" (deu. Überschreiben) etwas näher bringen soll.
Die Geschichte
Seit Januar 2008 ist Joomla! 1.5 als Stable erhältlich. Mit der Umstellung auf das MVC-Konzept sind auch spätestens seit dieser Zeit die sogenannten Template- oder Output-Overrides vorhanden. Mit ihrer Hilfe kann einfach gesagt die Ausgabe von Inhalten gesteuert werden.
Bekanntlich wurde bei Joomla! seit je her die Ausgabe des Content also Inhalts kritisiert, ob aus Komponenten von Drittherstellern oder aus den vorhanden Joomla! Komponenten. Was die Ausgabe der Inhalte von Drittherstellerkomponenten angeht, können auch nur jene diese beeinflussen. Wenn eine Komponente Tabellen ausgibt, kann Joomla! hier nichts ausrichten. Anders sieht es jedoch bei den Joomla! eigenen Komponenten aus. Die zentrale Komponente zur Ausgabe von Inhalten, wie z. B. Beiträgen, ist com_content. Hier werden alle von Joomla! bekannten Content-Ansichten, wie die der Beiträge, Kategorien oder Bereiche getätigt.
Zum Entsetzen einiger Joomla! Nutzer wurde an der Art, wie Content ausgegeben wird, auch unter Joomla! 1.5 scheinbar nichts verändert. Ein einfacher Beitrag wird noch immer von Tabellen für Überschriften, Buttons und andere Informationen zusammengehalten. Obwohl von den Entwicklern die Möglichkeit der Template Overrides propagiert wurde, schien dies kaum jemanden wirklich zu interesieren. Das ist zum Teil auch verständlich, denn als einfacher Nutzer möchte man vernünfigen Content „Out of the Box“ und sich nicht mit obskuren Overrides beschäftigen. Zudem war diese Technik recht neu und kaum verbreitet, so dass wenige Templates vorhanden waren, welche sie einsetzten.
Bevor wir uns anschauen, ob sich fast ein Jahr nach Erscheinen von Joomla! 1.5 etwas daran geändert hat, ein paar Worte zur Funktionsweise von Overrides.
Was sind Overrides?
Wie bereits erwähnt, werden standard Inhalte bei Joomla! von der Komponente com_content ausgegeben. Durch das neue MVC (Model-View-Controller) Prinzip kann hier sehr gut zwischen Logik und Layout unterschieden werden. Für das Layout ist der sogenannte „View“ zuständig. Dieser beinhaltet die HTML-Strukturen und wird mit den darzustellenden Daten (welche aus dem Model kommen) gefüllt. Der View kann bei Bedarf ausgetauscht werden, um die Daten in anderer Form darzustellen.
Der Joomla! eigene standard View der com_content Komponente giesst die Daten in das besagte Tabellen-Layout. Mit Hilfe eines Overrides kann man nun der com_content Komponente einen anderen View für die Ausgabe der Daten zur Verfügung stellen, etwa ein echtes CSS-Layout. Das bei Joomla! 1.5 integrierte „Beez“-Template tut dies vorbildlich.
Ein Override ist also nichts anderes als ein anderer View (Ansicht), welcher im entsprechenden Template Verzeichnis liegt. Wird dieser von Joomla! gefunden, wird der Joomla! eigene View ignoriert und der im Template Verzeichnis liegende View genutzt. Der Joomla! View wird also außer Kraft gesetzt („to override“).
Am Schluss des Artikels sind zwei Links angefügt, unter denen man die Funktionsweise von Overrides genau erklärt bekommt.
Warum ein Template auf Basis von Overrides?
Nun könnte man denken, dass für jeden Template-Entwickler oberste Priorität wäre, zumindest für die com_content Komponente ein Override zur Verfügung zu stellen. Man kann nämlich für jede Komponente, sofern sie das MVC-Konzept nutzt, ein Override erstellen.
Wenn wir uns anschauen, wie sich die Templates seit dem Erscheinen von Joomla! 1.5 entwickelt haben, dann scheint es nach dem Motto „Mehr Features = besseres Template“ zu gehen. Besonders auf den grossen und beliebten Template Portalen übertrifft man sich mit Mootools-Effekten, Widgets und dutzenden von Modulpositionen.
All das geht auf Kosten der Performance und Wartbarkeit der gesamten Website. Die meisten Template-Käufer lassen sich von diesen Nachteilen scheinbar nicht abschrecken und kommunizieren den Feature-Wahn an ihre Kunden. Viele treffen ihre Kaufentscheidung sicher auch erst aufgrund dieser Features. Inzwischen werden beim Template-Kauf nicht mehr Joomla Templates geliefert, sondern komplette Joomla! Installationen, um die Unmenge an Einstellungen rund um das Template, welche für einen einfachen Nutzer unmöglich vorzunehmen sind, vorweg konfiguriert zu haben.
Es gibt Templates, welche zwei Javascript Frameworks gleichzeitig einsetzen, nebenbei acht CSS- und je nach Bedarf weitere Javascript-Dateien einbinden. Wehe dem, der eine Komponente einsetzt, welche eine andere Mootools Version oder gar ein anderes Javascript Framework nutzt.
All das wäre nicht weiter schlimm, wenn Overrides den ihnen gebührenden Platz bei der Template-Erstellung hätten. Optimale Flexibilität, SEO, Performance und wenn nötig Barrierefreiheit sind ohne den Einsatz von Overrides kaum erreichbar.
Aus diesem Grund schauen wir uns folgende Grafik an, welche einige der bekannten Template Portale auflistet und den Einsatz von Overrides im Verlauf der Zeit zeigt.
Als erstes muss man hierzu sagen, dass der Einsatz von Overrides nur ein Element der Template-Erstellung ist und nicht ausschließlich für die Qualität eines Templates spricht. Es gibt durchaus Templates, welche Overrides anbieten, andere wichtige Aspekte eines Templates jedoch vernachlässigen. Andererseits existieren Templates, welche ausgesprochen schlank und flexibel sind, jedoch keine Overrides unterstützen. Auffällig ist, das relativ unbekannte Portale Overrides einsetzen, wohingegen einige der Marktführer noch fleissig Tabellen ausgeben. Dies kann am Workflow der Template-Bauer liegen, denn ein Override verlangt etwas andere Handgriffe, ist jedoch weit einfacher zu erstellen als eine dritte, transparente PNG-Ebene unter dem IE6 zum Laufen zu bekommen.
Die Zukunft von Overrides
Ich bin recht zuversichtlich, dass ein Override für die com_content in Zukunft zum guten Ton eines jeden namhaften Template Portals zählen wird. Als Käufer eines Templates ist es ohne Kenntnisse nicht einfach in Erfahrung zu bringen, ob Overrides genutzt werden, denn die meisten Portale werben mit einem „100% pure CSS design“, meinen damit jedoch nur das Template-Gerüst.
Die Ausgabe der Inhalte überlassen sie weiterhin Joomla! und damit den Tabellen. Vielleicht sollte besser ein „Overrides supported“ Sticker auf den Portalen prangen, denn mit dem jetztigen Verständniss von CSS-Design zu werben, ist als würde Joomla! mit Datenbankunterstützung werben.
Die folgenden Links helfen Ihnen dabei, mehr über Overrides zu erfahren und entsprechende Templates zu erkennen.
4 Kommentare
wohl daran das man kompatibel zur 1.0 Serie sein will muss? Schon mal drüber nach gedacht
Kompatibilität kanns nicht sein, denn die Datenbankstrukturen sind gleich geblieben.
Eine kleine Ergänzung. RocketTheme veröffentlicht seit Januar 2009 Templates nur noch für die Version 1.5. Der Aufwand, der bislang nötig war, um die Parallelversionen für 1.5 und 1.0 zu pflegen, fließt nun ein in Overrides. Damit sind jetzt auch RT-Templates komplett tabellenfrei.
Viele Grüße,
Zorro
Kleine Korrektur: Auch schon in Mambo 4.5x und damit auch in Joomla 1.0 waren Overrides vorgesehen. Man mußte lediglich im Template einen Ordner components anlegen, die *.html.php der gewünschten Komponente dorthin kopieren und konnte nach Herzenslust ändern, was geändert werden sollte.
Das Problem: Die Trennung von Inhalt und Ausgabe war in allen Komponenten, auch und vor allem den Core-Komponenten, hundsmiserabel umgesetzt. Der Ausgabecode wurde eben nicht in der *.html.php erzeugt, sondern dort lediglich aus fertig generierten Codestücken zusammengesetzt. Es nützt nichts, ein gegen ein zu tauschen, wenn der zugelieferte Inhalt und enthält.
In dieser Hinsicht ist durch das MVC-Konzept vieles besser geworden, aber noch lange nicht alles gut, auch nicht im Core. Noch immer wird an vielen Stellen fertig vorformulierter Code zugeliefert, den man nicht einfach für eine individuelle Ausgabe umstrukturieren oder mit eigenen Tags versehen kann.
Es ist toll und lobenswert, was inzwischen machbar ist, aber es kann noch nicht der letzte Schritt auf dem Weg zur Trennung von Inhalt und Ausgabe gewesen sein.