Dies (wie auch die folgenden Seiten/Teile) sind eine Übersetzung des Tutorials von Alexander Limi, Creating a new theme for Plone: a real-world example auf Plone.org. Bitte beachten Sie das dortige Copyright des Originals, das entsprechend auch für diese Übersetzung gilt.

Es befindet sich aktuell auf dem Stand der Versionen von Plone bis zum Zweig von 2.5.x und ist auf die aktuelle Version 3.0.x von Plone nur teilweise anwendbar (ein Update ist geplant). 

Mit Plone 2.1 und späteren Versionen ist eine neue Methode zum Gestalten von Oberflächen für Plone bereit gestellt worden, die es um einiges einfacher als den früheren Versionen von Plone macht.

Ich will nicht besonders darauf eingehen, wie die Aufgabe in früheren Versionen erledigt wurde, abgesehen davon, zu erklären, dass dies mittels Hernehmens des existierenden Plone-CSS, Überschreiben der existierenden CSS-Regeln und Erstellen einer neuen Oberfläche auf dieser Basis. Diese Herangehensweise hat zahlreiche Probleme:

• Es war sehr kompliziert, falls Sie nicht viel über CSS wußten.
• Es neigte zu Brüchen, wenn auf eine neue Version des Plone-CSS upgedated wurde (selbst kleinere Änderungen würden Ihr Oberflächenthema verändern).
• Es bewirkte, dass die CSS-Ausgabedateien von Plone sehr groß wurden.

Die neue Herangehensweise

Mit Plone 2.1 und neuer ist eine neue Infrastukturkomponente, genannt ResourceRegistries, eingeführt worden. Diese Komponente erlaubt es, CSS und Javascript auf der Serverseite aufzusplitten, so dass es in einer vernünftigen Weise verwaltet werden kann. Es können bedingte Überprüfungen an Teile des CSS/JS angehängt werden und alles wird zu einer einzelnen Datei in der Ausgabe vereinigt, so dass der Browser nur eine CSS-Datei sieht, wodurch Menge der erforderlichen Dateiabfragen reduziert wurde. In späteren Versionen, fügte RR CSS- und JS-Kompression hinzu, um die Dateigröße zu reduzieren.

Was bedeutet das für uns, wenn wir ein Plone-Thema erstellen wollen, ist, dass wir Teile desCSS für die Plone-Benutzer-Schnittstelle wahlweise ausschalten können. Eine sehr verbreitete Heransgehensweise besteht darin, das CSS für Autorentätigkeit (den grünen Rahmen, das Formular-CSS) beizubehalten und nur dasjenige anzupassen, was die Leute sehen, die nicht angemeldet sind. Dies hat mehrere Vorteile:

• Wir können mit einer leeren Liste beginnen und unser CSS ohne Beeinträchtigung durch Plone hinzufügen
• Wir können die Downloadgröße des CSS reduzieren auf dasjenige, was wir brauchen
• Das Thema wird deutlich belastbarer gegenüber Änderungen in Plone selbst.

Der Grund dafür, warum diese Herangehensweise stabiler ist, wenn Kompatibilität mit zukünftigen Versionen aufrechterhalten werden soll, ist, dass sie nur auf HTML, IDs und Klassen beruht, die nur selten geändert werden (Realistisch gibt es nun dort ein Paar Veränderungen und sodann auch an den Klassen und IDs - aber diese sind weniger häufig wie die anderen Veränderungen; und das Plone-Team versucht, sie unversehrt zu lassen, wenn dies möglich ist).

Es gibt drei Wege, das Erscheinungsbild von Plone zu verändern:

Einfache Veränderungen

Ersetzen des Logos und Anpassen der Farben. Ich werde dies hier nicht behandeln, aber es ist in den meisten der Bücher und in einer ganzen Anzahl von Howtos beschrieben.

Umfangreich

Ersetzen des ganzen Designs, das öffentlich sichtbar ist, aber Beibehalten der grundlegenden Stile für die Bedienelemente. Dies mag einfache Veränderungen an main_template einschließen, aber nichts radikales.

Komplett 

Beginnend von Grund auf und Ersetzen des kompletten CSS und Neuschreiben aller Vorlagen (nicht empfohlen; wird ein Alptraum bei der Wartung)

Ich werde den Weg "Umfangreich" beschreiben.

Warum die Plone-Struktur behalten?

Zugänglichkeit (Accessibility)

Plone wurde so konstruiert, dass es benutzerfreundlich für Personen mit motorischen oder Sehbehinderungen ist. Dies erforderte eine Menge Aufwand und Test — mit Plone bekommen Sie dies gratis.

Sichtbarkeit für Suchmaschinen

Bereits als Standard hat eine leere Plone-Seite das Potential für einen hohen Google-Rang. Für Plone.org selbst beträgt der Google-Rang 9/10, derselbe wie für Microsoft, IBM und vergleichbar schwergewichtige Einträge im Internet. Die Plone-Community hat eine Menge Zeit in die Optimierung von Plone für Suchmaschinen investiert. Google liebt Plone. Plone liebt Google. (Trivialität: die einzige Seite, für die Alexander Limi einen 10/10 Rang herausgefunden habe, ist die Seite des W3C — kennt irgendjemand andere? :-)

Ein Hinweis zur Terminologie

Überall in diesem Tutorial verwende ich das Wort "Thema", um eine Sammlung von durchgeführten optischen Veränderungen zu beschreiben. In anderen Teilen der Plone-Literatur wird dies als "Skinning" beschrieben und das Resultat als "Skin" (Design, Oberflächenthema). Die Gründe, warum wir versuchen, von dieser Terminologie wegzukommen, sind mehrere:

1. In der Plone-Terminologie kann eine "Skin" beides sein, Vorlage,CSS und Veränderungen am Code. Wir versuchen, die Oberflächen-Themen soweit wie möglich zu trennen vom Code und der Anpassung von Vorlagen (Template) und benutzen das Wort "Thema", um zu vermitteln, das es sich nur um Veränderungen des Aussehens handelt.In Plone terminology, a "skin" can be both template, CSS and code modifications.
2. Wir bestärken Sie darin, Ihre anderen Veränderungen an Plone in einem separaten Dateisystem-Produkt aufzubewahren. Dies macht die visuellen Veränderungen / Thementeil der Gleichung wiederverwendbarer und einfacher.

Zum Beispiel in Alexander Limis Unternehmen hält man für gewöhnlich an folgender Namenskonvention für Produkte fest, wobei "Site" der Name des Kunden oder Projektes ist:

SiteTheme

Enthält das visuelle Thema und andere visuelle Elemente, die nicht normal sind (Logos, Hintergrundbilder etc.).

SiteTweaks

Enthält kleine Veränderungen an den Vorlagen (templates), Verhaltensänderungen an den Vorlagen und Python-Skripte.

SiteSetup

Benutzt die GenericSetup-Infrastruktur von Plone 2.5 oder neuer (oder CustomizationPolicies in Plone 2.1 und älter). Dieses Produkt enthält das Material, das gesetzt werden muss, wenn Sie eine Seite initialisieren — Änderungen an der Konfiguration, SQL-Verbindungen etc.

Was Infrastukturkomponenten betrifft, benennen wir diese niemals nach dem Kunden/Projekt, aber versuchen sie mit allgemeingültigen Namen zu versehen (da wir diese Lösung oft als OpenSource freigeben und deshalb neutrale Namen wollen).