Content Management mit Plone - Gestaltung, Programmierung, Anwendung und Administration

11 Design von Zusatzprodukten (S. 187-188)

Jede Funktionalität, die über Plones eingebaute Fähigkeiten hinaus geht, wird über Zusatzprodukte realisiert. Wo diese Produkte herkommen ist zweitrangig. Wichtig ist, dass sie als eigenständige Komponenten in eine System eingeführt werden. Und es ist wichtig, diese Eigenständigkeit auch zu bewahren. In den letzten Kapiteln wurde gezeigt, dass Skins wie Drittanbieterprodukte installiert werden. Aus der Sicht der Designer ist der einzige Sinn dieser Produkte, das Aussehen der Site zu beeinflussen. Das muss nicht der einzige Sinn sein, aber im Grund kann man das so sehen. Andere Produkte haben den Zweck, die Funktionalität von Plone zu erweitern. Das können sie in Form von "unsichtbaren" Fähigkeiten erreichen, oder durch neue, sichtbare Inhaltstypen. Um das Design dieser neuen Inhaltstypen geht es hier. Dabei muss man unterscheiden, ob es sich um ein Design handelt, das mit dem Produkt verteilt werden soll, oder ob die Darstellung der Artikel des Produkts dem Look der eigenen Site angeglichen werden soll.

11.1 Designanpassung fremder Produkte

Jedes Produkt wird normalerweise mit den nötigen Templates für die Darstellung geliefert. Auch wenn ein fremdes Produkt verwendet wird, soll doch die Gesamtanmutung einer Site über den gesamten Inhalt gleich bleiben. Deshalb werden auch die Templates der Drittanbieterprodukte, zumindest aber die Stile, angepasst. Mit den Anpassungen, wird das Produkt-Design Teil des eigenen Skins. Dort werden die Dateien auch gespeichert und nicht innerhalb des Zusatzproduktes. Das hat im Wesentlichen zwei Gründe. Zum Einen ist bei Produkten mit Updates zu rechnen. Fehler werden behoben und neue Funktionen hinzugefügt. Ein Update lässt sich einfach installieren. Das alte Produkt wird gelöscht, das neue in das Products-Verzeichnis kopiert und Zope neu gestartet. Sind die Templates innerhalb des Produkteverzeichnisses gespeichert, dann muss man diese Dateien erst sichern, und sie nachher auch wieder zurück in den neuen Produktordner verschieben. Der zweite Grund ist die Transportabilität eines Skins. Wenn alle Templates, die zum Design einer Site gehören in einem Verzeichnis gespeichert sind, dann ist es einfach, auf einem anderen Rechner dieselbe Site aufzusetzen, indem man den Skin auf die neue Instanz überträgt.

Danach werden alle Zusatzprodukte installiert und zum Schluss die Datendatei der Objektdatenbank kopiert. Wurden Teile innerhalb eines Produkts geändert, dann ist es nicht mehr egal, ob man sich das Produkt aus dem Internet lädt, oder von der alten Installation nimmt. Problematisch ist, dass man es dem Produktverzeichnis nicht ansieht, ob sich die Dateien darin verändert haben. Im Skin hat man die M¨oglichkeit, die Dateien auf die Verzeichnisse des Gesamtdesigns zu verteilen oder in einem eigenen Ordner zu sammeln. Ich empfehle an dieser Stelle aus Gr¨unden der besseren Trennung die zweite Variante.

Da es aber oft nur wenige Dateien sind, ist eine gesamte Verzeichnisstruktur, die in Skripte, Bilder, Stile und Templates aufteilt nicht angebracht. Sinnvoll ist in der Regel ein Verzeichnis, in dem alle Dateien gesammelt werden. Um das Design des Zusatzproduktes vom Design der restlichen Site zu trennen, sollten auch die Stile in einer eigenen Datei gespeichert werden, die im Verzeichnis der ge¨anderten Dateien des Zusatzprodukts liegt und ¨uber die CSS-Registry eingebunden wird. Wenn Sie diese wenigen Regeln beherzigen, dann haben Sie immer eine optimale Trennung zwischen dem Produkt und Ihrem Design, aber auch zwischen dem Design der Site und den zusätzlichen Elementen für weitere Produkte.