Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

t3n 15

Einblicke in die neue Komponente: eZ Components lernt MVC

Mit den eZ Components stellt CMS-Hersteller eZ Systems eine Open-Source-Bibliothek bereit, die Komponenten zur Entwicklung von PHP-Applikationen bündelt. Was bislang fehlte, war eine MVC-Komponente. Mit dem Anfang des Jahres veröffentlichten Release „2008.2“ ändert sich das. eZ-Entwickler Kore Nordmann stellt die neue MVC-Komponente ausführlich vor.

Lange Zeit lehnte das Entwickler-Team die Integration einer MVC-Komponente ab, da sie nicht in das Konzept einer reinen Komponenten-Bibliothek zu passen schien. In der Tat kann eine MVC-Komponente dazu führen, dem Benutzer eine Applikationsstruktur vorzugeben und ihm viele Freiheiten zu nehmen. Ein Nachteil, den viele Frameworks mit sich bringen und der innerhalb der eZ Components vermieden werden sollte. Erreicht wurde dies bislang, in dem die Komponenten für dedizierte Aufgaben und möglichst erweiterbar entwickelt wurden.

MVC-Komponente

Wie fügt sich nun die MVC-Komponente in dieses Bild? Am Anfang stand der Entwicklungsprozess, der bei eZ Components klar gegliedert ist, um die Qualität sicherzustellen [1]. Bei der MVC-Tools-Komponente wurde dieser Prozess noch etwas ausgeweitet. Ein erstes Anforderungsdokument wurde auf der Mailingsliste und im IRC-Channel diskutiert. Nach diesen anfänglichen Überlegungen trafen sich die Entwickler auf der Open-Nordic-Konferenz mit Entwicklern von eZ Publish und externen Entwicklern, die Lust hatten, sich an der Diskussion zu beteiligen, um die bereits besprochenen Konzepte weiter zu diskutieren und ein Design zu entwerfen.

Herausgekommen ist ein Satz von Interfaces, der Anforderungen an die Schnittstellen zwischen Request-Handling, Controller und View festlegt. Beispielimplementierungen sollen sicherstellen, dass das Applikationsmodell nicht nur mit HTTP, sondern etwa auch mit Kommunikation über Jabber und E-Mail umgehen kann. Das bedingt eine vollständige Separation von Controller und View, so dass in der Ausgabe jederzeit zwischen JSON, XML und HTML gewechselt werden kann.

Zum Testen wurde bereits vor dem Release der ersten Alpha-Version eine Beispielapplikation entwickelt: Eine Messaging-Applikation, ähnlich Twitter, die bei eZ Systems zum Austausch von Status-Updates verwendet wird. Diese offen zur Verfügung stehende Applikation lässt sich über Jabber und HTTP bedienen.

Von der Anfrage bis zur Ausgabe

Der grundlegende Prozess der Behandlung einer Anfrage in MVC-Implementierungen ist bekannt, in der MVC-Tools-Komponente folgt er im wesentlichen folgendem Schema:

Jede Anfrage verarbeitet die neue MVC-Komponente der eZ Components nach einem klaren Schema.

Jede Anfrage verarbeitet die neue MVC-Komponente der eZ Components nach einem klaren Schema.

Der „request parser“ erhält die eingehenden Informationen. Das können bei HTTP die Informationen im $_SERVER-Array sein, etwa die URL oder eventuelle GET- und POST-Parameter. Beim Behandeln von E-Mails kann es der Empfänger, Absender und eventuell der Titel der E-Mail sein. Die daraus extrahierten Informationen werden in einer Struct gespeichert, die diese Informationen abstrahiert und durch Ableiten um eigene Informationen erweitert werden kann.

Structs sind ein simples wiederkehrendes Pattern in den eZ Components: einfache Klassen mit ausschließlich öffentlichen Eigenschaften ohne Methoden. Sie dienen dazu, Informationen strukturiert vorzuhalten. Der Hauptvorteil ist, dass sie sich effizienter dokumentieren lassen als Arrays, wohingegen sie geringfügig langsamer im Zugriff sind.

Die Struct wird dann dem verwendeten Router übergeben, der den richtigen Controller auswählt und damit die Zuordnung von URLs zur Applikationslogik vornimmt. Es gibt viele Wege, dies zu implementieren – zwei der bekannteren sind zum einen Router basierend auf regulären Ausdrücken und zum anderen Router wie sie in Ruby on Rails verwendet werden. In beiden Fällen gibt es einfache Pattern, die die URLs „matchen“ müssen, denen dann jeweils eine Controller-Klasse zugeordnet ist. Sobald eines dieser Pattern „matcht“, wird die assoziierte Controller-Klasse instantiiert. Bevor der Controller dann aufgerufen wird, können eine Reihe von Filtern angewendeten werden, die beispielsweise Request-Logging oder generelle Authentifizierung übernehmen können.

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Finde einen Job, den du liebst