Formulargenerator - Thema zu spezifisch?

[Christian Seiler]

Hallo Mathias,

Zuerst einmal ist die Klassenaufteilung nachvollziehbar und die Anwendung leuchtet mir sofort ein,

Dann habe ich mein Hauptziel erreicht: ein gutes Konzept. :)

der Punkt, auf welchen ich hinausmöchte, ist, dass ich, wie ich bereits einführte, stark dazu neige, die Formulardaten insgesamt in einer externen Datenstruktur unterzubringen als dass ich sie im PHP-Code von Hand als (Unter-)Objekte deklariere, welche aufeinander Bezug nehmen und einen Baum bilden (Form -> FormFieldSet -> FormField -> FormFieldValidator IIRC), wodurch im PHP-Code dutzende (bei einem umfangreichen Formular schätzungsweise 20-25) Variablen (Objekte) von Hand deklariert werden müssen.
deine momentane Lösung ist *zu* flexibel,

Ich wollte die Lösung halt möglichst flexibel gestalten und halt auch Formulare abdecken, die hardgecodet werden, wie z.B. Loginformulare.

sie wird bei komplexen Formularen nicht viel Zeit- und Codeersparnis bieten, denn die komplette Fehlerbehandlung muss mehr oder weniger in PHP per Hand realisiert werden.

Warum denn? Die Fehlermeldungen werden vom Validator-Objekt automatisch generiert. Du brauchst nichts weiter tun als $form_objekt->validate () aufzurufen und die Validierung geht von statten und die Fehlermeldungen werden automatisch zu den entsprechenden Formularfeldern eingefügt.

In dem Script, welches die Klassen anwendet, hat diese Grundkonstruktion meiner Meinung nach nichts zu suchen, ich würde sie in in einer Methode unterbringen,

Ich kann gerne noch eine Funktion schreiben, die ein Array einliest und dann ein paar Standardklassen verwendet, um das Formular zu konstruieren. Diese Funktion gibt dann das Formular zurück.

»Von dieser Klasse leiten sich alle weiteren Validierungsklassen ab, da werde ich noch ein paar schreiben« - ähm, es ist jetzt schon unübersichtlich, sich die Syntax des Konstruktors der vorhandenen Klasse zu merken.

Hmmm. Ich habe eigentlich vier Parameter für die Validatorklasse vorgesehen: das Locale, der Minimumwert/Minimumlänge (je nachdem), der Maximumwert/Maximumlänge und die Übersetzungsfunktion. Einzig die Klasse für generische Zahlen hat noch mehr, aber die könnte ich auch aus dem Konstruktor rausnehmen und direkt die Variablen des Objektes verwenden.

Wie willst du die Daten organisieren, wenn du multiple Auswahlboxen, Checkboxen handhaben musst und die Eingabe mittels verschiedener RegExps von verschiedenen Datentypen (was du ursprünglich vorhattest) validiert werden muss...?

Ich bisher nur Standardtexteingabefelder und Passworteingabefelder über FormField und FormFieldValidator realisiert. Checkboxen werde ich so realisieren, dass das Formularfeld beim "validieren" einfach nur prüft, ob die POST-Variable gesetzt worden ist und den Wert dann entsprechend auf true oder false setzt. (brauchen keine Validatorklasse, das könnte die Checkbox-Formularfeldklasse selbst übernehmen) Radiobuttons und Auswahllisten werden (in Zukunft) so validiert, dass eine Liste mit möglichen Eingaben übergeben wird, und geprüft wird, ob die Eingabe darunter ist. Datumsauswahllisten/Zeitauswahllisten werde ich ähnlich behandeln, warscheinlich in Kombination mit einem Integer-Validator.

Das würde womöglich ein heilloses Durcheinander an Objekten,

Wieso? Man muss sich nur selbst zwingen, die Objekte möglichst abstrakt zu halten, dass man nicht unnötig viele braucht.

welche im Bezug auf das ineffiziente, einzelne Überprüfen der GET- oder POST-Parameter zwar einen höheren Abstraktionsgrad erlauben, aber keine Codeersparnis bieten.

Warum keine Codeersparnis? Ich denke, dass mein jetztiges Konzept mir doch schon etwas Code erspart, beim Login-Formular vielleicht nicht, aber so ab 4 oder 5 Feldern kann das durchaus eine Ersparnis sein.

Ich habe auch eine Möglichkeit vermisst, sich den Code anzuschauen.

Ich schicke ihn Dir gerne zu, Mail kommt gleich.

Wieso der Code nicht unter der GPL oder LGPL veröffentlicht werden kann, ist mir unverständlich.
[Lizenzen & Co]

Full ACK im Prinzip, aber CZ hat mich im anderen Thread davor gewarnt, und daher beruhen meine Überlegungen, ich bin leiber einmal zu vorsichtig, als dass meinem armen Code was passiert...

Grüße,

Christian