Ich schleppe schon einige Zeit ein Konzept bzw. eher eine Idee mit mir rum, das ich leider selbst aus Zeitgründen nicht umsetzen kann: das ressourcenbasierendes Framework (RF). Möglicherweise ist das Prinzip nicht ganz neu, aber mir ist bisher noch kein derartiges Framework oder CMS untergekommen.
Auf die Idee bin ich gekommen, weil CMS- bzw. Blogsoftware häufig zu starr ist, um schnell ein neues Feature zu implementieren. Der Weg von typenbasierenden Seiten, also mit der Unterteilung ‘Seite’, ‘Blog’, ‘Termin’ usw. in eine flexibel kombinierbare Ausgabe zieht häufig einen kompletten Umbau nach sich – oder ist abhängig von spezialisierten Schnittstellen.
Auch wenn ich mich gerne mit Konzepten beschäftige und z.B. bereits das Zend Framework oder Symfony kennengelernt habe, ist mir der Weg zu einer fertigen Anwendung noch zu lang, oder wenn ich kein eingefleischter Anwender bin, auch zu kompliziert.
Ressourcen als Basis
Während die meisten CMSs oft diverse vollkommen voneinander unterschiedliche Contentelemente kenne, darunter Plugins, Seiten als News, Termine, statische Elemente usw., kennt das RCMS nur einen Grundtypen: die Ressource.
Eine Ressource kann sich die Inhalte aus diversen Quellen holen, z.B. Datenbanken, Textdateien, Templates oder Webservices. Für jede Resource werden normalerweise zwei standardisierte Command-Klassen bereit gestellt, jeweils für die Einrichtung im CMS-Backend und für die Ausgabe im CMS-Frontend.
Definition des Ressourcentyps
Je nach Aufgabe gibt es verschiedene Grundtypen von Ressourcen. Typisch sind programmorientierte Ressourcen wie Datenbankverbindungen, ACL, Request und Response und ausgabeorientierte Ressourcen, wie z.B. für HTML Header und Visible Content, die nach den Aufgaben weiter unterteilt werden.
Resourcegruppen
Die Ressourcen werden für den Einsatz über eine Konfiguration zusammengestellt. Eine grundlegende Konfiguration erstellt den gewünschten Aufruf. Wird ein Seitentemplate verwendet, erhält dieses Template ebenfalls eine Konfiguration, um die für die Seite verfügbaren Ressourcen zu definieren. Mit weitere Konfigurationen werden Ausgabetypen wie z.B. ein Blog, eine Seite, ein Download usw. mit Standardelementen und Standardtemplates definiert. Ergänzt wird die Konfiguration über dynamische Einstellungen und Einstellungen aus den einzelnen Ressourcen, die sich gegenseitig beeinflussen können.
Jede Ressourcegruppe stellt selbst eine Ressource dar. So können Ressourcegruppe ineinander verschachtelt werden.
Abarbeitung der Ressourcen
Die Abarbeitung erfolgt mit einem Controller in mehreren Schichten. Immer verfügbar sind die Schichten prepare, execute und view. Mit prepare werden Parameter zusammengestellt. Dabei kann auch die Ressourcegruppe beeinflusst werden, um auf zusätzliche Ressourcen zuzugreifen, Ressourcen oder ganze Ressourcengruppen zu entfernen oder zu ersetzen.
Die zweite Schicht, execute, führt optional logische Operationen aus.
Mit view wird die Ausgabe generiert, soweit dies erforderlich ist.
Vor- und Nachteile
Der Vorteil ist eine hohe Erweiterbarkeit und Flexibilität. Ressourcen können relativ einfach ersetzt, ergänzt oder neu kombiniert werden. Durch die einheitliche Schnittstelle für alle Ressourcen müssen sich Anwendungsdesigner weniger um die technischen Hintergründe kümmern, sie müssen nur noch wissen, welche Daten sie aus welcher Ressource zurückbekommen.
Ein Nachteil ist möglicherweise die hohe Anzahl der Dateizugriffe. Spätestens bei komplexeren Aufgaben muss für jede Ressource eine Klasse erstellt werden. Es kann auch schnell zu einem Konfigurationsoverhead führen.
