Zergling-new

Hallo,

ich möchte für einen Formular-Generator (endlich komme ich wieder dazu) die Liste von Operatoren, die einem Element zugeordnet werden können, sortierbar machen.

Operatoren (Form_Operator) können Filter (Form_Operator_Filter, z.B. filterTrim), Validator (Form_Operator_Validator, z.B. isNumeric, isNotEmpty, ..) oder Conditionals (Form_Operator_Conditional, z.B. isOptional, checkDate) sein. Filter können den Wert eines Elementes bearbeiten, Validator können den Zustand (value) testen und Conditionals (Konsistenzprüfer nenn ich sie mal) prüfen den Zustand gegen andere Elemente im Formular. isOptional als Conditional prüft beispielsweise sich selbst auf Validität und reagiert je nach dem mit filterEmpty (oder was auch immer als Standard eingestellt sein wird). Hauptsächlich sollen Conditionals jedoch Elemente untereinander gegentesten, beispielsweise muss bei der Auswahl von "Deutschland" auch eine fünfstellige Postleitzahl eingegeben werden, sind es nur 4, ist lediglich die Auswahl von Schweiz und Österreich "konsistent".

Laaange Rede kurzer Sinn. isOptional() macht nur Sinn, wenn es als wirklich letzter der Validator und Filter ausgeführt wird, Conditionals wiederum als allerletztes!

Gibt es denn so etwas wie ein Sortable Interface für Objekte? Ich denke da an die ArrayObject-Interfaces Countable usw. mit denen ja gewisse Operationen auch möglich sind.

Ich stocher grad hier:
http://www.php.net/~helly/php/ext/sp...rayObject.html
und hier:
http://de2.php.net/manual/en/functio...ject-count.php
herum aber so richtig was finden tu ich nicht?

Dass es usort() gibt weiß ich. Notfalls wirds damit gemacht.

Mister Ad

Zergling-new

Andererseits ist die Reihenfolge fest: Filter, Validator, Conditionals?

nikosch

Feste Reihenfolge würde ich verneinen:

Kleines Beispiel:
conditionIsset () > filterTrim ()
vs.
filterTrim () > conditionIsset ()

oder

conditionIsInt () > filterToInt ()
vs.
filterToInt () > conditionIsInt ()


Vielleicht noch nicht das beste Bsp. Sicher ließen sich die Filter auch entsprechend kompliziert gestalten. Aber der Weg mit freier Sortierung ist sicher der bessere.
Die Ausgangsfrage habe ich noch nicht ganz verstanden. Wie werden die genannten Elemente denn zugeordnet. Über einen FormHandler? Oder jedem FormItem seine eigenen (wohl eher ungünstig bei Verknüpfungen untereinander, wg. zirkulären Angaben)
Käme Iterator in Frage?

Zergling-new

Hmm ich weiß nicht, ich sehe noch kein Beispiel, wann ein Filter nach einem Bedingungstest ausgeführt werden sollte (und wenn übernimmt das ein Conditional, z.B. um den 29. Februar anhand des Monatschecks in einen 1. März zu verwandeln).
MD5-Hash auf ein valides Passwort wird im Zend-Framework als Beispiel für die Flexibilität aufgeführt, das ist aber sehr an den Haaren herbeigezogen. Scheinbar haben die auch keine bessere Idee, was man damit eigentlich machen soll. Wie unterscheide ich denn dann zwischen Backend-Filtern die der User nicht sehen soll und Frontend-Filtern. Schließlich kann es ja nicht gewollt sein, dem User - wenn die restlichen Eingaben nicht valide waren - einen MD5 String anstatt seines Passwortes zu präsentieren. Klar könnte man jetzt nochmal einen Flag reindonnern, der das unterscheidet. Ich weiß nicht, das überzeugt mich noch nicht so ganz ..

nikosch

Vielleicht reden wir auch aneinander vorbei. Die > oben sollten keine Bedingung, sondern die Reihenfolge der Abarbeitung signalisieren. Bestimmte Validierungen (isset z.B.) machen nur als erste Aktion Sinn. Ebenso wie is_numeric () vor (int) $value erfolgen sollte

dr.e.

Hallo Ihr beiden,

zieht man die Betrachtung von der Seite der Sicherheit (Typensicherheit, bzw. Applikationssicherheit) auf, so ist meiner Meinung nach der Filter zuerst zu applizieren. In meiner Filter-Implementierung verwende ich noch einen generischeren Ansatz: ich filtere _alle_ REQUEST-Daten. Anschließend sollten Validatoren folgen. Zu diesen zähle ich aber auch sowas wie "isOptional", denn es sollte immer möglich sein mehrere Validatoren auf ein Feld zu definieren. Man kann dann "isOptional" und "validateDate" definieren um ein optionales Feld nur dann zu validieren, wenn eine Eingabe erfolgt ist. Das Thema "Conditionals" kann man für das Thema Datum auch in Validatoren packen ("isValidDate"), Ausgaben eines Feldes kann man mit Providern regeln (hatten wir kürzlich). Man gibt einem Feld dabei einen OutputProvider, der einem das entsprechende zurückliefert. Beim Passwort-Feld ist das oft ein "MD5OutputProvider". Letzteres halte ich aber für ein denkbar schlechtes Beispiel, denn das sollte die Businessschicht regeln. Diese muss nämlich oft eine Bestätigungsmail für eine Anmeldung verschicken, oder diverse andere Themen abhandeln. Nach dererlei Unfug, kann man der Datenschicht, dann ein verändertes Benutzer-Objekt übergeben, bei dem das Passwort ein MD5-Hash ist und es persistieren.

Viel interessanter ist das Thema Formulargenerierung an sich. Hier muss man vor allem das Problem der Gestaltung in HTML sauber lösen. Es ist nicht nur wichtig, die Felder in der Reihenfolge sortierbar zu machen, sondern auch die Anordnung per se muss x-Browser-kompatibel, ... sein.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~