Kategorien
Zend Framework aufsplitten
Wie ihr ja wisst, mag ich Frameworks. Sie helfen einen die Webentwicklung schneller zu betreiben und das ein oder anderen Projekt auch zügig auf die Straße zu bringen. Bis jetzt habe ich mich dem Zend Framework und Symfony gearbeitet. So wie es aussieht kommt auch ziemlich bald Symfony2 hinzu. Heute möchte ich mal einen Verbesserungsvorschlag für das Zend Framework einreichen. Naja nicht so direkt einreichen, eher etwas drüber schreiben und hoffen, dass es jemand liest.
Für mich was das Framework immer mehr als ein Framework. Ok, dass ist auch die Idee, die die Jungs von Zend haben. Aber erklären wir dies erstmal. Das Zend Framework ist zuallererst mal ein MVC-Framework, wie es so viele gibt. Ob es ein gutes oder schlechtes ist, weiß ich gar nicht genau, denn verwendet habe ich es zu dem Zweck nie. Ist aber auch egal, der viel bessere Teil des Frameworks sind die einzelnen Komponenten, denn dieses Framework ist zusätzlich noch eine Komponentensammlung, die relativ autark verwendbar ist.
Dummerweise packen die Zend Leute das alles zusammen in ein Paket. Dem Zend Framework. Warum ist das aber doof? Wir sind zum Beispiel eine Symfony-Firma. Alles unsere Projekte werden auf französischen Konkurrenten aufgebaut. Jetzt versucht mal das Zend Framework einzuführen. Ist gar nicht mal einfach kann ich euch sagen. Es klingt immer, als ob man an dem eigentlich verwendeten Framework vorbeiarbeitet. Dabei will man ja nur ein paar wirklich nützlliche Bestandteile verwenden, die Symfony nicht so hergibt.
Was machen wir also? Wir splitten das Zend Framework in zwei Teile auf: die Zend Library und das Zend Framework. Eigentlich ist die Idee jetzt hier schon fertig. Es ist viel einfacher eine öffentliche und gut gepflegte Bibliothek in seinem Projekt zu verwenden, als ein weiteres Framework. Auch die ganzen MVC-Bestandteile braucht man als Normalsterblicher ja eh nicht, außer man verwendet es als MVC. Lässt dich alles viel einfacher verkaufen auf die Art und Weise.
Nochmal in einem Satz zusammengefasst: Splittet das Zend Framework in zwei Teile, denn inhaltlich ist es das eh schon.
Hmm und wie wird das nun im Detail aufgeteilt ?
Ich halte die Idee für überflüssig. Das schafft nur Verwirrung und es enstehen Konflikte, bei Komponenten, die nicht eindeutig in einen (oder beide) „Teil(e)“ gehören Was spricht dagegen das gesamte Framework ins Projekt zu nehmen und nur mit bestimmten Komponenten zu arbeiten oder aber, wenn man Resourcen sparen will, die entsprechenden Komponenten einzubinden?
Eher könnte ich mir vorstellen, dass es früher oder später einen Paket-Manager geben wird, wie man es von Pear her kennt.
VH, Benjamin
Ich verstehe dein Problem nicht so ganz. Der MVC-Teil des Zend Frameworks ist doch auch nur eine Komponente in der Library, die man nutzen kann, oder es eben sein lässt. Was willst du da getrennt sehen?
Auch wenn das Ding vom Namen her „Framework“ heißt, bedeutet es noch lange nicht, dass es auch eins ist. Und das behauptet soweit ich weiß auch niemand. Es ist eine Klassensammlung, deren Komponenten sehr gut zusammenspielen und sowohl in Kombination verwendet werden können, sodass man sich damit ein eigenes Framework aufbauen kann oder eben man verwendet nur einzelne Klassen in seinem Projekt.
Wird hier neuerdings moderiert? Die Seite sagt mir, ich hätte einen Doppelpost verursacht, das aber nicht erscheint.
Ich habe neulich in [1] PEAR erwähnt – mit derselben Fragestellung: Warum wird keine einheitliche Infrastruktur verwendet? Damit könnte man solche Probleme von vornherein vermeiden, indem man seine Pakete modular entwickelt und sie separat über einen PEAR-Channel zur Verfügung stellt. Besonders beim Zend Framework sollte es doch keine großen Probleme darstellen, oder?
[1] http://www.phphatesme.com/blog/softwaretechnik/einbinden-von-bibliotheken-auf-der-suche-nach-dem-konigsweg/
Ich kann denen nur zustimmen, welche die Idee für überflüssig halten.
Wenn es jetzt um Bibliotheken gehen würde, welche von den Clients nachgeladen werden müssten und Traffic verursachen würden (wie bei Javascript), könnte ich das Problem nachvollziehen.
Nachvollziehen kann ich aber auch, dass viele „Services“ nicht benötigt werden und wie die Javascript-Unterstützung ausgegliedert werden sollten. (Im Rahmen von ZF2 soll das meines Wissens sowieso geschehen.)
Ferner hatte ich eigentlich die Hoffnung, dass sich PHAR-Archive durchsetzen würden, eine Aufsplittung in zu viele Komponenten wäre da eher kontraproduktiv.
Ich kann das auch nicht so recht nachvollziehen.
Das Zend Framework ist nichts weiter als eine Klassensammlung, die sogar unter dem Motto „use at will“ propagiert wird. Wenn man z.B. nur Zend_Mail nutzen möchte, dann bindet man eben nur diese Komponente in sein Projekt ein.
Bei den komplexeren Komponenten müssen natürlich Abhängigkeiten beachtet werden, da sie andere Komponenten voraussetzen, aber grundsätzlich können die Klassen unabhängig benutzt werden.
Soll Zend jetzt jede mögliche Kombination von Komponenten als einzelnes Downloadpaket anbieten? Ich kann Deinen Anspruch und auch den praktischen Nutzen nicht nachvollziehen.
<<Wir splitten das Zend Framework in zwei Teile auf: die Zend Library und das Zend Framework
Den Satz habe ich nicht verstanden. Die Klassen, die zusammen das Gesamtangebot des Zend Frameworks bilden, liegen im Ordner library. Was ist für Dich dann das Zend Framework?
<<Dummerweise packen die Zend Leute das alles zusammen in ein Paket
Normalerweise kopiert man die Dateien zentral auf dem Server, packt den Ordner in das php-include-Verzeichnis und kann so aus X-Projekten heraus per simplen require auf eine zentrale Kopie der Zend-Klassen zugreifen (genau wie bei PEAR-Klassen). So können unterschiedliche Projekte unterschiedliche Komponenten nutzen und trotzdem muss nur eine zentrale Kopie gepflegt werden. Das ist doch eigentlich gut. 😉
Da Du das bemängelst, gehe ich davon aus, dass Du die benötigten Klassen (oder sogar alle?) jeweils in einen Unterordner des Projekts kopierst. Das bedeutet im Falle eines Updates natürlich Arbeit – und zwar für jedes Projekt. In der Regel referenziert man deshalb die Zend-Klassen lediglich, ohne sie physikalisch im konkreten Projektordner liegen zu haben.
Also ich kann den Vorschlag schon nachvollziehen. Aus meiner Sicht ist es zwar nicht weiter schlimm, die überflüssigen Komponenten auch zu haben. Inhaltlich ist die Trennung aber auf jeden Fall vorhanden. Da muss ich Nils 100%ig zustimmen.
Ist jetzt vielleicht etwas Off-Topic aber ich finde zudem, dass das Zend Framework noch einiges an zusätzlicher Funktionalität bieten könnte. Von einfacheren Hilfsfunktionen die man häufiger mal benötigt, habe leider spontan nichts parat, neulich war mir mal wieder etwas aufgefallen. Bis hin zur Generierung von Standardansichten ala Zend_Form, z.B. für Tabellen… hier wäre aus meiner Sicht einiges möglich, schließlich sind Tabellen doch recht standardisiert aufzubauen und es gibt nette Möglichkeiten der weiteren Nutzung für ein Framework (Sortierung, Filterung, Export, …).
Hier würde mich mal interessieren, wie ihr generell die Frameworks kombiniert. Setzt ihr auch viele Pear-Komponenten ein (man muss ja auch die verschiedenen Konzepte und Schreibweisen beachten, das kann auch nerven!!).
Danke für eure Kommentare!
Also das ZF kenn ich nur grob, aber meiner Meinung nach sind viele kleine Packete angenehmer, da nur noch das am Projekt hängt, was gebraucht wird.
Wenn man dann auch noch ein Dependency Management System einführen würde, wäre das auch nicht mehr aufwendig, da „komplexere“ Packete ihre Abhängigkeiten selbst definieren und man wirklich nur noch das einbindet, was man wirklich benötigt.
Nur so ein kleiner Anreiz aus der Java Welt. 😉
Anleihen aus der Java-Welt nehme ich normalerweise gerne mit, daher auch mein Hinweis auf die PHAR-Archive.
Ich möchte hier allerdings ein paar Dinge zu bedenken geben:
– Java bietet die Möglichkeit Desktop und Server-Applikationen zu erstellen, daher benötigt eine Desktop-Applikation z.B. die Web-Komponenten des Spring-Frameworks nicht und würde die Größe nur unnötig aufblähen. (Desktop-Applikationen mit PHP sind doch eher Exoten.)
– In Java ist ein Build-Vorgang selbstverständlich und mit z.B. Maven gibt es etablierte Tools für das Dependency Management – in der PHP-Welt ist vielen noch nicht einmal der Umgang mit Ant/Phing geläufig, gar nicht zu reden von Maven oder ähnlichem.
– PEAR ist schön und gut, leider in der PHP-Welt auch nicht so weit verbreitet, wie es sein könnte. So weit ich weiss, hat PEAR aber den Nachteil, dass man unterschiedliche Versionen einer Bibliothek nicht parallel installieren kann. Hier benötigt man wieder weitgehend unbekannte Tools wie pearanha oder pantr.
Daneben gibt es dann noch ein paar Dinge, die es – zumindest in einer Übergangsphase – kompliziert machen:
– Eine fehlende Konvention für Paketnamen
– Eine unzureichende Unterstützung – bzw. fehlende Konvention – für die Bereitstellungspfade (Für PEAR gibt es ja eine solche Konvention, aber wie viele Libraries in der PHP-Welt werden über PEAR angeboten?)
Nun aber wieder der Bogen zurück zum ZF:
Hier bieten es sich dann natürlich an, das ZF in ein paar Pakete zu organisieren, was ja mit ZF2 angedacht ist, so weit ich mich da richtig erinnere.
An dieser Stelle wird der ein oder andere sagen: Hier widerspricht er sich doch mit dem, was er vorher geschrieben hat!
Jein, ich gebe zu, dass ich mir eine (auch jetzt schon teilweise vorhandene) logische Gliederung in diese Abschnitte wünsche und mit dem packen dieser Bereiche in einzelne PHARs, käme man sicher nicht nur Nils entgegen. Eine zwingende Notwendigkeit sehe ich dafür allerdings aus den oben genannten Gründen nicht, es würde höchstens zu einer besseren Übersichtlichkeit beitragen und den „Paketgedanken“ weiter in der PHP-Welt bekannt machen und etablieren.
In dem Zusammenhang vielleicht interessant: http://pear.zfcampus.org/
Die Idee ist doch nicht neu und wurde auch schon etliche Male diskutiert, sogar inklusive Lösungsansätzen und Anwendungsmöglichkeiten. Aber da gerade die Entwicklung der Version 2 in Arbeit ist und diese auch noch eine Weile dauert, führt die Paketaufteilung und deren Verteilung zu „ungelegten Eiern“.
„Warum ist das aber doof? […] Jetzt versucht mal das Zend Framework einzuführen. Ist gar nicht mal einfach kann ich euch sagen.“
Dass ein paar Betonköpfe die Möglichkeit nicht akzeptieren wollen, ZF auch als Library einzusetzen, kann doch wohl kein ernsthaftes Argument sein, ein Projekt zu splitten.
Oder verstehe ich dich da falsch?
Naja Symfony macht es ja genau richtig an der Stelle. Die haben es aufgesplittet. Es gibt Symfony als Full Stack Framework und die Symfony Components. Finde ich sauber gelöst.
War im Launch-Stress, deshalb melde ich mich erst heute. Ob überflüssig oder nicht, sowas in der Art wird es im ZF2 geben.
http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Requirements#ZendFramework2.0Requirements-Providemechanismsforusingjustthepartsoftheframeworkneeded