Die Master-Client-Struktur ist für den ZMS-Administrator sehr leicht im Menü System-Konfiguration aufzubauen (siehe folgendes Bild). In der Tat verwendet man die Zeit vielmehr in die theoretische Vorarbeit, nämlich die Überlegung, welche Konfigurations-Details primär zentral über den Master zur Vererbung konstruiert werden und welche spezifisch für einen ZMS-Client (Instanz) aufgebaut werden. Idealerweise besitzen die Clients nur ein minimales Set spezifischer Konfigurationen (Prinzip der minimalen Redundanz), weil dadurch die dauerhafte Pflege selbst großer Multisites mit mehr als 100 Clients sehr gut gewährleistet werden kann. Ziel ist es also in den Clients möglichst keine Besonderheiten zu konfigurieren bzw. hierfür ein einheitliches Regelwerk zu bestimmen. Folgende Fragen helfen bei der Konzeption:

  1. Welche strukturellen Gemeinsamkeiten zwischen den ZMS-Instanzen der Multi-Site gibt es?
  2. Welche Metadaten, Content-Objekte, Formate werden allgemein benötigt
  3. Welche Layout-Elemente (Templates) werden allgemein benötigt
  4. Mit welchen Regeln lassen sich Variationen abbilden (Beispiel: einige Clients haben ein zusätzliches Bild im Header) und welche strukturellen Korrelate lassen sich für deren funktionaler Abbildung finden (z.B. Metaelement für Header-Bild)

Profitipp: Auch die CSS-Files sollten eine minimale Redundanz aufweisen. Dies schafft man über ein zentrales Master-Stylesheet (CSS), das durch client-spezifischen CSS-Elemente ergänzt wird. Damit sich Master- und Client-Stylesheets nicht überschreben, befinden sich die zentralen Assets im Common-filder, während instanz-Assets im Zope-Ordner „instance“ liegen.

master

Abbildung 52: Für eine Master-Client-Konfiguration werden im Master-ZMS alle Namen der relevanten ZMS-Root-Container (bzw. Zope-Folder) in das Feld „Clients“ unterreinander eingetragen. Umgekehrt trägt man im Client den Namen des Masters ein. Voraaussetzung dafür ist, dass die Zope-Ordner, in denen sich die jeweiligen ZMS-Knoten befinden hierarchisch angeordnet sind .d.h. der Master liegt „über“ den Clients und die Clients liegen parallel „unter“ dem Master.

client_zope

Abbildung 53: Ideale Client-Konfiguration: alle Darstellungstemplates sowie alle Konfigurations-Elemente (Content-Klassen) stammen aus dem Master. Es gibt lediglich einen instanzspezifischen Asset-Ordner (entspricht /common) für Assets und CSS-Dateien und eine Objekt-Mapping-Methode zur Abtraktion instanzspezifischer Layouts (Impressum, Kontext etc.)

client_akquire

Abbildung 54: Über den Vererbungs-Mechanismus lassen sich die Konfigurations-Elemente (Content-Modelle, Metadaten etc.) von der Master-Instanz „akquirieren“; auf diese Weise wirken sich Änderungen in der Master-Konfiguration unmittelbar auf alle Clients aus. Die Vererbung kann jederzeit aufgehoben werden und das Konfigurations-Element instanz-spezifisch gelöscht oder nach einem Kopiervorgang an lokale Erfordernisse angepasst werden.