[php] 'portables', kleines framework

["Dr. Volker Göbbels"]

Ahoi ;)

Carola 'Sammy' Kummert schrieb:

> DB-Abstraction ist nur bedingt nuetzlich - der Normalfall ist, dass du 
> als Entwickler weiszt, fuer welche Plattform deine Anwendung gedacht 
> ist und Queries plattformabhaengig optimierst. Nun unterscheiden sich 
> Optimierungsmoeglichkeiten (und auch die Implementierungen der 
> verschiedenen SQL-Standards sowie zusaetzlicher Features) der 
> jeweiligen Datenbanken teilweise doch recht drastisch voneinander, 
> daher zahlt sich eine Abstraktionsebene bestenfalls aus, wenn man ein 
> OS-Multiplattform-Projekt startet.

DB Abstraktion auf der Ebene eines ADOdb, also nicht als ORM sondern als 
DB Layer ist definitiv wünschenswert. Ich möchte in keinem Projekt 
sehen, wie einer meiner Leute mit mysql_* oder mysqli_* Funktionen rum 
kaspert.

> Smarty ist ... diskussionsfaehig. Nett zum Einsteigen in die Materie, 
> praktisch bei groeszeren Anwendungen nur bedingt einsetzbar. Das geht 
> bei expliziter Zuweisung von Variablen an Templates los, die der 
> Programmierer taetigen muss und endet irgendwo beim Thema 
> Performancetuning. Kann man alles machen, muss man aber nicht. Fuer 
> Kleinprojekte mit absehbar wenig Changes in der Oberflaeche mags angehen.

*nörgs* Einspruch ;) Wie man die Daten an ein Smarty übergibt, kann man 
ja selbst entscheiden. Natürlich kann man sich einen View bauen, der 
alle Attribute des Controllers oder Models direkt in die Template Engine 
pumpt. Aber auch das möchte man nicht unbedingt, für so etwas ist PHP 
definitiv nicht ausgelegt.
Performancetuning ist bei Smarty in den seltensten Fällen ein Problem. 
Wer damit ein solches hat, setzt keinen Opcode Cache ein oder hat die 
Optionen nicht korrekt eingesetzt, die Smarty da von Hause aus bietet.

Und auch hier wieder: PHP selbst als Template Engine ist ein absolutes 
No-No. Das hat außer Pseudo-Coolness nichts zu bieten, was von Vorteil 
wäre ;)

Richtig gut und elegant wäre eine XHTML-Attribut-baiserte Template 
Engine wie Kid oder Genshi, aber das gibts ja leider nicht für PHP ;)

> Wenn du Rails nicht magst, ist vermutlich Symphony auch nichts fuer 
> dich, das ist im Prinzip eine Rails-Nachbildung. Wie ueblich noch ein 
> wenig pessimiert in der Art der Umsetzung, aber die Community ist 
> nett. Btw, ist der Symphony-Hype inzwischen eigentlich wieder ein 
> bisschen abgeklungen?

Ich denke mal, im Moment gibts da ein Kopf-an-Kopfrennen zwischen 
CakePHP, CodeIgniter und Symphony. Ich nutze keines von denen, weil 
keines davon von Hause aus eine gescheite Template Engine bietet ;)

> Das mit der einen Config-Datei kann je nach Framework-Design zu 
> Problemen fuehren - wenn ich mir ein modulares Framework vorstelle, in 
> der es zwar eine "Zentralconfig" gibt, aber die einzelnen Module im 
> Zweifelsfall noch eigene Konfigurationsmoeglichkeiten mitbringen, kann 
> das zum Beispiel den Vorteil haben, dass fuer das Modul explizit 
> andere Umgebungsvariablen definiert werden koennen, die nur dann 
> interessant werden, wenn dieses Modul auch aktiv im Code 
> genutzt/angesprochen wird.

Klingt theoretisch nett, praktisch möchte ich kaskadierte Configs in 
Modulen oder Sub-Modulen in keiner Applikation sehen, die ich oder wir 
betreuen müssen. Da bin ich ein starker Anhänger von Coding by 
Convention zum Vorteil der Wartbarkeit.

> Eine einzige Config kann ziemlich stark aufgeblasen werden, wenn man 
> darin jede Menge unterschiedlicher Module mit Parametern versieht - 
> auch wenn man sie fuer den gerade anstehenden Aufruf nicht benoetigt. 
> Allerdings reden wir hier von einem Framework, und das bedeutet von 
> Hause aus meist zusaetzliche Abstraktionsebenen und Latenzen, nur 
> selten sind Frameworks auf Geschwindigkeit getrimmt.

Hier gilt dasselbe wie oben: ab einem gewissen Grad der 
Konfigurierbarkeit ist das nicht mehr wartbar und das will man nicht ;)

> Zend Framework ist super. So als Marketingding. In der Praxis freut es 
> mich auch immer, weil es bedeutet, dass ich Arbeit bekomme ;) (Fakten: 
> Instabil, uneinheitliche API, langsam, ich weiß nicht, warum sie einen 
> Quality-Manager fuer das Ding haben, Codequalitaet ist fuer mich was 
> anderes.)

Ist verschieden: manche Teile des ZF sind von guter Qualität und auch 
gut nutzbar, bei anderen frag ich mich, warum man nur die halbe zu 
lösende Aufgabe programmiert hat (wie bei den ACLs zum Beispiel, die 
sind alleine vom Konzept her nur schlecht).

> Symphony macht nur Spaß, wenn du RoR magst, das aber in PHP haben willst.

Generatorscripte finde ich nicht unbedingt falsch, wenn das Framework 
nicht auf Quickshots spezialisiert ist sondern auch längere 
Produkt-Entwicklungszyklen verträgt und die Entwickler dann immer noch 
unterstützt und nicht behindert ;)

> Praktischer Tipp:
> 
> Schnapp dir die Frameworks, die dir auf der Liste interessant 
> erschienen, versuche, sie zum Laufen zu bringen und damit Dinge zu 
> realisieren. Benchmarke vergleichbare Endergebnisse. Ueberlege dir, 
> wieviel Einarbeitungsaufwand du jeweils hattest, wie gut das Ding 
> vermutlich skaliert und wieviele Projekte du damit umsetzen wirst. 
> Wenn du das Gefuehl hast, aus dieser Mischung etwas zu bekommen, das 
> sich fuer dich gut anfuehlt, bist du vermutlich auf dem richtigen Weg.

Ich glaube, das ist eine hervorragende Idee. Wichtiger als Performance 
wären mir Code Qualität, Wartbarkeit der entstehenden Applikation sowie 
"Wohlfühlfaktor" der Entwickler. Ich muß mich als Entwickler in dem 
Biotop, welches das Framework aufspannt wohl fühlen. Wenns dann nicht 
allzu grottig programmiert ist, klappts auch mit der Performance ;)

Viele Grüße,
Volker Göbbels
-- 
Dr. Volker Göbbels, Technology Scouting
Arachnion GmbH & Co. KG, Paulinenstraße 28, 52146 Würselen
http://www.arachnion.de, http://twitter.com/VolkerGoebbels
Registered: AmtsG Aachen, HRA 4674, GF Dr. V. Göbbels