jQuery Abfrage (return false)

[wiiplayer]

Ich habe ein Formular mit input Felder. Alle Felder sollen geprüft werden.

1. ob alle Felder ausgefüllt sind
2. das nur Zahlen eingetragen sind

Der Fehler soll mit alert ausgegeben werden und das Formular soll nicht verschickt werden.

  
$('#myForm').submit(function(){  
		$('#myForm input[type=text]').each(function(n,element){  
			if ($(element).val()=='') {  
				alert('Field '+element.id+' must have a value');  
				return false;  
				}  
			if (isNaN($(element).val())) {  
				alert('Eingabe ist keine gültige Zahl!');  
				return false;  
				}	  
				  
			});  
		return true;  
	});  

Der Fehler wird richtig ausgegeben. Aber das Senden bei einem Fehler wird leider nicht verhindert.
Was muss ich genau ändern, damit das Formular nur gesendet wird, wenn es keinen Fehler gibt?

[molily]

Hallo,

$('#myForm').submit(function(){

äußere Funktion 1, wird einmal beim Absenden des Formulars aufgerufen

  $('#myForm input[type=text]').each(function(n,element){  

innere Funktion 2, wird für jedes Feld aufgerufen (Iteratorfunktion)

  	if ($(element).val()=='') {  
  		alert('Field '+element.id+' must have a value');  
  		return false;  

Mit diesem return beendest du die innere Funktion 2.
Das ist in Ordnung, damit stoppt die each-Schleife und weitere Elemente werden nicht geprüft.
Du willst aber zusätzlich, dass die äußere Funktion 1, false zurückgibt. Das tut sie nicht automatisch, wenn du aus Funktion 2 zurückspringst. return bedeutet ja nur: Beende die aktuelle Funktion und springe zurück zur Codestelle, wo die Funktion aufgerufen wurde.

Das kannst du z.B. erreichen, indem du eine Variable in Funktion 1 notierst und diese in Funktion 2 änderst, wenn ein Fehler gefunden wurde.

var korrekt = true;

Dann in Funktion 2 korrekt = false setzen, wenn ein Fehler gefunden wurde.

Am Ende von Funktion 1 dann return korrekt;. Dann wird false zurückgegeben, wenn ein Fehler gefunden wurde.

Mathias

[suit]

Ich habe ein Formular mit input Felder. Alle Felder sollen geprüft werden.

1. ob alle Felder ausgefüllt sind
2. das nur Zahlen eingetragen sind

Der Fehler soll mit alert ausgegeben werden und das Formular soll nicht verschickt werden.

A geh - warum denn alert() - das ist doch billig und hässlich.

Warum den nicht ein schönes Element im DOM welches du per append() anhängst? Oder ein modaler Dialog mit jQuery UI? Wenn du schon ein Framework nutzt, mach was draus.

Was muss ich genau ändern, damit das Formular nur gesendet wird, wenn es keinen Fehler gibt?

false ist false :) was du willst, ist das default-Event unterdrücken:
event.preventDefault()

[Gunnar Bittersmann]

@@wiiplayer:

nuqneH

Ich habe ein Formular mit input Felder. Alle Felder sollen geprüft werden.

JavaScript ist dafür nicht erforderlich, moderne Browser können das ohne.

1. ob alle Felder ausgefüllt sind

Gib den Pflichtfeldern das @required-Attribut.

2. das nur Zahlen eingetragen sind

Setze @type="number" oder gib ein @pattern an.

Serverseitig (PHP, …) musst du sowieso prüfen, ob gültige Eingaben reinkommen. Daher ist es fraglich, ob der Aufwand noch lohnt, zusätzlich noch für alte Browser eine clientseitige Überprüfung mit JavaScript zu implementieren.

Qapla'

[Nunja]

Ich habe ein Formular mit input Felder. Alle Felder sollen geprüft werden.
JavaScript ist dafür nicht erforderlich, moderne Browser können das ohne.

Es soll Fälle geben, in denen man neben modernen auch relevanten Browsern (z.B. IE8) das gewünschte UI-Erlebnis bieten möchte.

[suit]

Ich habe ein Formular mit input Felder. Alle Felder sollen geprüft werden.
JavaScript ist dafür nicht erforderlich, moderne Browser können das ohne.

Es soll Fälle geben, in denen man neben modernen auch relevanten Browsern (z.B. IE8) das gewünschte UI-Erlebnis bieten möchte.

"alert" ist ein modernes UI-Erlebnis? Mach dich nicht lächerlich.

Eine kleine Request-Response-Kette mit einer ordentlichen serverseitige Überprüfung ist - damit das ganze ohne viel Arbeit zuverlässig funktioniert ohnehin notwendig. Eine rein clientseitige Prüfung per JavaScript birgt zu viel Gefahr, dass die Prüfroutinen auseinanderlaufen - da muss sowieso ein XHR ran.

[molily]

Eine kleine Request-Response-Kette mit einer ordentlichen serverseitige Überprüfung ist - damit das ganze ohne viel Arbeit zuverlässig funktioniert ohnehin notwendig. Eine rein clientseitige Prüfung per JavaScript birgt zu viel Gefahr, dass die Prüfroutinen auseinanderlaufen - da muss sowieso ein XHR ran.

Wie bitte? Was für absurde Prüfroutinen hat ein Durchschnittsformular denn, die nicht mit HTML5 deklarativ abgedeckt werden können? Für 95% der Webformulare braucht man keine komplexe Prüflogik, bei der die Implementierungen auf Client- und Serverseite groß auseinanderlaufen könnten. Erstens gibt es mit RegExps und Grammatiken beidseitig verwendbare Sprachen, zweitens ist JavaScript ebenfalls beidseitig verwendbar. Wenn diese Synchronisierung ein Problem ist, dann hat man es zu einem gemacht.

Mathias

[suit]

Eine kleine Request-Response-Kette mit einer ordentlichen serverseitige Überprüfung ist - damit das ganze ohne viel Arbeit zuverlässig funktioniert ohnehin notwendig. Eine rein clientseitige Prüfung per JavaScript birgt zu viel Gefahr, dass die Prüfroutinen auseinanderlaufen - da muss sowieso ein XHR ran.

Wie bitte? Was für absurde Prüfroutinen hat ein Durchschnittsformular denn, die nicht mit HTML5 deklarativ abgedeckt werden können?

Das habe ich nicht gesagt :)

Für 95% der Webformulare braucht man keine komplexe Prüflogik, bei der die Implementierungen auf Client- und Serverseite groß auseinanderlaufen könnten.

Ja

Erstens gibt es mit RegExps und Grammatiken beidseitig verwendbare Sprachen, zweitens ist JavaScript ebenfalls beidseitig verwendbar. Wenn diese Synchronisierung ein Problem ist, dann hat man es zu einem gemacht.

Wenn es z.B. um die Prüfung von Gutschein-Codes in Webshops geht, kannst du clientseitig die Syntax prüfen, das wars aber auch schon - ob der Code schon eingelöst wurde, ob er noch gültig ist, ob das angebot noch verfügbar ist solche Sachen musst du notwendigerweise serverseitig prüfen.

Und als komfortfunktion per Ajax live nach der Eingabe. Wenn jemand ein langes Bestellformular mit Rechnugsadresse, Lieferanschrift, Gutscheincode usw ausfüllt, abschickt und dann eine Antwort mit 18 Fehlern bekommt, bricht er eher ab wie wenn er zwischendrin bei der Eingabe schon immer wieder Feedback bekommt.

[Gunnar Bittersmann]

@@Nunja:

nuqneH

Es soll Fälle geben, in denen man neben modernen auch relevanten Browsern (z.B. IE8) das gewünschte UI-Erlebnis bieten möchte.

Von einem Schwarz-weiß-Fernseher kann man nicht erwarten, Farben anzuzeigen.

Dann warten die paar Nutzer alter Browser vielleicht eine Sekunde auf die Antwort vom Server (Affenformular).

Qapla'

[molily]

Hallo,

JavaScript ist dafür nicht erforderlich, moderne Browser können das ohne.

Das ist lustig Aussage angesichts dessen, dass man im Safari 5, ein Browser, der Techniken wie required unterstützt, das Prüfen des Formulars, das Anzeigen von Meldungen und das Blocken des Absendens manuell mit JavaScript lösen muss. Meines Wissens ist dieses Verhalten auch HTML5-konform. Im Firefox und Chrome hingegen wird das submit-Ereignis nicht gefeuert, wenn das Formular Fehler aufweist und browsereigene Fehlermeldungen angezeigt werden. Damit eine konsistente UX umzusetzen, die dem Nutzer hilfreiche Hinweise gibt, ist nicht ohne JavaScript-Quirks möglich. Da würde ich lieber auf HTML5-Formularvalidierung verzichten und client- wie serverseitig eine eigene zuverlässige umsetzen.

Mathias

[suit]

Das ist lustig Aussage angesichts dessen, dass man im Safari 5, ein Browser, der Techniken wie required unterstützt, das Prüfen des Formulars, das Anzeigen von Meldungen und das Blocken des Absendens manuell mit JavaScript lösen muss. Meines Wissens ist dieses Verhalten auch HTML5-konform. Im Firefox und Chrome hingegen wird das submit-Ereignis nicht gefeuert, wenn das Formular Fehler aufweist und browsereigene Fehlermeldungen angezeigt werden. Damit eine konsistente UX umzusetzen, die dem Nutzer hilfreiche Hinweise gibt, ist nicht ohne JavaScript-Quirks möglich. Da würde ich lieber auf HTML5-Formularvalidierung verzichten und client- wie serverseitig eine eigene zuverlässige umsetzen.

Was übrigens nicht funktioniert ist einfach den Typ eines Formularfeldes zu ändern.

Wenn du ein input[type=date] machst und das type-Attribut dann auf text änderst um z.B. einen JavaScript-Datepicker zu verwenden zu können, ohne dass dich der originale stört, schlägt das unter Opera 11.52, Safari 5 oder Chrome 14 fehl:

Das ding Klonen, das Attribut ändern, wieder einfügen und dann das original entfernen hingegen funktioniert:

http://jsfiddle.net/fvCuH/

[Gunnar Bittersmann]

@@molily:

nuqneH

Das ist lustig Aussage angesichts dessen, dass man im Safari 5, ein Browser, der Techniken wie required unterstützt, das Prüfen des Formulars, das Anzeigen von Meldungen und das Blocken des Absendens manuell mit JavaScript lösen muss. Meines Wissens ist dieses Verhalten auch HTML5-konform.

“The no-validate state of an element is true if the element is a submit button and the element's formnovalidate attribute is present, or if the element's form owner's novalidate attribute is present, and false otherwise.”

Da hier weder @novalidate noch @formnovalidate im Spiel ist, sollte der Status false sein.

“When a form element form is submitted […]
5. If the scripted-submit flag is not set, and the submitter element's no-validate state is false, then interactively validate the constraints of form and examine the result: if the result is negative (the constraint validation concluded that there were invalid fields and probably informed the user of this) then abort these steps.”

Wie ich das lese, darf ein nicht korrekt ausgefülltes Formular nicht abgeschickt werden. Demnach wäre das Verhalten des Safari nicht HTML5-konform …

Im Firefox und Chrome hingegen wird das submit-Ereignis nicht gefeuert, wenn das Formular Fehler aufweist und browsereigene Fehlermeldungen angezeigt werden.

… sondern jenes von Firefox und Chrome.

Damit eine konsistente UX umzusetzen, die dem Nutzer hilfreiche Hinweise gibt, ist nicht ohne JavaScript-Quirks möglich.

Oh je, immer noch browserspezifische Eigenbrödlerei statt Standardkonformität. Browserkrieg 2.0.

Na dann schickt Safari eben auch das Formular ab und bekommt die Fehlermeldungen vom Server – vorläufig, bis Apple den Bug gefixt hat.

Da würde ich lieber auf HTML5-Formularvalidierung verzichten und client- wie serverseitig eine eigene zuverlässige umsetzen.

Warum sollte man den fähigen Browsern die performante Lösung vorenthalten?

Qapla'

[molily]

Hallo,

Wie ich das lese, darf ein nicht korrekt ausgefülltes Formular nicht abgeschickt werden. Demnach wäre das Verhalten des Safari nicht HTML5-konform …

Das freut mich zu hören.

Damit eine konsistente UX umzusetzen, die dem Nutzer hilfreiche Hinweise gibt, ist nicht ohne JavaScript-Quirks möglich.

Oh je, immer noch browserspezifische Eigenbrödlerei statt Standardkonformität. Browserkrieg 2.0.

Der Quirks ist der übliche, der einen browserseitig erwartet. Speziell Formularvalidierung geht ab JavaScript 1.0 ohne Probleme und harmloses DOM Scripting ist nicht browserspezifisch, sofern man brauchbare Abstraktionslayer verwendet. Und Eigenbrödlerei ist hier nur positiv, weil der Seitenautor die Hilfe- und Fehlermeldungen bestimmen kann und sie durchgehend gleich aussehen und funktionieren.

Warum sollte man den fähigen Browsern die performante Lösung vorenthalten?

Wenn ich serverseitig validiere, muss ich mir ohnehin ein gutes UI für Erklärungen und Fehlermeldungen ausdenken, das HTML und CSS dafür bauen und die dahinterstehende Logik programmieren.

Darauf aufbauend die Meldungen bereits clientseitig anzuzeigen, sofern es nur geht, wird vermutlich die Benutzbarkeit des Formulars maßgeblich verbessern. So etwas könnte man gut mit A/B-Tests überprüfen. Ich würde vermuten, ein Formular mit direktem clientseitigem Feedback wird häufiger und schneller abgeschlossen als eines mit Server-Roundtrips. Diese Usability-Vorteile stünden in keinem Verhältnis zum Mehraufwand, wenn man client- und serverseitige Validierung sinnvoll umsetzt.

Nutzt man clientseitige Validierung mit JavaScript, so ist es derzeit doppelter Aufwand, auf die HTML5-APIs zu setzen, um beispielsweise Fehlermeldungen anzupassen. Zumal diese fehlerhaft umgesetzt sind, sodass einfache Feature-Abfragen fehlschlagen. In diesem Script beispielsweise wird das Safari-Problem mit einem fragwürdigen Hack umschifft. Wer weiß, ob der in der nächsten Browsergeneration noch funktioniert.

Mathias

[Gunnar Bittersmann]

@@molily:

nuqneH

Und Eigenbrödlerei ist hier nur positiv, weil der Seitenautor die Hilfe- und Fehlermeldungen bestimmen kann und sie durchgehend gleich aussehen und funktionieren.

Durchgehend gleich?? Nein.

Du meinst: durchgehend gleich auf allen Browsern? Wayne interessiert das? Den Nutzer wohl kaum; der wird selten mit verschiedenen Browsern eine Website besuchen und die Darstellung vergleichen.

Für den Nutzer ist eher das durchgehend gleiche Aussehen von Fehlermeldungen (u.a. UI-Elementen) in seinem Browser über verschiedene Websites hinweg relevant. Und das erreicht man eben gerade mit HTML5.

Qapla'

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunnar Bittersmann!

Für den Nutzer ist eher das durchgehend gleiche Aussehen von Fehlermeldungen (u.a. UI-Elementen) in seinem Browser über verschiedene Websites hinweg relevant. Und das erreicht man eben gerade mit HTML5.

Es ist wohl eine Mischung aus beiden. Wenn ich auf ein fehlerhaft ausgefülltes Formularelement hinweise, sollte ich das auf ein und derselben Website auch immer im selben Stil tun. Beispielsweise eine rote outline oder ein roter Hintergrund.

Wobei sich natürlich auch die Frage stellt, wie viele Fehlermeldungen der einzelne zu Gesicht bekommt.

Matthias