stf.stream

Beste Grüsse aus der Sonne ,

hat von euch jemand bereits mit dem Symfony-Framework gearbeitet??
Tips - Hinweise - Meinungen - 'n gutes Tutorial, ich suche alle Infos, die über 'ne Google-Recherche hinausgehen.
Muss innerhalb kurzer Zeit fit sein und bin daher dankbar für jede Hilfe.

mfg @stf

__________________
stf.

Mister Ad

Basti

Hi "stf".

Ich bin gerade dabei, mir das Manual anzusehen und bin schwer begeistert. Man liest und liest und denkt nur: Ah, daran haben sie auch gedacht ... genau ... aber wie lösen sie dann das Problem xy? (zwei Absätze später) ... cool, haben sie auch bedacht. Also irgendwie paradiesisch.

Also hört sich für mich alles sehr gut an. Allerdings hab ich mir bisher weder den Code angeschaut, noch mir alles durchgelesen oder gar damit gearbeitet. Die Punkt, bei denen ich angeeckt bin:

* ORM und ActiveRecords (über Propel): ist zwar komfortabel, aber auch sicher nicht die performateste Lösung. Ist aber auch optional bzw. auch erweiterbar, ohne danach noch auf automatische Builds bei DB-Änderungen verzichten zu müssen;

* Teilweise ellenlange Folgen von Konstanten;

* Frag mich, obs nicht Namenskonflikte bei den Action-Klassen geben kann, wenn mehrere Actions in unterschiedlichen Modulen je durch eine eigene Klasse umgesetzt sind;

* Der Application-Flow wird vollständig innerhalb der Controller (Actions) gesteuert. Dort gibst du also entweder ein Template aus oder macht einen Forward (interne Weiterleitung mit Beendigung des aktuellen Prozesses) oder ein HTTP-Redirect.

* Die Aufbereitung der View-Daten geschieht anscheinend bis auf ein paar Helpers, die in den Templates zur Verfügung stehen ausschließlich in den Action-Objekten. Ich mag es, wenn man zur vereinfachung der Templates diese nicht anfassen muss, sondern noch ein View-Objekt hat, in dem man z.B. einen Flag setzen kann, der das Ergebnis einer bestimmten Bedingung enthält, um die Abfrage dann nicht im Template machen zu müssen. Auch funktioniert das ganze Template-System via Push-Mechanismus und ich denke, es ist keine schlechte Idee, die Daten, die aus der DB kommen erst bei der Ausgabe Datensatzweise aus der Ergebnisliste zu ziehen und dann ggf. noch zu modifizieren. Hab das aber auch noch nicht ausprobiert, denke aber, das würde Sinn machen.

Soweit mal meine Gedanken.

Tutorials brauchst du definitiv nicht. Das Projekt hat die beste Dokumentation, die ich je bei einem so jungen OS-Projekt gesehen habe (wobei ich da sicherlich einiges übersehen hab, klar). Da ist alles harklein beschriben und es bleiben erstmal kaum GFragen offen.

Ich werd mir das in jedem Fall näher anschauen.

Ach ja, hab gesehen, dass im neuen PHP-Magazin (oder phpsolmag?) ein Artikel darüber abgedruckt ist. Ich vermute aber, das ist einfach nur die Dokumentation zusammengeschnurpselt, übersetzt und auf irgendeine Mini-Anwendung angewendet. Also wahrscheinlich rausgeschmissenes Geld, wenn man die 10 Öre nur für diesen Artikel ausgibt.

Viel Spaß.
Basti

stf.stream

Hi basti,

erstmal danke für dein Interesse und deine Gedanken zum Framework. Ich hab jetzt 'n bißchen rumprobiert und bin zu folgendem Ergebnis gekommen:

*Installation ist eigendlich verhältnissmässig easy. Einzig die Tatsache, dass die verschiedenen benötigten Pakete (creole, propel, pake, phing, symfony) nicht so ohne weiteres in den zusammenpassenden Versionen vorliegen erweist sich als störend. (erfordert manuelle Anpassung der package.xml: <channel> und <dependenies> bei pake).
Das virtual-hosting is bei lokaler installation 'n bißchen doof, andere Projekte sind erstmal nicht mehr erreichbar (wird wohl 'n Script abhilfe schaffen).

*Project-setup flutscht ohne Ende. Tolle Sache das!

*Deine Bedenken hinsichtlich des Performanceverlustes durchs O/R-Mapping sind leider begründet. Selbst ein leeres Projekt (ohne irgendwelche Actions) mutet ein wenig wie 'n Panzer an: gewaltig leistungsstark, aber nicht sehr schnell.
Ich denke durch caching wird da noch einiges rausgeholt. (hab bisher nur die Produktionsumgebung getestet, die is ohne caching)

*Ich kann mir nicht vorstellen, wann die Dominanz der Controller hinsichtlich der Application-Fluss-steuerung von Nachteil sein sollten. Ist das Geschmackssache oder gibts da 'nen definitiven Nachteil?

------

Was ich mich frage ist, obs möglich ist Module zzgl. Actions dynamisch zu erzeugen um z.B. in 'nem ein CMS variable Pages (Module) anzubieten...
Ich arbeite daran :wink: .
Was ich mich noch Frage: was meinst du mit

?

Die Doku ist wirklich Klasse, hab ich mir gerade ausgedruckt! Tiefergehende Untersuchungen (Quelltext etc.) hab ich auch noch nicht gemacht, mal sehn was da zu Tage tritt...

viele Grüsse @stf

__________________
stf.

Basti

Was meinst du? Du kannst doch beliebig VHosts anlegen bzw. was ist daran anders, als wenn du eine Enwicklungsumgebung für ein anderes Projekt ausfetzt?

Na, wenn das "Projekt" noch leer ist, dann läugt da doch noch gerakeine Datenrumschieberei und vor allem Kompiererei. Insofern sollte die Langsamkeit in dem Stadium woanders drauf begründet sein, oder?

Ich glaube, es kann sehr nützlich sein, hier zumindest einen Application-Controller zu haben, der den Fluss zentral steuern, da die Komponenten dann nochmal einiges flexibler sind und die Bedienung womöglich einfacher. Ich hab aber auch noch mit kenen System gearbeitet, das sowas implementiert hat und selbst noch keine produktive Lösung fertg geschrieben. Aber diese Default-Werte, also dass sich die View aus dem Namen der Action + Rückgabewert eribt finde ich klasse und werde ich als Fallback übernehmen, denn in vielen Fällen laufen die Requests ja unabhängig voneinander und müssen nicht in einen Page-Flow-Kontext engebunden werden.

Was meinst du mit "dynamisch erzeugen"?

Ach, da war irgendwo in der Doku ein Eingangs-Skript (index.php), das ich glaub eine Konfig-Datei über lauter lange Konstanten eingebunden hat. Irgendwas, wie SF_ROOT_DIRECTORY . SF_DIRECTORY_SEPARATOR . SF_IRGENWAS_PATH . SF_DIRECTORY_SEPARATOT . ... Bei sowas stellt es mir die Haare!

Las mal weiter von deinen Erfahrungen hören!

Basti