Zend Framework Blog

Hinweis von Ralf: nach einer längeren Sommerpause (es war einfach zu heiß und überhaupt) geht es hier nun weiter. Ich beginne gleich mit einer neuen Rubrik, in der ich (und ihr) Open Source Projekte vorstellen könnt, die auf dem Zend Framework aufsetzen. Wer also auch an dem einen oder anderen OS Projekt mitarbeitet, dass auf dem Zend Framework basiert, kann sich gerne bei mir melden. In den nächsten Tagen werde ich mich dann selber (hoffentlich) wieder regelmäßiger zu Wort melden. Doch nun hat Till das Wort:

Das RedSpark Framework

Das offene RedSpark Framework setzt auf dem ZEND Framework (kurz ZF) auf und löst einige der Probleme, mit denen sich schon fast jeder Entwickler konfrontiert sah. Vielleicht umschreibt dabei der Begriff „Application Framework“ RedSpark am besten: Ein Framework welches auf die Erstellung, aber vor allem auch Wiederverwendung von Web-Anwendungen, kurz „Apps“, ausgelegt ist.

Probleme trotz Framework

Welche Probleme sind gemeint? Und warum „Application Framework“? Zusätzlich muss sehr berechtigt gefragt werden, ob die Welt ein weiteres PHP-Framework braucht. Beginnen wir mit den Problemen, die viele Entwickler mit dem ZEND Framework haben:

Einstieg

Viele Entwickler berichten, dass sie auf das ZF umsteigen wollen, der Einstieg aber zu schwierig und vor allem zeitaufwändig sei.

OOP / Skills / Struktur

Viele Entwickler ohne OOP Erfahrung haben Probleme, ausgehend von der „weißen Seite“ eine saubere Architektur aufzubauen. Zudem fehlen dem MVC-Ansatz im ZF bekannterweise die Models, die entsprechend selbst konzipiert werden müssen.

Wiederverwendbarkeit

Für neue Projekte wird meistens entweder das letzte Projekt geklont oder weiter entwickelt, um den Start „auf der weißen Seite“ zu vermeiden. Diese Systeme sind danach allerdings nicht mehr wartbar, da Änderungen mehrfach gemacht werden müssen.

Individualisierbarkeit

Projekte mit dem ZF sind natürlich hochgradig individuell, allerdings müssen wie gesagt viele Komponenten selbst entwickelt werden, die in anderen Systemen bereits existieren.

Development

Exemplarisch sei hier Rapid-Prototyping genannt, welches direkt bei der Geschäftslogik ansetzt, ohne Zeit in Struktur und Aufbau der Anwendung zu investieren. Sowie das Thema Unittests. Jeder möchte Unittests nutzen, leider scheitert es häufig an dem Problem, komplexe Anwendungen mit einfachen Annahmen komplett zu testen.

Kommt all das bekannt vor? Das RedSpark Framework löst diese Probleme.

Lösungen des RedSpark Framework

Das RedSpark Framework erweitert das ZF an den folgenden Stellen:

Einstieg / OOP / Skills / Struktur

Der Einstieg in RedSpark gestaltet sich genau so einfach wie die Installation eines beliebigen OpenSource CMS Systems. Bereits Out-of-the-Box bietet das System, neben dem kompletten ZF als Basis eine Anwendungsstruktur, ein vollwertiges CMS, ein Basislayout, sowie vor allem ein Backend.

RedSpark kann somit entweder als CMS dienen und mit vorgefertigten Apps (Blog, Payment, etc.) erweitert werden oder in dieser Form als Basis für eine eigene ZF basierte Anwendung genutzt werden. Dabei kann neben Scaffolding für die Erzeugung der Struktur auch das komplette ZF genutzt werden. Nie war es möglich in kürzester Zeit eine so komplexe Anwendung zu erstellen, ohne auf die Flexibilität des ZFs verzichten zu müssen.

Wiederverwendbarkeit

RedSpark legt alle Bestandteile versioniert ab. Das System ist dadurch stets aktualisierbar und vor allem sind Softwarekomponenten in unterschiedlichen Apps und unterschiedlichen Versionen gleichzeitig nutzbar. Eine wichtige Voraussetzung für Wiederverwendbarkeit.

Individualisierbarkeit

Sämtliche Klassen des ZF, sowie sämtliche Klassen in den darüber liegenden Schichten beerben einander. RedSpark ist zwar mit all den vorgefertigten Apps auch sehr gut direkt z.B. als CMS einsetzbar, durch die Vererbungsstrategie ist es allerdings auch möglich, jede Methode aller darunter liegenden Schichten nach Belieben anzupassen.

Development

Neben den Lösungen für die Probleme Rapid Prototyping und Unittesting bietet RedSpark auch hier diverse Lösungen aus der Praxis:
Systemtexte im Backend pflegbar
Ein ausgereifter Cache (Memcache + Statifizierung) – im Backend steuerbar
Nutzung von SMARTY in der Templateausgabe
Referenzimplementierungen in Form einer Kickstart App

Fazit

Die Trennung des projektbezogenen Quellcodes in der eigenen App von den Libraries und anderen Apps steht an oberster Stelle. Jeder Kunde erhält genau die für seine Anwendung nötigen Entwicklungen und Änderungen. Alle vorhandenen Funktionen können jedoch im OOP Sinn für die eigene App erweitert werden.

RedSpark entsteht im Hause der Firma Kuborgh in Hamburg und Köln und „tickt“ bereits unter Seiten wie z.B. www.axe.de und ist die Basis vieler Facebook Apps, dazu aber in Kürze mehr, zum Beispiel in einer der nächsten Ausgaben des PHP Magazins. Die Roadmap für aktuell geplante Releases sind im Blog zu finden:

• http://www.redsparkframework.de/Blog/List.phtml

Peter schreibt in seinem Blog über die möglichen Ansätze zur Integration des Zend Frameworks in den OXID eShop. Ich kenne mich mit dem OXID eShop zwar überhaupt nicht aus, aber Peter stellt eine kleine Liste für Integrationsmöglichkeiten ausgewählter Zend Framework Komponenten zusammen. Dabei könnte er sich den Einsatz von Zend_Controller, Zend_Cache, Zend_Config, Zend_View und mit Abstrichen auch Zend_Db vorstellen. Das Problem dabei ist, dass der OXID eShop ein gewachsenes Projekt mit vielen verfügbaren Modulen ist. Bei der Integration des Zend Frameworks müsse somit zwingend darauf geachtet werden, dass diese unzähligen Module nicht auf einen Schlag nicht mehr zu nutzen sind. Ich bin mal gespannt, ob und wie das OXID eShop Team dies umsetzt. Aber lest selbst:

• Spike-Solution des OXID eShops + Zend Framework verfügbar