JavaScript Form-Validierung per JavaScript

[eightcore]

Guten Abend.

Habe ein Form mit Username, Passwort und einem Anmelde-Button.

 <form method="post" name="Logon" onsubmit="return chkFormular()" action="login.php">

Die Username- und Passwort-Checkbox soll also per JavaScript überprüft werden. Wenn die Daten syntaktisch korrekt sind, soll der Browser zu der Datei login.php wechseln.

Problem: Letztere Datei wird auch aufgerufen, wenn die Funktion chkFormular false zurückgibt.


Was mache ich falsch?

 

[iLegend]

Hallo,

du darfst das nicht mit einem submit machen. Bei dir wird nämlich automatisch die login.php aufgerufen egal was chkFormular macht. Beim Submit wird die action ausgeführt und da der Request schon gesendet wurde ist egal was chkFormular macht.

So ca muss es aussehen.
<form name="Logon" action=">
<input type="text" name="username"/>
<input type="password" name="password"/>
<input type="button" onclick="chkFormular"/>
</form>
und in der chkFomular -Funktion musst du dann bei einer richigen Eingabe ein document.form.logon.submit oder so machen. du kannst das natürlich schon mit einem submit button machen aber dann musst du die default action vom submit button abbrechen und dann die Eingaben checken und am Ende wieder submitten.

 

[1668mib]

Man sollte dazu sagen, dass eightcore es gemäß dem gemacht, was SelfHTML schreibt: http://de.selfhtml.org/javascript/beispiele/formulareingaben.htm
(soll nicht heißen, dass das es so zwingend sein muss)
Interessanterweise geht das Beispiel von SelfHTML bei mir...

Und ich freu mich schon auf die Kommentare mit "Prüfungen nie in JavaScript" usw, die übersehen, dass es hier nur um den User-Komfort geht, sinnlose Formulare gar nicht erst an den Server zu schicken... :-)

Edit: Kannst du mal die chkFormular() zeigen, v.a. so dass man sehen kann, dass sie auch tatsächlich false zurückliefert?
Ach ja, ich habs unter Chrome getestet.


Edit2: Ich würde sogar die SelfHTML-Variante bevorzugen, da sie bei abgeschaltetem JS dennoch funktioniert, wenn auch ohne Client-seitige Vorvalidierung.

 

[eightcore]

Das einzige, was momentan in der Prüf-Methode steht ist return false;. Ich werde morgen (also eigentlich heute) das Ganze mit andern Browsern testen und mich anschliessend nochmal hier melden. Bereits vielen Dank für die Hilfe!

 

[Daaron]

Und ich freu mich schon auf die Kommentare mit "Prüfungen nie in JavaScript" usw, die übersehen, dass es hier nur um den User-Komfort geht, sinnlose Formulare gar nicht erst an den Server zu schicken... :-)

Im Zweifel hast du es eh mit Paranoikern zu tun, die mit NoScript durchs Netz stolpern. Viel besser ist es, den HTML5 Form Validator als erste Filterstufe zu verwenden. Der triggert schließlich bei jedem modernen Browser.

 

[eightcore]

Ihr könnt gerne mit dem Lehrer Kontakt aufnehmen und ihn bitten, die Aufgabenstellung zu ändern...


Edit: Hab's jetzt noch mal gestartet und schwupps, funktioniert. Habe - so weit ich weiss - nichts geändert.
Danke für eure Hilfe!

 

[Daaron]

Tja, solange du nicht alles glaubst, was der Lehrer dir erzählt.... In der Praxis machts niemand so wie du es beschrieben hast. Entweder man nutzt direkt HTML5 oder man verwendet den Validator eines Frameworks. http://mootools.net/docs/more/Forms/Form.Validator ist weitaus schneller und eleganter zu implementieren als handgeklöppelte Validatoren.

 

[Blackbenji]

und weder das mootools.net noch das selfhtml script prüfen wirklich richtig. bei beiden lies sich folgende eingabe umsetzen und wurde erfolgreich abgeschickt, das ist keine validierung.

Feldname: User
Inhalt: j

Feldname: Ort
Inhalt: j

Feldname: Mail
Inhalt: j@j.d

Feldname: Alter
Inhalt: 0

 

[catmoney]

Ich würde mich nie nur auf clientseitige Formularvalidierung verlassen.

Wieso schickst du die Daten nicht per Ajax-Aufruf an den Server und prüfst dort serverseitig (mit php-Script) und gibst anschließend die Fehlermeldung oder leitest im Erfolgsfall zu deiner login.php weiter.

 

[1668mib]

@catmoney: Ich würde nie eine Antwort schreiben, ohne zumindest ein paar Beiträge durchgelesen zu haben...
Die Antwort auf deine Frage wurde schon lange gegeben ...

 

[catmoney]

@1668mib: Wie meinst du das? Ich habe lediglich meine Meinung zum Thema geschrieben und habe doch gar keine Frage gestellt.

 

[1668mib]

Entschuldige meine schlechten Deutschkenntnisse. Ich dachte mal, das Wort "Wieso" leitet Fragen ein. Aber da scheine ich auf dem Holzweg zu sein. Genauso mit der Ansicht, dass es eigentlich nichts mit dem Thema zu tun hat, weil die Aufgabenstellung die Umsetzung vorgab. Aber ich rede wohl nur wirres Zeugs...

 

[catmoney]

Du hast Recht und ich muss mich entschulidgen, ich hatte die Antworten tatsächlich nicht detailliert gelesen und dabei deinen Kommentar übersehen:

"Und ich freu mich schon auf die Kommentare mit "Prüfungen nie in JavaScript" usw, die übersehen, dass es hier nur um den User-Komfort geht, sinnlose Formulare gar nicht erst an den Server zu schicken... :-)"

Aber Dank deiner sarkastischen Antwort werde ich nun zukünftig alles besser durchlesen

 

[Spike S.]

Tja, solange du nicht alles glaubst, was der Lehrer dir erzählt.... In der Praxis machts niemand so wie du es beschrieben hast. Entweder man nutzt direkt HTML5 oder man verwendet den Validator eines Frameworks. http://mootools.net/docs/more/Forms/Form.Validator ist weitaus schneller und eleganter zu implementieren als handgeklöppelte Validatoren.

Das ist mir etwas zu pauschal^^
Da HTML5 noch nicht final verabschiedet ist, würde ich mich nicht zu sehr darauf verlassen. Außerdem zieht das wieder Sonderlocken für verschiedene Browser nach sich.
Und ein Framework ist auch nicht immer die Lösung. Wenn ich nur 1 oder 2 Felder prüfen muss, ist ein zusätzliches Framework einfach nur unnötiger Traffic und Rechenlast. Außerdem, wo bleibt da der Spaß mit DOM und den Events?
Es kommt halt immer drauf an...

 

[1668mib]

@Spkie S.: Richtig, HTML5 als gesamter Standard ist nicht final. Und theoretisch könnte sich noch alles ändern. Allerdings sind gewisse Teile schon als "fertig" spezifiziert, und man kann davon ausgehen, dass sich an den Spezifikationen nichts mehr ändern wir bis zu Verabschiedung.

 

[Daaron]

Ich hab noch kein Projekt erlebt, bei dem das einzige Stück JS die Validierung von 2-3 Feldern war. Am Ende landet doch immer irgendwo ein Slider oder wenigstens eine Lightbox.
Und an den meisten Teilen von HTML5 wird sich genau gar nichts mehr ändern, weil sonst ALLE modernen Browser, inkl. des IE10, umgeschrieben werden müssten. Wie wahrscheinlich findest du es, dass sich so viel ändert, dass jeder Browser großflächig geändert werden muss hinsichtlich Funktionen, die schon seit 1-2 Jahren gut funktionieren?

 

[1668mib]

@Daaron: Die Kausalität ist falsch. Es ändert sich bei den größten Teilen nicht, weil sonst alle möglichen Browser umgeschrieben werden müssten (mein Gott, von Chrome erscheinen täglich zwei neue Versionen...), sondern weil die entsprechenden Drafts so verabschiedet wurden.

 

[Spike S.]

Ist ja schön und gut, dass man sich einigte (oder einfach alle dem Ersten hinterher) den Standard schon umzusetzen und zu veröffentlichen. Das Internet ist dynamisch genug, oder vielleicht dadurch zu dynamisch... Auf jeden Fall beschleunigte es die positive Entwicklung der Webseite als solches.
Allerdings habe ich als Softwaretester eine andere Einstellung zu nicht-abgenommenen und nicht-freigegebenen Spezifikationen. Im Zweifel sind sie das Papier nicht Wert und mehrere Tage/Wochen Arbeit für die Katz

 

[Daaron]

Im Bereich der Web-Entwicklung balanciert man immer auf dem Grat zwischen "standardisiert" und "es funktioniert halt".
Denk doch nur an CSS3. Es ist nicht wirklich final, nicht einmal ansatzweise. Aber wie räudig würde das Netz aussehen ohne border-radius oder box-shadow? Wie viele coole Sachen würden ohne transitions nicht gehen?
Und hinsichtlich HTML5: Wie nützlich wäre das iPad, wenn es Youtube nicht im HTML5-Modus gäbe?

Vieles aus dem Bereich HTML5/CSS3 ist de-facto Standard. Es mag nicht in Stein gemeißelt sein, aber ändern wird sich daran trotzdem nichts. Das gilt auch für HTML5 Form Validation.