Content Management mit Plone (eBook)

Hans Jörg Friedrich lebt und arbeitet in Stuttgart. Nach Abitur und Zivildienst machte er eine Ausbildung zum Tontechniker. Ihr folgten Tätigkeiten in der Werbung, der Musik- und Filmproduktion sowie beim Theater. Seit 1998 ist er als Tontechniker und Producer für den Südwestrundfunk tätig, seit 2005 auch als System- und Anwendungsbetreuer. Freiberuflich führt er seit 1998 eine Agentur für Multimediadesign. Von 1998 bis 2002 absolvierte er außerdem ein Studium zum Diplom-Ingenieur (FH) im Fach Audiovisuelle Medien an der Fachhochschule Stuttgart. Dabei spezialisierte er sich auf die Konzeption und die Realisierung interaktiver Medien. Schwerpunkte dieser Arbeit sind die Erstellung datenbankbasierter e-Commerce-Anwendungen.

Vorwort 5
Für wen ist dieses Buch gedacht? 5
Wie ist dieses Buch zu lesen? 6
Konventionen 7
Was ist auf der CD-ROM? 7
Danksagungen 7
Inhaltsverzeichnis 9
Teil I Content Management 18
1 Einführung in Content Management 20
1.1 Content 20
1.2 Management 22
1.3 Einsatz von Content-Management-Systemen 24
2 Plone-Oberfläche 26
2.1 Der Kopfbereich 26
2.2 Der Seitenkörper 30
2.3 Der Fußbereich 37
2.4 Wie geht es weiter? 37
3 Content Types 38
3.1 Ordner 39
3.2 Seite 40
3.3 Bild 42
3.4 Datei 42
3.5 Link 42
3.6 Nachricht 43
3.7 Termin 43
3.8 Ausblick 44
4 Plones Benutzerkonzept 46
4.1 Permissions – Berechtigungen 46
4.2 Roles – Vollmachten 47
4.3 Gruppen 48
4.4 Local Roles – Lokale Rollen 49
4.5 Workflow 49
4.6 Benutzerkonzepte – Ein Beispiel 53
4.7 Wie geht es weiter? 55
5 Inhalte erstellen – Die Arbeit der Autoren 56
5.1 Kupu – WYSIWYG-Editor in Plone 57
5.2 reSt – reStructuredText 64
5.3 Lokalisierung– Mehrsprachige Websites 79
5.4 Wie geht es weiter? 82
6 Die Inhaltsstruktur – Die Arbeit der Redakteure 84
6.1 Physikalische Organisation 84
6.2 Logische Organisation – Sichten 93
6.3 Wie geht es weiter? 106
6.4 Benutzerf¨uhrung 107
6.5 Benutzerinteraktionen 111
Teil II Design 116
7 Grundlagen 118
7.1 CSS in zehn Minuten 119
8 Templates 132
8.1 Template-Arten 132
8.2 Zope Page Templates 134
9 Plone Basislayout 150
9.1 TTW und dateibasierte Entwicklung 151
9.2 Plones Templates und CSS-Dateien 153
9.3 Plone Skins 157
9.4 Design von Inhalten 163
9.5 Wie geht es weiter? 166
10 Migration eines Designs nach Plone 168
10.1 Analyse 169
10.2 Konzeption 170
10.3 Umsetzung 172
10.4 Die Inhalte 200
11 Design von Zusatzprodukten 204
11.1 Designanpassung fremder Produkte 204
11.2 Basisdesign eigener Produkte 205
11.3 Internationalisierung – i18n 206
11.4 Lokalisierung – i10n 213
Teil III Programmierung 216
12 Werkzeuge 218
12.1 Python 219
12.2 UML 220
13 Plone Konzepte 230
13.1 TALES – Template Attribute Language Expression Syntax 230
13.2 Datenquellen und Datensenken 238
13.3 Der Katalog 241
13.4 Akquisition 249
13.5 Sicherheit 253
13.6 Properties – Objekteigenschaften 257
13.7 Internationalisierung 258
13.8 Unit-Tests in zehn Minuten 259
14 Plone-Komponenten 264
14.1 Content-Typen 264
14.2 Tools 290
14.3 Workflow 292
14.4 Formulare 295
15 Five 302
15.1 Zope 3 in zehn Minuten 302
15.2 Five verwenden 311
Teil IV Administration 316
16 Installation 318
16.1 Plattformüberlegungen 318
16.2 Hosting, Housing oder das eigene Rechenzentrum 320
16.3 Die Plone-Installation 321
16.4 Zusatzprodukte 328
16.5 Anpassungen 331
17 Plone Konfiguration 334
17.1 Customization Policy – eine Einf¨uhrung 335
17.2 Produkte hinzuf¨ugen / entfernen 336
17.3 Allgemeine Einstellungen 342
17.4 Language Settings – Spracheinstellungen 345
17.5 E-Mail-Einstellungen 347
17.6 Navigation 348
17.7 Suchfunktionen – Der Katalog 349
17.8 Themen 352
17.9 Aussehen 353
17.10 Benutzer und Gruppenverwaltung 355
17.11 Workflow 376
17.12 External Editor 388
17.13 Kupu 393
17.14 Customization Policy – die Implementierung 396
17.15 Wie geht es weiter? 401
18 Plone in Betrieb 402
18.1 Backups 402
18.2 Weitere Sicherheitsvorkehrungen 403
18.3 Plone und Apache 404
18.4 SSL – verschl¨usselte Verbindungen 409
18.5 Caching 413
18.6 Skalierung mit ZEO 420
18.7 Überwachung 425
Literaturverzeichnis 434
Sachverzeichnis 438

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.