Architekturtypen
Page-Typ im Modul-Ordner
Wird ein zusätzlicher Seitentyp in einem Modul gebaut, steht er genau gleich zur Verfügung, wie wenn er im Code-Ordner der Grundinstallation abgelegt wird. Zur Benutzung muss eine neue Seite dieses Typs erstellt werden, die Anzeige erfolgt in der entsprecheneden *.ss-Datei dieses Seitentyps.
(Besipiel: 'MeinKleinerEventKalender' steht nur zur verfügung innerhalb des eigenen Seitentyps)
Mögliche Vorteile in Modulbauweise: Alle nötigen Dateien (Bilder, CSS, JS) sind im Modulordner.
Sub-Classing
Beispiel: Tutorial 7 - Ein Video-Modul erstellen
Wird eine Klasse erweitert (extends) entsteht eine Unterklasse, die alle Eigenschaften und Methoden der Elternklasse erbt. Damit lässt sich auf einfache Weise die Fähigkeit einer Klasse ausbauen. Es muss nur der zusätzliche Teil, weitere Eigenschaften oder Funktionalitäten, neu geschrieben werden. Die Eltern-Klasse vererbt alle bereits zur Verfügung stehenden Möglichkeiten.
Mit Silverstripe wird oft der Page-Typ erweitert.
class MyPage extends Page {
...
}
class MyPage_Controller extends Page_Controller {
}Die Absicht und Vorgehensweise ist einfach und klar. Der Typ "MyPage" erbt alles von "Page" und erhällt zusätzlich ...
class MyDataObject extends DataObject {
$db = array(
...
);
public function getCMSFields() {
...
}
}Soll eine zusätzliche Datenbank-Tabelle erstellt werden, die in einem separaten Controller aufgerufen und im Template zur Anzeige gebracht wird, kann das "DataObject" extendiert werden. Hier erbt "MyDataObject" alles von "DataObject" und erbt daher alles im Umgang mit Datenbankabfragen, MySql-Statements und deren Anzeigemöglichkeiten im Backend.
class MyPage_Controller extends ContentController {
}
class MyDatabase extends SiteThree {
}
class MyPage extends Page {
}
Die extendierte Klasse vererbt alle ihre Eigenschaften und Methoden an die neue Klasse. Das ist ein sinnvoller Aufbau und sehr praktisch, wenn der Page-Typ wie im Beispiel 'MyPage' zur Anzeige verwendet wird.
Etwas anders sieht es aus, wenn Datensätze aus einem anderen Objekt, einem anderen Controller in der Page-Anzeige gebraucht werden.
Wenn Beispielsweise alle Titel und Links der einzelnen News-Seiten als Teaser in der rechten Spalte der Startseite angezeigt werden sollen, kann dies in einem extendierten Typ "StartPage" gebaut werden. Im Template kann direkt auf die DB-Inhalte dieses Typs zugegriffen werden. Die Links und Titel können direkt im Template in der rechten Spalte angezeigt werden.
Soll der News-Teaser aber in allen Seiten angezeigt werden, muss der Controller mit dem DB-Aufruf und die Anzeige in den Page_Controller eingebaut werden. das heist: Jede Seite muss den Datensatz neu laden und anzeigen.
Das ist so, als würde der Datensatz für den News-Teaser ständig hinterhergeschleift.
Mit Sub Classing wird also ein linearer Weg verfolgt, und von oben nach unten vererbt. Dies kann, einmal gebaut, bei einem sich verändernden, wachsenden Projekt, ein starres Hindernis darstellen.
DataExtension (Decorator)
Beispiel: Tutorial 8 - Ein Modul für seiten abhängige Headerbilder erstellen
Eleganter scheint mir die Architektur, wenn der Datensatz für den News-Teaser dem Page_Controller gereicht wird. Bereits beim Aufbau der Seite steht dann alles was angezeigt werden soll zur Verfügung.
Ein "Decorator" kann neben einer bestehenden Klasse erstellt und der Klasse angehängt werden. Wird eine "dekorierte" Klasse aufgerufen, wird das zusätzliche Paket gleich mitgeliefert.
Die Verknüpfung von Page-Controller (Klasse) und dem DataExtension-Controller (Decorator) wird in der Config-Datei festegelegt.