Form-Generator Konzept [1]

[Christian Seiler]

Hallo Forum,

Juhuuu - ich bin über das Posting-Limit gekommen. ;-)

Nachdem ich heute nicht ganz unschuldig an der aufgeheizten Stimmung und an sinnlosen Diskussionen war, bringe ich mal was sinnvolles. (Hilfe, ich starte einen Thread, waahh, ich befürchte, ich werde bald die Marke 10 erreichen ;))

In </archiv/2002/10/27058/> (Blöd, dass der Archiv-Viewer nicht geht) hatte ich vor, eine Klasse zu schreiben, wie man Formulare bequem validieren kann. Ich bekam jedoch einige Antworten (speziell von Thomas (Schmieder) und Mathias) die gesagt haben, es sei sinnvoller, einen Formulargenerator zu erstellen, um somit sehr einfach Formulare erstellen zu können. Damals war ich von der Idee noch nicht so begeistert, inzwischen denke ich anders. :)

Ich hab' mir ewig lang Gedanken über ein mögliches Konzept für so etwas gemacht (und deswegen bin ich dann auch auf den Formulargenerator zurückgekommen) Ich will hier nun mal kurz mein jetztiges Konzept vorstellen (das meiste, was ich hier vorstelle, habe ich auch schon implementiert):

Zuerst einmal habe ich eine Datei RegexUtility.inc.php, die aus nichts anderem als zwei Funktionen besteht, um Zeichen, die für reguläre Ausdrücke eine besondere Bedeutung haben, zu maskieren. Diese habe ich _regex_replace_normal und _regex_replace_cclass genannt. Beide Versionen haben zwei Parameter: der erste für den zu ersetzenden String, der andere für den Delimiter des Ausdrucks. Der Defaultwert für den Delimiter ist /. Warum brauche ich diese Funktionen? Wenn ich zum Validieren von Formulareingaben möglichst Flexibel sein will, dann können sich bestimmte Zeichen (z.B. Dezimaltrennzeichen) je nach Einstellungen verändern. Da diese u.U. eine besondere Bedeutung in regulären Ausdrücken haben können, maskiere ich sie.

Ich habe eine weitere Datei BasicTranslation.inc.php, die dazu dient, Standardfehlermeldungen zurückzuliefern. Es gibt dort eine Funktion __form_validator_tr, die jedoch nur verwendet werden sollte, wenn man sich sonst keine Gedanken zur Mehrsprachigkeit gemacht hat. Die verwendete Übersetzungsfunktion kann beliebib ausgetauscht werden.

Desweiteren habe ich eine Datei FormFieldValidator.class.php. In dieser Datei habe ich eine Basisklasse FormFieldValidator, die zur Validierung dient. Der Konstruktor erwartet 4 Paramter: Das Locale [1], die Mindestlänge, die Maximallänge und die Übersetzungsfunktion. Die Klasse hat noch eine weitere Methode, validate, die einen Parameter (den Wert) besitzt und im Moment nur die Länge prüft. Die Funktion validate besitzt einen Parameter, den zu prüfenden Wert, und sie gibt entweder false oder den Wert zurück, der zu validieren war. [2] Von dieser Klasse leiten sich alle weiteren Validierungsklassen ab, da werde ich noch ein paar schreiben, im Moment habe ich nur für Integer-Zahlen und beliebige Zahlen. (in nicht-wissenschaftlicher Notation) Man kann sich also einen Validierer konstruieren:

$null_locale = null;
$validator = new FormFieldValidator ($null_locale, 3, 8);
$value = $validator->validate ($_POST["value"]);
if ($value === false) {
...
}

Das Spielchen mit dem null-Locale muss leider sein, da ich die Variable per Referenz erwarte. (Wenn das Locale erst mal richtig groß geworden ist (da viele Mitglieder), dann kann das bei vielen Formularfeldern ziemlich viel Zeit fressen, das ständig zu kopieren.)

Danach habe ich eine Klasse Form, die in der Datei Form.class.php definiert ist. Diese Klasse besitzt drei Parameter: Den Namen (der Inhalt des id-Feldes), den Titel (wird im Formular als Text angezeigt) und das Ausgabeobjekt. [3] Die Klasse besitzt noch weitere Methoden:
 - wasProcessed: gibt zurück, ob dieses Script zur Verarbeitung des Formulars aufgerufen wurde. (also das Formular an dieses Script 'abgeschickt' worden ist) Rückgabewert: true/false.
 - hiddenField: setzt oder verändert ein hidden-Field, erwartet 2 Parameter, den Namen und den Wert. Rückgabewert: keiner.
 - removeHiddenField: löscht ein hidden-Field, erwarten 1 Paramter: den Namen. Rückgabewert: keiner.
 - setAction: setzt die Aktion des Formulars auf etwas anderes als $_SERVER['PHP_SELF'], erwartet einen Parameter, die neue Aktion. Rückgabewert: keiner.
 - addError: fügt dem Fehler-Array des Formulars eine weitere Fehlermeldung hinzu, erwartet einen Paramter, die Fehlermeldung. Rückgabewert: keiner.
 - validate: Lässt alle Formularfelder validieren, erwartet keinen Paramter. Gibt 0 zurück, wenn alles OK ist, -1 zurück, wenn mindestens ein Fehler aufgetreten ist und -2 zurück, wenn mindestens eine Warnung, aber kein Fehler aufgetreten ist.
 - fetch: Gibt das Formular als HTML-Code zurück, entweder über eine Standardmethode oder über das Ausgabeobjekt. (Im Falle des Ausgabeobjekts wird nur die entsprechende Funktion aufgerufen) Erwartet keine Parameter.
 - display: da steht im Moment echo $this->fetch(); drinnen, eine Erklärung dürfte sich erübrigen.

[-->]

-------------------------------------

[1] Ein Objekt einer Klasse Locale, über das ich mir noch keine großen Gedanken gemacht habe. Im Moment müssen laut meiner Implementation 2 Eigenschaften vorhanden sein: thousands_sep und decimal_point. Später wird das sicherlich noch mehr werden. Ich möchte nicht die OS-Unterstützung für Locales verwenden, weil man da sehr auf das System angewiesen ist und das ganze nicht sehr portabel ist.

[2] Ich mache das absichtlich so, damit die Methode den Wert auch gleich umwandeln kann, z.B. eine Deutsche Zahl "3,5" in eine für PHP verständliche Zahl "3.5", oder ein Datum in einen Timestamp, somit sind die Möglichkeiten sehr groß.

[3] Das Ausgabeobjekt muss ein Objekt einer Klasse sein, das eine Methode process besitzt, die als einzigen Parameter ein Objekt der Klasse Form erwartet. Man kann auch null übergeben, dann wird eine Standardfunktion verwendet, die jedoch nicht immer sinnvoll ist.