robo47

Schau dir vielleicht mal im Zend Framework die Umsetzung mit Zend_Form + Zend_Validate an, alle Validatoren haben standard-messages, in Kombination mit Zend_Translate hat man da mit ein paar Zeilen auch Übersetzungen ohne händisch am Code was zu ändern (nur über ne Sprachdatei) und das lieses sich theorhetisch ähnlich auch umsetzen um eine zentrale Klasse zu basteln die für die Texte zuständig ist.

Ansonsten kannst du natürlich auch die Formen in extra Datei erstellen, beim Zend Framework sieht das so aus dass man nen init-methode hat die man überschreiben kann:

dann macht man im code nur noch ein $form = new FooForm(); und hat die Klasse mit allen Validatoren und soweiter.

hier könnte man auch die form-klasse erweitern und dann eine methode nachs init klemmen die z.b. für alle validatoren automatisch aus einer Datei die passenden Meldungen liest wenn sie projekt-spezifisch sind.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

Mister Ad

MaMo-Net

Hi,

danke für deinen Post. Ich hatte mir Zend_Validate schon angesehen und habe mir nun nochmal genauer Zend_Translate/Locale angesehen, das ist ja im Grunde nichts anderes als ein eindeutiger Key, der dann quasi ersetzt wird durch die entsprechende Sprachstring. So habe ich das im Moment auch schon in der Vorgängerversion implementiert, ich dachte jetzt aber, man könnte das evtl. flexibler gestalten, so dass man verschiedene Sprachstrings nutzen kann, z.B. ne lange ausführliche Erklärung für eine Ausgabe über dem Formular und wenn man z.B. AJAX nutzt nur eine kurzer Hinweis. Nunja, das ist kein Muss, die Key-Ersetzungs-Methode ist ausreichend, aber wäre sicherlich "nice to have".

Die zusätzlichen Klassen pro Validierungszusammenstellung finde ich etwas overkill, das geht ja in die entgegengesetzte Richtung wie ich es eigentlich haben möchte.

Mal gucken ob uns noch was besseres einfällt...

Gruß
MaMo

dr.e.

Hallo MaMo-Net,

vielleicht interessiert dich auch der neue Ansatz des APF zum Thema Formular-Validierung. Hier wurde für das neue Release eine Trennung von Validator und zu validierendem Objekt (ebeso für das Thema Filter) nach dem Observer-Pattern eingeführt. Für die Ausgabe der Validierungs-Texte gilt hier das Listener-Prinzip, sprich die Ausgabe-Repräsentation registriert sich als Listener beim Formular-Element, das wiederum von einem externen Validator (Observer) validiert wird. So lassen sich i18n Sprachtexte sehr gut wiederverwenden.

Du arbeitest im Vergleich zum Zend-Framework nicht mit einer expliziten PHP-Klasse, sondern definierst über den HTML/XML-Code dein Formular mit allen seinen Komponenten (Formular-Felder, Messages, Validatoren, Filter, ...) und erreichst über diese lose Kopplung eine sehr gute Wiederverwendbarkeit der Einzel-Komponenten.

Die Zuordnung der Sprach-Werte findet jedoch auch beim APF über Keys statt, die in einer Sprach-Sektion (z.B. "[de]") stehen. Beispiele für diese Art der Formular-Definition findest du im Kapitel Aufbau von Validatoren und Ausgabe von Validator-Fehlermeldungen.

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

MaMo-Net

Hallo dr.e,

danke auch für deinen Beitrag, habe mir deine Seiten kurz angesehen, bin jedoch noch nicht 100%ig durchgestiegen, v.a. wie du das meinst mit dem Observer in Kombination mit den Sprachtexten. Hatte jetzt aber auch noch nicht wieder Zeit en masse, muss mich mit dem Thema Formular-Validierung in ein paar Tagen nochmal auseinandersetzen, derzeit liegen irgendwie laufend andere Dinge an. Außerdem warte ich auf ein neues Buch, das gibt ggf. noch ein wenig Input.

Ich melde mich dann (sicher) nochmal.

Gruß MaMo

Phoscur

Unabhängig von der momentanen Unterhaltung, aber zum Thema:
Ich bin mir nicht sicher wie ich das mit der Validierung machen soll. Ich möchte einen DomainLayer auf PHP- und JavaScript-Seite bauen und würde Validierung direkt im DomainObjekt-Setter ansiedeln. Mir ist dann allerdings auch unklar, wie ich das mit einem Formular verbinde. Für JavaScript könnte man direkt das onChange Event verwenden. Die Kommunikation der JS und PHP DomainObjekte ist eine andere Geschichte, doch die Umsetzung der Validierung interessiert auch mich. Bisher hatte ich nur an eine Bibliotheksklasse Validator gedacht mit verschiedenen Methoden wie isName(), isEmail(), isURL(), isFloat(), isNum(), etc.. So würde ich das denn auf beiden Seiten umsetzen.
Insgesamt habe ich wahrscheinlich gar nicht soviele Formulare (Login + Optionen?).
Welche Probleme können denn bei meinem Aufbau auftreten? Ich bin mir nicht sicher, ob es sich überhaupt lohnt Formulare generisch umzusetzen, mir wird ein Template reichen.
Was spricht dagegen Validierung ins DomainObject zu legen?

__________________

robo47

Nur um das mal kurz zu erwähnen, weil ich letztens mir auch gedanken über die ganze Validierung/Filterung in Javascript gemacht habe.

Ich bin für mich zu dem Schluss gekommen den overhead das ganze komplett via ajax zu lösen hinzunehmen, weil es für mich schon etwas gegen DRY verstößt in 2 Sprachen das gleiche zu erfinden inklusive tests etc.
Wenn man die gleiche Validierung mit PHP und JS braucht hat, hat man in der Praxis immer die doppelte Menge Code für diesen Bereich. Wenn man neben Validatoren noch Filter nutzt, hat man auch nochmal die ganzen Filter die man auch noch in JS basteln muss.

Wenn man also irgendwann einen neuen Validator oder Filter braucht muss man das ganze dann in JS und PHP entwickeln und testen und vor allem schauen dass es auch in allen Fällen 1:1 immer die gleichen Ergebnisse bringt und man muss irgendwie dann noch die Fehlermeldungen zwischen PHP und Javascript sharen, da kann beispielsweise schon unterschiedliches Verhalten der Regex-Engines von PHP und Javascript Unterschiede bringen und der fakt dass Javascript manche dinge in regex nicht unterstützt die PHP mittels preg_* kann, utf-8, etc.

Also für mich war das ganze im Endeffekt zu viel Overhead auch im Hinblick auf den Aufwand das ganze zu testen und so.

Da ich das Zend Framework nutze, habe ich mir deshalb das hier angeschaut:
Live Validierung mit dem Zend Framework und jQuery | Kristof Dreier
und baue das dann noch etwas aus (Klassen-basierte aktivierung, spinner um auch eventuelle längere validierungsprozesse zu verdeutlichen, einzelfeld-validierung... etc) so kann ich jederzeit einfach einen Filter oder Validator in PHP schreiben und hinzufügen, kein zusätzlicher Code für das JS, Nachteil ist halt der Overhead dass jegliche Validierung immer auch einen http-request bedeutet, womit ich aktuell leben kann, ausserdem erlaubt es mir auch ohne aufwand einfach fremde Validatoren die jemand für ZF-Applikationen geschrieben hat zu nutzen ohne passenden JS-Code zu nutzen.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

MaMo-Net

Hi,

um die Argumentation von robo47 etwas fortzuführen, es gibt auch diverse Validatoren in meinem Konzept die hinterher auch gegen z.B. eine Datenbank prüfen (z.B. Nutzername schon vorhanden, MX-Prüfung bei E-Mail-Adressen, Passwort-Sicherheit mit Wörterbuch-Check etc.). JS kann ja quasi nur eine textuelle Prüfung durchführen ohne irgendwas dahinter liegendes, daher werde ich diesen Weg auch beschreiten.

@Phoscur Was meinst du mit DomainObject?

Gruß
MaMo

Phoscur

Für das Thema müsste man hier topicsprengend ausholen. Ich empfehle dir einfach ein wenig Literatur dazu zu lesen. Die Profis hier wissen aber wovon ich rede.

@robo:
Bei einer viel JavaScript komme ich um einen Haufen Duplikation nicht drumherum, versuche das aber natürlich zu minimieren.

__________________

Koala

man muß in JS nicht noch mal alles prüfen, und nicht alles doppelt (in PHP und JS) programmieren.

Es reicht doch eine grobe Prüfung ob int, Datum, leer etc.

Die genaue Prüfung erfolgt durch PHP.

nikosch

Naja, das ist die Frage. Wenn eine optische OK-Meldung erfolgt und nach dem Submit der selbe Wert als fehlerhaft abgegeben wird, ist das nicht sehr nutzerfreundlich.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--