am 12. März 2010
PHP5, Objekt-Relationales-Mapping, MVC-Architektur? Das klingt auf den ersten Blick nicht unbedingt nach Eigenschaften, die ein CMS interessant machen. – Und in der Tat, verglichen mit den Platzhirschen im Content Management Revier, bringt Silverstripe standardmäßig nur die Basis-Austattung für die Verwaltung von Inhalten mit.
- Verwaltung von textuellem Inhalt mit Rich Text Editor, Versionierung und Drafts (Entwürfen)
- Verwaltung von Bildern (inkl. automatischem Resizing)
- Hinzufügen, löschen und umarrangieren von Seiten
- Datei-Management
- Tagging für die Kategorisierung von Seiten
- „Schöne“ URLs
- Meta Daten einstellbar für jede einzelne Seite
- Optionale Kommentarfunktion für jede Seite
Jeder, der jedoch schon mal an WordPress herumgebogen hat, um ihm eine Funktionalität zu entlocken, die eine Blog-Engine eigentlich nicht unbedingt haben muss, weiss, dass heute auch kleine Seiten weit mehr als nur Inhaltsverwalter benötigen.
Genau das ist die Lücke, in die Silverstripe vorstößt: es bietet ein schlankes System mit gut ausgebauten Basisfunktionen und definiertem Raum für das Implementieren eigener Anwendungslogik. Das ist nicht dasselbe wie die Plugins-Schnittstelle in WordPress oder Extensions in Typo3. Das ist eher eine objektorientierte Version der functions.php Datei, die es in WordPress ermöglicht, Funktionalität für das aktuelle Theme zu hinterlegen.
Im Gegensatz zu Systemen wie Typo3, geht es hier also nicht darum, Redakteuren vollkommene Freiheit bei der Gestaltung aller Seiten zu ermöglichen. Der Ansatz ist viel mehr die Bereitstellung definierter Seitentypen durch den Entwickler. Seiten im CMS erben dann quasi von diesen Seitentypen und können durch den Redakteur mit Inhalt befüllt und arrangiert werden.
Das besondere daran? Es ist von vornherein vorgesehen, dass Seitentypen Geschäftslogik kapseln können – ohne dass erst Extensions oder Plugins geschrieben werden müssen (das geht natürlich trotzdem). Diese Geschäftslogik ist dann die Funktionalität, die der Seite im CMS über den reinen Inhalt hinaus zur Verfügung stellen kann.
Ein Beispiel?
Jeder Seitentyp in Silverstripe besteht aus einer Model Klasse für die Definition der Datenfelder, die es auf dieser Art von Seite geben soll, einer Controller Klasse für die Funktionalität und einem dazugehörigen Template.
Legt man in einem jungfräulichen Silverstripe eine Seite an, so ist diese vom Typ Page.
class Page extends SiteTree {
public static $db = array(
);
public static $has_one = array(
);
}
class Page_Controller extends ContentController {...}
Damit hat man eigentlich schon alles, was man braucht, um loszulegen. Das Page Model bietet ein Textfeld für eine Überschrift und einen Rich Text Editor für ein Textfeld.
Spannend wird es, sobald man das erweitern möchte. Soll eine Page jeweils noch ein Bild ausserhalb des Textfelds bereitstellen, fügt man es im Model hinzu. Zum einen wird das Datenfeld mit dem Eintrag im Array $has_one definiert und zum anderen wird in der Methode getCMSFields() definiert, wo und unter welchem Namen das zusätzliche Feld auftauchen soll. Hier wird ein zusätzlicher Tab mit dem Namen MainImage erstellt.
class HomePage extends SiteTree {
static $db = array(
);
static $has_one = array(
'MainImage' => 'Image',
);
function getCMSFields() {
$fields = parent::getCMSFields();
$fields->addFieldToTab("Root.Content.MainImage", new ImageField('MainImage', 'Image'));
return $fields;
}
}
Es gibt ein außerordentlich gutes Tutorial, das in drei Teilen (das sind drei Links…) erklärt, wie man auf diese Art und Weise eine Website mit Basisfunktionalitäten gut umsetzen kann. Heraus kommt dann beispielsweise so etwas.
Ein CMS als Anwendungs-Laufzeit
Viel interessanter ist jedoch der Umstand, dass alle public Methods einer Controller Klasse zum einen im Template der entsprechenden View zur Verfügung stehen, zum anderen aber auch direkt über eine URL ansprechbar sind. Hier beginnt der eigentlich spannende Teil, denn so steht der Implementierung eigener Anwendungslogik nichts mehr im Weg.
class Page_Controller extends ContentController {
public function hello(){
echo „Hello World“;
}
}
Obiges Beispiel erweitert jede Seite vom Typ Page um die Funktionalität Hallo zu sagen. Das ist nicht besonders spannend? Dann könnte man statt Hallo ja auch mehrstufige Formular-Workflows implementieren oder Webservices ansprechen (es gibt sogar Ansätze Rails und Silverstripe miteinander zu verknüpfen).
Je mehr eigene Funktionalität man auf diese Art implementiert, desto mehr rückt das unter Silverstripe liegende Framework Sapphire in den Vordergrund und hier offenbart sich die weniger starke Seite von SIlverstripe. Nicht nur, dass Sapphire die eine oder andere diskussionsfähige Designentscheidung zu Grunde liegt und man darüber streiten kann, ob und wie viel statische Klassen mit Objektorientierung zu tun haben, am Ende des Tages bleibt Sapphire ein weiteres umfangreiches Custom-Framework.
Ralf Eggert hat hier schon einmal alles gesagt, was es in meinen Augen zu diesem Themenkomplex zu sagen gibt.
Als bei uns der Ernstfall eingetreten ist und wir Silverstripe als Anwendungs-Plattform genutzt haben, haben wir jedenfalls relativ schnell von Sapphire Abstand genommen und das Zend Framework hineingebastelt. – Glücklicherweise bietet SIlverstripe ja ausreichend Schnittstellen für so etwas.
