nicht angemeldet
Klasse für Form-Validierung client- und serverseitig
0 
Gunnar Bittersmann
Klasse für Form-Validierung client- und serverseitig
Hallo!
Auf der Suche nach einer Klasse/einem Skript für die Formular-Validierung komme ich nicht so recht weiter.
Die Validierung soll sowohl serverseitig als auch clientseitig (per JavaScript) erfolgen, und nach Möglichkeit sollte man die Validierungsregeln für beides zusammen nur einmal formulieren müssen. Und irgendwie muss ich es zur Zusammenarbeit mit Smarty 3 bewegen können.
Alles was ich bisher gefunden habe scheint veraltet zu sein oder ist zu umfangreich (ich brauche keine Admin-Oberfläche in der ich mein Formular zusammenbauen kann).
Hat da jemand einen guten Tip?
Viele Grüße!
Beo
-
@@Beo:
nuqneH
Die Validierung soll sowohl serverseitig als auch clientseitig (per JavaScript) erfolgen,
Schau dir mal den A-List-Apart-Artikel Forward Thinking Form Validation an, was moderne Browser auch ohne JavaScript schön können.
und nach Möglichkeit sollte man die Validierungsregeln für beides zusammen nur einmal formulieren müssen.
Das wird wohl schwer möglich sein.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
Ich selber verwende für Formular Validierungen "Jquery Validation" (Javascript) Plugin, und Serverseitig programmiere ich er selber mit, doppelt hält besser :-)
-
Hi,
und nach Möglichkeit sollte man die Validierungsregeln für beides zusammen nur einmal formulieren müssen.
Das wird wohl schwer möglich sein.
Kommt auf den Umfang bzw. die Komplexität an, mit der man "validieren" möchte.
Sowas wie optional vs. obligatorisch, minimale/maximale Längen von Texteingaben, kann man sicher so abbilden, dass es a) für PHP nutzbar ist und b) PHP daraus auch gleich die entsprechendene Datenstruktur für eine Nutzung innerhalb einer JS-Validierungsklasse machen kann.Nicht zu komplizierte Reguläre Ausdrücke, die PHPs PCRE-Funktionen ebenso verstehen wie JavaScripts RegExp-Objekt, könnte man bei bedarf ebenfalls hinzu nehmen.
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right? -
Hi Gunnar.
Schau dir mal den A-List-Apart-Artikel Forward Thinking Form Validation an, was moderne Browser auch ohne JavaScript schön können.
Ich hab mir das gerade mal angesehen, das klingt ganz interessant. Was macht man denn nun damit im Umfeld von HTML4-Dokumenten? Meiden? Nutzen und auf Validität verzichten? Hat das Nebenwirkungen?
Danke, viele Grüße
der Bademeister-
Tach auch.
Ich hab mir das gerade mal angesehen, das klingt ganz interessant. Was macht man denn nun damit im Umfeld von HTML4-Dokumenten? Meiden? Nutzen und auf Validität verzichten? Hat das Nebenwirkungen?
Hab mir das nun nicht genauer angeschaut auf Code-Seite. Aber mein ganz naiver Ansatz wäre, statt über das type- und die HTML5-eigenen Attribute mit Klassen zu arbeiten, welche die Informationen beinhalten.
Ein
<input type='date' required />
würde dann sowas werden wie
<input type='text' class='type-date field-required' />und dass kann man dann wieder bei onblur/onchange/... auseinandernehmen und validieren.
Ansonsten einfach den Doctype auf HTML5 ändern, gibt ja keine wesentlichen Nachteile dadurch (wenn du sowieso an das Dokument ran musst...).
Bis die Tage,
Matti-
@@Matti Maekitalo:
nuqneH
<input type='date' required />
Hm, seltsame Gemischtschreibweise. Das Element XML-like mit '/' geschlossen, aber boolsches Attribut ohne Wert?
<input type='text' class='type-date field-required' />
und dass kann man dann wieder bei onblur/onchange/... auseinandernehmen und validieren.Eben. Man müsste den Aufwand betreiben und JavaScript programmieren für etwas, was Browser schon nativ können. (Heute schon einige, zukünftig so ziemlich alle.)
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
Tach auch.
<input type='date' required />
Hm, seltsame Gemischtschreibweise. Das Element XML-like mit '/' geschlossen, aber boolsches Attribut ohne Wert?Normalerweise versuche ich gültiges XML zu schreiben, aber hier habe ich mich einfach an der Schreibweise des von dir zitierten Artikels gehalten.
<input type='text' class='type-date field-required' />
und dass kann man dann wieder bei onblur/onchange/... auseinandernehmen und validieren.Eben. Man müsste den Aufwand betreiben und JavaScript programmieren für etwas, was Browser schon nativ können. (Heute schon einige, zukünftig so ziemlich alle.)
Ich ergänze mal: "was HTML5-Browser schon nativ können".
Der Artikel von A List Apart benutzt ebenfalls Javascript, um Browser dazuzubringen, mit der HTML5-Form-Validierungs-Syntax zurechtzukommen, auch wenn diese ihnen unbekannt ist.Ich habe geschrieben, wie es möglich wäre, ähnliches in einem HTML4 Umfeld umzusetzen. Da es ja, wie ich auch schrieb, keine wesentlichen Nachteile von HTML5 ggü. HTML4 gibt, plädiere ich ebenfalls dafür, die neuen Attribute zu nutzen anstatt einen Haufen neue Klassen einzufügen (vor allem, weil die Attribut-Schreibweise besser zu lesen und "zukunftsfähig" ist.)
Bis die Tage,
Matti
-
-
-
@@Bademeister:
nuqneH
Was macht man denn nun damit im Umfeld von HTML4-Dokumenten? Meiden? Nutzen und auf Validität verzichten?
Validität sollte nicht zum Selbstzweck verkommen. Wenn es Nutzen bringt, darauf zu verzichten … Die Abwägung zwischen einem wirklichen Nutzen und einem zweifelhaften Schulerklopfen sollte nicht schwerfallen.
Hat das Nebenwirkungen?
Ja. Man muss die Meldungen des Validators genauer lesen, um gewollte von ungewollten Fehlern unterscheiden zu können.
Oder das Markup als das kennzeichnen, was es ist: HTML5. Dann gibt auch der Validator grünes Licht. Dummerweise auch dann, wenn man lieber eine Fehlermeldung hätte (bspw. bei einem nicht geschlossenen Element), weil er HTML5 als Tagsoup prüft.
Sinnvollerweise wird man XML-konformes HTML5 schreiben* und seinem Server beibringen, das an alle Clients als 'text/html' rauszuschicken, außer an Validatoren: an diese als 'application/xhtml+xml', damit sie nach strengeren Regeln prüfen.
Qapla'
* Polyglott heißt das wohl im HTML5-Jargon. Die Macher konnten es nicht lassen, alles umzubenennen.
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
Hat das Nebenwirkungen?
Ja. Man muss die Meldungen des Validators genauer lesen, um gewollte von ungewollten Fehlern unterscheiden zu können.
:-) Ich meinte weniger das Verzichten auf Validität im allgmeinen, sondern das Nutzen dieser Formularfunktionalität in Dokumenten, für die es nicht vorgesehen ist.
Oder das Markup als das kennzeichnen, was es ist: HTML5. Dann gibt auch der Validator grünes Licht. Dummerweise auch dann, wenn man lieber eine Fehlermeldung hätte (bspw. bei einem nicht geschlossenen Element), weil er HTML5 als Tagsoup prüft.
Sinnvollerweise wird man XML-konformes HTML5 schreiben* und seinem Server beibringen, das an alle Clients als 'text/html' rauszuschicken, außer an Validatoren: an diese als 'application/xhtml+xml', damit sie nach strengeren Regeln prüfen.
Alles klar, das kling vernünftig. Vielen Dank Dir und Matti.
Viele Grüße,
der Bademeister
-
-
-