exTSend - meine kleine Erweiterungslib für das ZF

[G.Schuster]

Hallo,

Ich hab während der Entwicklung mit dem ZF das ein oder andere kleine Plugin geschrieben und dachte, das könnte vielleicht für den ein oder anderen ENtwickler interessant sein.
Daher habe ich das Ganze mal zusammengepackt, ihm den Namen exTSend gegeben und es zum Download bereitgestellt.

Ich muss dazu sagen, dass die Lib nicht annähernd vollständig ist, der ein oder andere Part könnte aber als Anregungsquelle oder aber auch direkt as-is interessant sein.
Ich arbeite derzeit noch am Fertig-Paket und ein paar Beispielen, da insbesondere die Model-Implementation vielleicht nicht ganz so leicht aus den SourceComments verständlich sein könnte.

Ich würde mich freuen, wenn sich der interessierte Leser das mal ansieht und vielleicht ein bisschen Feedback gibt.

Downloads gibt's hier: http://www.extsend.com

[deetee]

Könntest du eine phpdoc API online stellen? Hab gerade versucht eine zu erstellen, aber es wird schon gemeckert a la

"ERROR in Acl.php on line 76: "@staticvar" tag was used without any parameters, illegal"

Wäre nett, weil nur durch Quelltext wuseln ist recht anstrengend. Würde gern mal dein Model ausprobieren, dazu wäre ne API recht praktisch für den Überblick.

[G.Schuster]

Ich werd schauen, ob ich das im Laufe des Tages hinbekomme.
Vielleicht schaff ich es sogar, das versprochene Paket fertig zu machen.

[G.Schuster]

So, phpDoc ist Online: http://www.extsend.com/phpdoc/index.html

[KingCrunch]

Seh ich das falsch, oder is sie leer?

[Bleistift]

Siehst du falsch. Links das Package wählen und dann links ganz unten die Klasse.

[KingCrunch]

Zitat von Bleistift

Siehst du falsch. Links das Package wählen und dann links ganz unten die Klasse.

Danke

[G.Schuster]

Sorry, ist das erste Mal, dass ich mit phpDoc arbeite...bin mit den Tags noch nicht ganz so vertraut aber ich denke da kann man mit etwas goodwill ja drüber wegsehen

[KingCrunch]

Zitat von G.Schuster

Sorry, ist das erste Mal, dass ich mit phpDoc arbeite...bin mit den Tags noch nicht ganz so vertraut aber ich denke da kann man mit etwas goodwill ja drüber wegsehen

Mach dir ma keinen Kopp, das lag jetz am gewählten Ausgabeformat, an dem ich () gescheitert bin

[deetee]

Also mir gefällt die Lib, ich werde meine Models darauf aufbauen.

Noch ein tipp, es wäre angenehmer, wenn du das phpdoc Tag @filesource in den page-level docblock einfügen würdest. Damit kann man dann auch von der API aus den Quellcode ansehen.

[G.Schuster]

Werd ich mir die Tage ansehen.
Ich arbeite grade eh schon weiter dran, wenn ich die Zeit finde gibt's hoffentlich Ende nächster Woche endlich ein "working example".
Das Model-Thema ist ja nicht ganz so einfach umgesetzt, insbesondere was verknüpfte Models angeht.
Aber es funktioniert bei mir zumindest...ich hoffe, dass das bei anderen dann auch so klappt.

PS: Über ein bisschen Mundpropaganda (und natürlich auch Ergänzungs-/Korrekturvorschläge) würd ich mich freuen.

[G.Schuster]

So, hab es nun endlich geschafft eine einfach Demo zu bauen.
Ist vom Umfang sehr rudimentär damit man überhaupt etwas sieht - vor allem aber, damit man Beispiele für die Model-Implementation hat.
Ausreichend Verständnis muss man aber dennoch mitbringen, da die Resourcen als auch die Rollen in Nested Sets verwaltet werden.
Demo-Link und Download gibt's auf der Seite.

@deetee: filesource ist drin.

[Bleistift]

Ich schau mir das mal am WE an... Eine Frage noch: Woher kommt der Name?

[G.Schuster]

Der Name ist abgeleitet von einer Kombination aus "extend" (erweitern) und Zend.
exZend wäre aber namensrechtlich bedenklich gewesen, für exTSend hab ich jedoch eine Genehmigung bekommen und ausgesprochen hört es sich recht ähnlich an.

[deetee]

Falls du UML Diagramme hast die du veröffentlichen würdest, ich wäre interessiert.

[Marco]

schöne Sache, werde ich mir die Tage auf jeden Fall mal anschauen.

gruß marco

[deetee]

Schade, aber ich bekomme dein Model nicht integriert. Ich dachte nicht, dass dermaßen viele Abhängigkeiten existieren, um dein Model zu nutzen. Habe gehofft es wärer mit einem simplen Ableiten von exTSend_Model getan, und der Rest ist mehr oder weniger frei wählbar. Habe mich noch breitschlagen lassen, als ich merkte, dass Models mit "Model_" beginnen müssen, dass man nur mit den mitgelieferten Loader Klassen Zugriff auf die Models bekommt und noch diverse andere Kleinigkeiten. Aber ein Interface zu erstellen, welches von irgendeinem Adapter genutzt wird, von dem man zu dem Zeitpunkt noch nichts weiß, z.B. wozu man ihn braucht. Durch deine Demo App habe ich gesehen, dass das Interface nichtmal von dem Model implementiert werden muss, was mich dann doch etwas verwirrte, weil ich absolut nicht mehr wusste, was da eigentlich genau passiert!

Fazit: Um dein Model zu nutzen muss man für meinen Geschmack zuviele Kompromisse eingehen. Die Namenskonventionen und die Verzeichnisstruktur wäre ja noch akzeptabel für mich, aber dass z.B. Interfaces (evtl. auch Exceptions?) erstellt werden müssen, die man sonst so nicht eingeführt hätte und die man nichtmal in seine Model Klasse per "implements" hinzufügen muss, das war dann der Punkt an dem ich nicht mehr wollte

Aufgrund der vielen Abhängigkeiten würde ich deine Lib eher als Framework sehen. Kann man die Abhängigkeiten, wie Namenskonventionen per Setter eigentlich an eigene Bedürfnisse anpassen?
Außerdem dürfte es eine recht aufwendige Sache sein eine bestehende Model Klasse auf dein Model zu migrieren. Das war nämlich mein erster Versuch, den ich ganz schnell aufgab, um evtl. durch ein neu erstelltes Model erstmal zu sehen wie alles funktioniert.


Also nciht falsch verstehen, ich finde deine Arbeit klasse, aber es ist echt schwierig dein Model zu nutzen. Die Demo hat geholfen die Abhängigkeiten schneller zu erkennen. Ich habe gehofft durch deine abstrakte Model Klasse eine Basis für meine Modelstruktur schaffen zu können.
Und meine Kritik gilt auch nur für den Model Part! Kann sein, dass der Rest leichter zu nutzen ist, kann ich nicht sagen.

[G.Schuster]

Die Models sind nicht einfach, das ist richtig.
Mir ging es bei der Implementierung vor allem darum, Restriktivität in Bezug auf vernünftige Erfüllung gewisser Vorgaben mit der Flexibilität, so gut wie alle Daten darüber laufen lassen zu können zu verbinden.
Ich hatte anfangs einen viel grausigeren Ansatz, bei dem man die Felder einzeln zusammenbauen musste...dagegen ist der Ansatz doch recht einfach.

Zum Thema Interface - die werden implementiert - von den Adaptern.
Sinn und Zweck ist, im Model (z.B. SharedModel_Group) das Objekt und die verfügbaren öffentlichen Methoden zu definieren.
Um dann auch Daten verarbeiten zu können gibt es einen entsprechenden Unterordner, in dem ein Adapter-Interface (SharedModel_Group_Interface) und theoretisch eine beliebige Anzahl an Adaptern liegt.
Da generische Adapter selten "gut gehen" habe ich mich eben für den Weg entschieden, dass man pro Model die Adapter genauer spezifizieren muss (mehr oder weniger simples CRUD).
Sind also mindestens drei Dateien, die man erstellen muss, um ein Model verwenden zu können - was ich jetzt nicht soooo schwierig finde.

Allgemein sei gesagt, dass die Lib natürlich recht stark auf das zugeschnitten ist, was ich tagtäglich mache - Kundenprojekte mit einer bestimmten, von mir ausgedachten, Struktur.
Würde ich mit täglich 3 Stunden Arbeit Millionen scheffeln und hätte somit 90% des Tages frei würde ich mir sicher mehr Gedanken machen, wie man das Ganze allgemeintauglicher machen könnte.
So muss es eben das tun, was bei der spezifischen Projektarbeit rausspringt - und das unterliegt dann eben gewissen Restriktionen wie Namenskonventionen oder Interface-Vorgaben.
Das war und ist auch ein Grund, warum ich exTSend mehr als Inspirationsquelle für Andere veröffentlicht habe - weil es sehr spezifisch für meine Anforderungen ist, mit etwas Offenheit aber durchaus auch As-Is von Anderen eingesetzt werden könnte.

So, genug geschrieben für die frühe Uhrzeit...und danke für dein ehrliches Feedback, das weiß ich zu schätzen.