debuggen du musst - Yoda Conditions in PHP

stackoverflow.com hat bei seinen Lesern mal nach typischem Programmierer-Jargon gefragt und die ein oder andere erheiternde Antwort erhalten. Eine schöne Zusammenfassung findet sich z.B. in diesem Post auf globalnerdy.com. Einen Begriff, nämlich den der "Yoda Condition" möchte ich hier mal herausgreifen: In einer condition, in der eine Konstante mit einer Variablen vergleicht, schreibt man nun nicht if ( var == const ) sondern if ( const == var ), was natürlich an falschen Satzbau erinnert - somit passt der Name "Yoda Condition" wie die Faust aufs Auge. Was nach schlechtem Stil klingt, hat jedoch durchaus seine Berechtigung und ist somit eigentlich der bessere Stil, es hilft nämlich, einen beliebten Tippfehler zu finden. Tippt man in Sprachen mit C-Syntax nämlich fälschlich statt dem Vergleichsoperator == ein = in die condition, passiert nämlich nicht das Erhoffte und dieser beliebte Fehler hat sicherlich hier und da schon mal zu Kopfzerbrechen und Haareraufen geführt.
Ich versuche im Folgenden mal den Vorteil einer Yoda Condition mit Hilfe von PHP zu verdeutlichen:
Vertippt man sich in der condition nicht, ist es egal, ob man die Variable mit der Konstanten oder umgekehrt vergleicht.

führt ebenso wie

zur Ausführung des Codeblocks, wenn denn $var tatsächlich 5 ist. Vertippe ich mich jedoch beim Vergleichsoperator, ist die condition wahr und der Codeblock wird ausgeführt, auch wenn ich das überhaupt nicht will:

Schlimmer noch, wenn ich durch den Fehler sogar die Variable verändere, die ich eigentlich nur überprüfen will. Debuggen wird da bei komplizierterem Code evtl. unnötig schwer. Gewöhne ich mir
stattdessen Yoda Conditions an, also etwa so:

meckert PHP zu Recht mit einem Parse error: syntax error, unexpected '=' in [...] und der Fehler fällt sofort ins Auge.

Was also wie komischer Stil aussieht, durchaus seinen Sinn es hat.

(Bild von drumecho auf flickr.com, CC-Lizenz)

Lempel-Ziv-Welch-Algorithmus

...neulich hab' ich mich mal wieder selten dämlich angestellt. Es ging darum, mal eben schnell den LZW-Algorithmus umzusetzen. Mal kurz: LZW dient zur verlustfreien Datenkompression mittels eines Wörterbuchs, das aber nicht zusätzlich zu den Daten abgelegt werden muß.
Ich hab' also in die deutsche Wikipedia geschaut und obwohl der Algo da schon sehr ausführlich beschrieben ist, bin ich an der Umsetzung erstmal gründlich gescheitert. Vieleicht hätte ich doch zuerst in dem englischen Artikel (oder woanders) nachschlagen sollen, der m.E. um einiges besser ist... Wie dem auch sein, nun tut es und ich hab' für Leute, die sich die Kodierung eines Strings mittels LZW mal ganz ausführlich ansehen wollen, mal eine Extreme-Verbose-Ausgabe (Achtung, utf-8!) an meine Implementierung drangeflanscht.
Und: Ja, ich weiß, so ist das natürlich auch kein Musterbeispiel für Übsersichtlichkeit.

mootools und so

...ich gebe ja zu, daß JavaScript* und ich noch nie richtig Freunde waren und es wahrscheinlich auch nicht mehr werden. Und obwohl ich - wenn man mich auf der Straße fragen würde - wohl nie eingestehen würde, daß es sinnvoll sein kann, irgend etwas nicht auf dem Server zu erledigen bevor man das Ergebnis ausliefert, weiche ich hier mal meine festbetonierte Meinung auf. Ich halte ja eigentlich nicht viel von blinkenden, fadenden oder sich bewegenden Elementen auf Webseiten, wenn ausklappbare oder slidende Elemente (Menüs, Infoboxen etc.) jedoch die Übersichtlichkeit und Bedienbarkeit der GUI (wenns denn schon in X- und oder HTML sein muß) verbessern... naja, dann von mir aus, denn: Man hat schließlich nicht unendlich viel Platz auf 'dem Bildschirm'.
Da ich selbst wenig mit JavaScript zu tun habe freue ich mich immer über bestenfalls gut dokumentierte und leicht zu verwendende Frameworks. Schon vor einiger Zeit fielen mir die mootools in die Hände, die ich 'irgendwann' mal ein bisschen ausprobieren wollte. Das habe ich jetzt getan, auch wenn das Ergebnis noch sehr dürftig und nur ein erstes Ausprobieren ist: Mit den Sortables aus mootools habe ich eine kleine Seite geschrieben, auf der man DVB-S-Fernsehsender nach Programmplatz sortieren kann, ein Klick auf den Button darunter erzeugt dann eine entsprechend sortierte channels.conf-Liste, die man sich rauskopieren und weiterverwenden kann. Die Angaben aus der Liste sind ohne Gewähr auf Richtigkeit und es fehlen auch einige Sender. Das Script war halt nur zum Spielen gedacht, nicht als vernünftig zu bedienendes Tool. Wie dem auch sei: 'Ajax und Web-two-ohh - hoppla, jetzt komm ich' - nein, nicht wirklich.

* "Java and Javascript are similar like Car and Carpet are similar." (Greg Hewgill)

Auto-props für PHP-Scripte

...um den Überblick über verschiedene Bearbeitungszustände seiner Dateien zu behalten, bietet sich (wie der Name schon verspricht) eine Versionsverwaltung an. Um nun - schaut man dann in die Dateien rein - eine schnelle Info zu bekommen, mit welcher Datei man es eigentlich zu tun hat und (möglicherweise auch wichtig), wer die Datei bearbeitet hat, lohnt es sich, diese Informationen gleich mit in der Datei zu speichern. Hierbei kann es schnell nerven, dies manuell machen zu müssen.
Für selbst recht kleine Scriptbasteleien in PHP stellte sich für mich heraus, daß diese 'Minimalversionskontrolle' aufwendig, fehleranfällig und dadurch total unbrauchbar ist.
Um das Schreiben von Informationen zu einer Datei (z.B. in den Kommentarheader) zu automatisieren, bietet Subversion Schlüsselwörter an, die in den Dateien z.B. bei einem commit durch den Namen des Autors, das Änderungsdatum oder die Versionsnummer ersetzt werden.
Erstellt man in PHP die Kommentarblöcke automatisch, lohnt es sich, gleich den entsprechenden Schlüssel mit eintragen zu lassen. Um die Kommentarblöcke zu erstellen nutze ich den DocBlockGenerator aus pear und, da ich Subversion nutze, lasse ich diesen über den Parameter version gleich den passenden Schlüssel eintragen ('version'=>'svn' im Parameterarray oder -v svn für docblockgen über die Kommandozeile).
Schaut man sich den Kommentarheader der Datei an, sieht man dort die Zeile
* @version SVN: $Id:$
mit dem Schlüssel $Id:$ für SVN.
An einem kleinen Beispiel möchte ich nun zeigen, daß Subversion dann auch das macht, was es soll:
Nehmen wir an, wir haben in /var/www/foo ein PHP-Script foo.php mit automatisch erzeugten Kommentarblöcken, möchten diese in ein Repository einpflegen und dabei soll Subversion den Schlüssel $Id:$ ersetzen.
Zuerst müssen wir Subversion so konfigurieren, daß es die Ersetzung auch durchführt. Auf Benutzerebene ändern wir hierzu die Konfigurationsdatei ~/.subversion/config, stellen darin unter [miscellany] enable-auto-props = yes und erstellen dann unter [auto-props] einen Eintrag, damit Subversion die Ersetzungen für PHP-Scripte vornimmt:
*.php = svn:eol-style=native;svn:keywords=Author Id Revision Date
(Für Dateien mit anderen Endungen (z.B. .tpl o.ä.) entsprechende Einträge)
Nun legen wir (z.B. im Homeverzeichnis) ein Repository für unser foo-Projekt an
svnadmin create $HOME/svn/foo
und pflegen unsere Daten ein
svn import /var/www/foo file://$HOME/svn/foo/trunk -m 'erster Import'
Als Client für SVN benutze ich RapidSVN. Hier kann man sich nun ein Bookmark auf das Repository erstellen und dies dann als 'New Working Copy' irgendwohin auschecken (siehe Bild).
Ein Blick in die Datei /trunk/foo.php unserer Arbeitskopie zeigt nun, daß Subversion tatsächlich den Schlüssel ersetzt hat. Im Kommentarheader steht nun eine ähnliche Zeile wie
* @version SVN: $Id: foo.php 1 2008-12-24 11:55:00Z bearbeiter $
Erstellt man aus den Kommentarblöcken mit z.B. dem phpDocumentor eine Dokumentation, hat man nun (natürlich) zu jeder Datei unter dem Punkt 'version' das entsprechende Bearbeitungsdatum, die Version und den Autor auf einen Blick.

Ach, und, um das nicht zu vergessen: Happy Birthday Debian!

(Bild: Screenshot RapidSVN mit foo als Repo und Arbeitskopie)

OpenLigaDB

...vor zwei Jahren hatte ich zur WM noch vergeblich genau sowas gesucht: Einen Webservice, der mir die aktuellen Spielergebnisse liefert. Natürlich gab es tausende Liveticker im Netz, aber einen Dienst, von dem man die Daten ordentlich abfragen konnte, hatte ich nicht gefunden (oder es gab halt keinen). Deshalb lief hier damals zu jedem Spiel ein eigener kleiner Rechner, von dem ich die Spielstände abfragen konnte - der Stromzähler lief natürlich ständig mit. Inzwischen sind knapp zwei Jahre ins Land gegangen und nun gibt es endlich einen offenen Dienst mit den Daten, die ich brauche: OpenLigaDB (Liga-Kürzel 'fem08' für die EM-Daten). Klappt auch (noch?) super soweit.
In diesem Sinne herzlichen Dank an den Betreiber und die fleißigen Dateneinpfleger!

(Bild: Ausschnitt aus der formatierten Ausgabe der OpenLigaDB-Daten von der EM08)

things to do

...eigentlich wollte ich mir ja auch noch das js-Framework mootools ansehen - das ein oder andere daraus kann man sicher hier oder da noch gut gebrauchen - und wo wir schon bei JavaScript sind: Drüben bei Kevin van Zonneveld werden momentan einige viele PHP-Funktionen in js gestrickt (php.js) - sollte ich mal gezwungen sein, irgendwas clientseitiges verbrechen zu müssen, werde ich bestimmt noch darauf zurückkommen. Momentan gilt jedoch: Keine Zeit, keine Zeit - zwischendurch wollte ja auch noch der Ubuntu-Rechner auf 8.04 geupgradet (schlimmes Wort) sein...
"Oh dear! Oh dear! I shall be too late!"

eXist

...es ist kalt, stürmisch, regnerisch und am frühen Nachmittag schon wieder stockdunkel. Was liegt da näher, als sich vor den knisternden Kamin flimmernden Monitor zu setzen und sich Software anzusehen, die man schon länger mal testen wollte. Heute werfe ich also mal einen kurzen Blick auf die XML-Datenbank eXist. Mein Gebastel fängt auch gleich recht unglücklich an - die jars von der Seite wollten nicht wirklich (weder die 1.0.2-rev5396 noch die 1.1.1-newcore) - im IRC rät man mir aber prompt zu den pre-release-binaries, die sich dann auch problemslos installieren lassen (1.1.2dev rev7005). So, Server angeworfen und auf Port 8080 kann man auch gleich das WebGui bewundern, sich einloggen und über 'Examples Setup' ein paar Testdaten importieren. In der XQuery-Sandbox kann man dann auch schon die ersten Anfragen abschicken, fein.
Als nächstes wollte ich ein paar eigene XML-Dateien in die Datenbank importieren - dies war mit dem Webstart-Client nicht wirklich ein Problem: Einfach das ganze Verzeichnis mit den XML-Dateien als neue Collection auswählen und danach die Maschine arbeiten lassen. In der Zwischenzeit könnte man sich z.B. XQuery ein wenig genauer ansehen...
Im Zusammenhang mit PHP ist mir XQuery bislang nur in Form der XQuery-Lite-Klasse über den Weg gelaufen, PHP5 selbst beherrscht ja nur XPath. Wie kommt man nun aber mit einem PHP-Script an die soeben in die frisch installierte Datenbank geschriebenen Daten? Am Einfachsten ist wohl der Zugriff über SOAP - einfach deshalb, da es schon eine PHP (bzw. Perl) -Klasse gibt, die einem die lästige Arbeit mit SOAP abnimmt. Die Klasse ::PheXist:: von Òscar Celma bringt schon die nötigen Methoden (connect, xquery, ...) mit und funktionierte in einem ersten Test tadellos.

GUIuiui

...heute bau ich mir mal ein kleines GUI für ein ebenso kleines PHP-CLI-Script. Nur so - um zu sehen, wie das so geht. Als Script habe ich ich hier 42 Zeilen PHP, die eine einfache Textdatei einlesen, die Daten umwandeln und in eine andere Textdatei schreiben. Die Namen der Dateien werden als Parameter übergeben. Nur zur Info: Die Ausgangsdaten sind eine zeilenweise Liste von Part-of-Speech-Tags, die erzeugte Datei ist eine Sequenzdatei, die man dem esthmm-Programm (Hidden Morkov Model) aus Tapas Kanungos UMDHMM-Paket übergeben kann. Das GUI bastel ich mit dem Kommander Dialog Editor - der liegt hier eh rum und mit dem klick ich mir jetzt ein paar Bedienelemente zusammen. Was wird gebraucht? Je ein FileSelector ('infile' und 'outfile') für die Auswahl der Ein- und Ausgabedatei, ein Knopf, der das Script starten soll und dann noch zwei Textfelder zur Anzeige der Dateiinhalte. In den Kommander Text des Knopfes kommt die Scriptausführung mittels @exec(php pos2seq.php -i @infile.text -o @outfile.text) - das Script pos2seq nimmt die Parameter -i und -o, @infile.text und @outfile.text sind die Dateinamen, die die Fileselektoren infile und outfile zurückliefern. Jetzt noch dafür sorgen, daß die Textdateien in den Textfeldern angezeigt werden. Das erste Textfeld verbinden ich mit dem ersten Fileselector - als Signal TextChanged, als Slot populate das Textfeld fülle ich bei populate mit @File.read(@infile.text), also dem Inhalt der ausgewählten Datei. Nun binde ich noch das zweite Textfeld an den Knopf und erstelle eine Connection, die dieses Textfeld löscht, wenn eine andere Ausgabedatei ausgewählt werden sollte. Fertig. Und hübsch. Das GUI funktioniert auch tatsächlich - man übergibt dem kmdr-executor einfach die kmdr-Datei - das Bild zeigt das Ergebnis nach Scriptaufruf.

Graphen

...im Zusammenhang mit einem Kurs in Automatentheorie und der Implementierung des FSA2DFA-Algos bin ich damals auch über die Programmbibliothek graphviz von AT&T gestolpert, da diese Automaten sehr schön darstellen kann. Neulich kamen mir diese Programme wieder in den Sinn, als es darum ging, wie und womit man bestimmte Daten als ungerichtete Graphen darstellen könnte. Da diese Graphen in XHTML eingebunden werden sollen, fiel mir (neben Rasterdaten) sofort SVG ein - Grund genug, nochmal nach der alten graphviz-Installation zu suchen und... ja, es kann SVG exportieren - super! Ein paar kleine Veränderungen am SVG - z.B. Links auf die Label der Kanten setzen - und schon hätte man den Graphen, den man braucht. Der Paketmanager verriet mir auch gleich, daß es wohl sogar bindings für PHP gibt - dazu nur leider noch nicht die entsprechenden Einträge im Manual.

CVS - update

...heute steht eine weitere kleine Sitzung an unserem 'Hello World!!!'-Projekt an. Gleich stolpern wir über die erste Unaufmerksamkeit des vorigen Tages: CVS meldet ein 'No CVSROOT specified!' zurück, da wir gestern vergessen haben, unsere Umgebungsvariablen in die .profile oder die .bashrc unseres Homeverzeichnisses einzutragen. Da wir keine Lust haben, die Umgebungsvariablen bei jeder Sitzung neu zu setzen, holen wir dies schnell nach. Bevor wir uns nun an die Scripte setzen, gleichen wir unsere lokale Arbeitskopie mit dem Repository ab. Da wir ein wenig ungeduldig sind, lassen wir uns nicht erst mit
cvs -n -q update
die Dateien anzeigen, die aktualisiert werden müssen sondern führen mit
ich@client:~/Webseite$ cvs update
die Aktualisierung unserer lokalen Arbeiskopie direkt aus. CVS antwortet mit
cvs update: Updating .
P index.php
cvs update: Updating classes
P classes/HelloWorld.class.php
U classes/Html.class.php
und zeigt uns, daß unsere Scripte von gestern leicht abgeändert wurden (P = Patch) und, daß die Datei classes/Html.class.php in unserer Arbeitskopie komplett aktualisiert wurde (U = Update) - in diesem Fall ist die Datei unserem lokalen Verzeichnis hinzugefügt worden, da sie vorher nicht existierte. (Da hat also jemand an unseren Scripten weitergeschrieben.) Eine Beschreibung von update und dessen output findet man hier.
Ein cvs rlog Webseite zeigt uns dann noch an, welche Änderungen unsere Scripte erfahren haben und, was es mit der neuen Klasse Html auf sich hat. Nun können wir uns erstmal wieder unseren Scripten widmen und uns evtl. darüber aufregen, welchen Nonsense der andere Programmierer da fabriziert hat.

CVS - checkout und commit

...inzwischen langweilt uns das Script unsäglich und verlangt nach einer Änderung. Hinter dem 'Hello World' sollen mindestens ein paar Ausrufezeichen erscheinen. Wir löschen also die blöden Scripte auf dem Client oder schieben sie mit einem
ich@client:~$ mv Webseite Webseite.orig
aus dem Weg, da wir sie uns anschließend mit einem
ich@client:~$ cvs checkout Webseite
aus dem Repository holen wollen. CVS meldet
cvs checkout: Updating Webseite
U Webseite/index.php
cvs checkout: Updating Webseite/classes
U Webseite/classes/HelloWorld.class.php
und wir haben nun im Verzeichnis 'Webseite' die zu bearbeitenden Scripte. Am langweiligsten wäre es, in der Methode printOut das echo zu ändern. In meiner Überarbeitung der Scripte kommt mindestens eine Klassenvariable (und natürlich eine Methode, diese zu setzen) vor - aber das sei jedem selbst überlassen. Meine Änderungen betreffen sowohl die index.php als auch die HelloWorld.class.php und führen zu folgendem Ergebnis:
ich@client:~$ php index.php
> Hello World!!!
Da die Scripte wie gewünscht funktionieren, stellt man sie mit
cvs commit -m "mit Ausrufezeichen" Webseite
zurück ins Repository. Das commit umfasst hier das gesamte Modul, da ich ja beide Scripte geändet habe. CVS antwortet mit einem braven
cvs commit: Examining Webseite
cvs commit: Examining Webseite/classes
/home/ich/CVS/Webseite/index.php,v <-- Webseite/index.php
new revision: 1.2; previous revision: 1.1
/home/ich/CVS/Webseite/classes/HelloWorld.class.php,v <-- Webseite/classes/HelloWorld.class.php
new revision: 1.2; previous revision: 1.1
und hat die Revision von 1.1 auf 1.2 geändert. Ein
ich@client:~$ cvs rlog Webseite
zeigt diesmal an, welche Zeilen der Dateien geändert wurde, wer es war und wann.

CVS - ein erstes import

...wo war ich? Richtig, ich wollte ein tolles Script schreiben und das dann ins Repository übertragen. Lokal habe ich mir als ein Verzeichnis 'Webseite' angelegt, darin ein Verzeichnis 'classes'. In 'Webseite' habe ich folgendes Script index.php erstellt

<?php
include ('./classes/HelloWorld.class.php');
$helloworld = new HelloWorld;
$helloworld->printOut();
?>

und in 'classes' eine HelloWorld-Klasse (HelloWorld.class.php)

<?php
class HelloWorld {
 function HelloWorld() {
 }
 function printOut() {
   echo "Hello World\n";
 }
}
?>

Ein Aufruf von
ich@client:~/Webseite$ php index.php
liefert mir das gewünschte
> Hello World
Das Script funktioniert - hooray! Von der Hoffnung beseelt, daß dieses Script einmal etwas ganz großartiges wird, wenn es denn erst im Repository steht, führen wir das erste import aus
ich@client:~/Webseite$ cvs import -m "Wenn ich groß bin werde ich eine Webseite" Webseite PearlsForSwine-Software start
Dem import geben wir per -m einen Eintrag für's Log mit. Die letzten drei Parameter sind für den Namen des Moduls (hier: Webseite), für den Hersteller und für die Version (hier: start). CVS antwortet mit einem
I Webseite/CVS
I Webseite/classes/CVS
N Webseite/index.php
cvs import: Importing /home/ich/CVS/Webseite/classes
N Webseite/classes/HelloWorld.class.php
No conflicts created by this import
Na, das sieht doch gut aus. Wir haben nun im Repository ein Modulverzeichnis 'Webseite' angelegt und unsere Scripte übertragen. Jetzt schauen wir uns noch mit
ich@client:~/Webseite$ cvs rlog Webseite
das Log für unser Modul 'Webseite' an. Head 1.1, Revision 1.1, unser Kommentar ist auch drin - sieht gut aus.

INSERT und SELECT und so

...jetzt wird es aber Zeit für ein weiteres 'aha, klappt, gut'-Erlebnis. Wir wollten unsere Formulardaten noch in die Datenbank schreiben und wieder auslesen. Dem INSERT, das in etwa so aussehen könnte
INSERT INTO foobar ( eingabefeld, textfeld ) VALUES ( [hier die $_POST-Vars] )
übergeben wir einfach die Werte aus $_POST - sträflicherweise unüberprüft, ist ja erstmal nur ein lokales Testscript. Danach lesen wir die Datenbanktabelle gleich wieder aus (SELECT) und lassen uns die Werte aus den Spalten eingabefeld und textfeld tabellarisch ausgeben. Man beachte hier die Sortierung (ORDER BY eingabefeld) mit utf8_unicode_ci (siehe Bild), das Resultat einer Sortierung mit utf8_general_ci ist in diesem Fall identisch. Wäre jetzt wohl zu viel verlangt, daß nicht nur die o und u mit Diakritika (ja sie werden irgendwie), sondern auch ö und ü unter o und u einsortiert werden... Naja, aber immerhin: utf8 hat mit MySql jedenfalls erstmal ganz gut funktioniert.

Accept-Charset: UTF-8

...nachdem wir neulich ein schönes XHTML in utf-8 gebaut und ausgeliefert haben, wollen wir heute doch mal testen, ob man Unicode-Zeichen auch mit einem Formular verwenden kann und, was davon nach dem Verschicken noch ankommt. Der Server kennt offenbar de_DE.UTF-8, das sagt uns auch 'locale' bzw. setlocale(LC_ALL,'de_DE.UTF-8') in PHP. Im HTTP-Header steht bereits Accept-Charset: UTF-8,*, deshalb können wir wohl darauf verzichten, dies per header() zu setzen (oder gar dies im form anzugeben) - gut. Die Spannung steigt. Nun noch ein Formular bauen und sich vom Script $_POST ausgeben lassen, damit man sieht, was übermittelt wurde. Das Ergebnis sieht doch gut aus (die kleinen o über den v sind angekommen). An dieser Stelle darf man sich wohl aber schon ein wenig fürchten, weil PHP kein Unicode beherrscht (man beachte die var_dump-Ausgabe: "string(18)? Aber das sind doch nur 6 Zeichen..." Denkste!).

(Ich habe übrigens keinen blassen Schimmer, was genau ich da in das erste Textfeld geschrieben habe, es sollte bestenfalls niemanden beleidigen...)

dokumentier' heut' Nacht mit mir!

...was macht man an einem Samstag? Also außer Kaffee trinken? Na, sich mal den Berg noch zu dokumentierende Software vorzunehmen und lustig loslegen. Zu dem Zweck und, da in Zukunft mal zur Abwechslung ordentlich dokumentiert werden soll, hab ich mir mal den phpDocumentor angeschaut und auch gleich ein wenig gebastelt. Ich hab' mich dann aus Gründen der Übersichtlichkeit auch (fast) überreden lassen, meine zwei, drei Kommandozeilenprogrämmchen in Klassen unterzubringen. Quatsch eigentlich, aber für eine zusammenhängende Doku irgendwie praktischer. Der phpDocumentor ist recht hübsch, nimmt einem jedoch leider die eigentliche Dokumentationsarbeit nicht wirklich ab - hab ich auch nicht erwartet.
Außerdem bin ich momentan auf der Suche nach einem Framework, um nicht zum tausendsten Mal $_POST 'zu Fuß' auslesen zu müssen. Nein, nicht RoR, sollte schon PHP sein. Die Auswahl ist da auch recht groß: Symfony gefiel irgendwie nicht - wegen YAML (nicht das Layout-YAML, sondern das andere).
Da man ja bei PHP gleich an Zend denkt, hab ich auch hier nachgeschaut (vielversprechend: Der angedachte 'Support for XML Databases' - gäbe es den schon, wär die Entscheidung leichter). Seagull war mir noch im Gedächtnis, deswegen hab ich da auch geschaut. Hm... und da man ja irgendwie doch recht faul ist, klingt 'auto generated code' nicht wirklich schlecht und Qcodo scheint einem damit recht weit entgegen zu kommen.
Eine Entscheidung ist noch nicht gefallen, ich dokumentier inzwischen weiter...