Frage zum Wiki-Artikel „Validierung von Formularen“

[Chris234]

Hallo,

ich versuche bei meinen Formularen die Wertebereiche der Eingaben zu begrenzen. Die input Elemente sind vom Typ number. Ich habe über die Attribute min, max und step die entsprechenden Einstellungen vorgenommen und solange ich über die Pfeile die Zahlenwerte einstelle funktioniert das auch gut. Aber wenn ich über die Tastatur die Zahlen eingebe funktioniert die Prüfung nicht. Es werden zwar nur Zahlen akzeptiert und wenn über step nur ganze Zahlen akzeptiert werden die Nachkommastellen abgeschnitten, aber die Prüfung ob die Zahlen außerhalb des Wertebereichs liegen funktioniert nicht. Verstehe ich die Funktionsweise der Attribute falsch? Kann mir eventuell jemand helfen, wie ich eine "einfache" Wertebereichsprüfung realisieren kann, die nur die erlaubten Werte übermittelt?

Ich habe meinen HTML-Code angehängt, die cfg, id und category Attribute werden für die dynamische Anzeige des Inhaltes benötigt, da der Webserver über XML und eine Busstruktur mit der SPS kommuniziert. Mir ist bewusst, dass eine clientseitige Überprüfung umgangen werden kann und die serverseitige Prüfung nicht ersetzt, trotzdem soll clientseitig die Überprüfung im besten Fall nur valide Werte durchlassen.

Vielen Dank im voraus, Chris234

<div class="content_view">
  <table class="centeredTable" style="border: 10px solid #4C4C46">
    <tr>
      <td><span cfg="251" id="cfg_02" category="Diagnose">Tag</span></td>
      <td><span cfg="252" id="cfg_03" category="Diagnose">Monat</span></td>
      <td><span cfg="253" id="cfg_04" category="Diagnose">Jahr</span></td>
    </tr>
    <tr>
        <td><input id="value_wDiagSPSZeit_Tag" type="number" min="1" max="31" step="1" value="24" onchange="onManualValueChange(this)"></td>
      <td><input id="value_wDiagSPSZeit_Monat" type="number" min="1" max="12" step="1" value="10" onchange="onManualValueChange(this)"></td>
      <td><input id="value_wDiagSPSZeit_Jahr" type="number" min="2000" max="2100" step="1" value="2017" onchange="onManualValueChange(this)"></td>
    </tr>
      <tr><td colspan="3"><br></td></tr>
    <tr>
      <td><span cfg="254" id="cfg_05" category="Diagnose">Stunde</span></td>
      <td><span cfg="255" id="cfg_06" category="Diagnose">Minute</span></td>
      <td><span cfg="256" id="cfg_07" category="Diagnose">Sekunde</span></td>
    </tr>
    <tr>
      <td><input id="value_wDiagSPSZeit_Stunde" type="number" min="0" max="23" step="1" value="12"  onchange="onManualValueChange(this)"></td>
      <td><input id="value_wDiagSPSZeit_Minute" type="number" min="0" max="59" step="1" value="30"  onchange="onManualValueChange(this)"></td>
      <td><input  id="value_wDiagSPSZeit_Sekunde" type="number" min="0" max="60" step="1" value="0" onchange="onManualValueChange(this)"></td>
    </tr>
    <tr>
      <td style="padding-top: 100px;"><button id="spsLesenBtn0" type="button" name="sps_lesen" onClick="showLoader();spsChangeBit('wDiagSPSZeit_SPSLesen', 'wDiagSPSZeit_SPSLesen_IO');"><img src="../images/sps_lesen.png" alt=" "><span cfg="193" id="cfg_09" category="Main">&nbsp;SPS lesen</span></button></td>
      <td style="padding-top: 100px;"><button type="button" name="sps_schreiben" onClick="showLoader();spsWriteAllValues('wDiagSPSZeit_SPSSchreiben', 'wDiagSPSZeit_SPSSchreiben_IO');"><img src="../images/sps_schreiben.png" alt=" "><span cfg="194" id="cfg_10" category="Main">&nbsp;SPS schreiben</span></button></td>
        <td> &nbsp; </td>
    </tr>
  </table>
</div>

[Auge]

Hallo

ich versuche bei meinen Formularen die Wertebereiche der Eingaben zu begrenzen. Die input Elemente sind vom Typ number. Ich habe über die Attribute min, max und step die entsprechenden Einstellungen vorgenommen und solange ich über die Pfeile die Zahlenwerte einstelle funktioniert das auch gut. Aber wenn ich über die Tastatur die Zahlen eingebe funktioniert die Prüfung nicht. Es werden zwar nur Zahlen akzeptiert und wenn über step nur ganze Zahlen akzeptiert werden die Nachkommastellen abgeschnitten, aber die Prüfung ob die Zahlen außerhalb des Wertebereichs liegen funktioniert nicht. Verstehe ich die Funktionsweise der Attribute falsch? Kann mir eventuell jemand helfen, wie ich eine "einfache" Wertebereichsprüfung realisieren kann, die nur die erlaubten Werte übermittelt?

Mit welchem Browser/welchen Browsern testest du? Nicht jedes Attribut wird von jedem Browser interpretiert (siehe caniuse, bitte auf die Fußnoten achten).

Tschö, Auge

[JürgenB]

Hallo,

die eingebaute Validierung bei Zahleingaben ist meines Wissens nach browserabhängig und ersetzt keine weitere Validierung per Javascript und auf dem Server.

Gruß
Jürgen

[Auge]

Hallo

die eingebaute Validierung bei Zahleingaben ist meines Wissens nach browserabhängig und ersetzt keine weitere Validierung per Javascript und auf dem Server.

??? Was erzählst du mir das? Der OP schrieb selbst:

„Mir ist bewusst, dass eine clientseitige Überprüfung umgangen werden kann und die serverseitige Prüfung nicht ersetzt, trotzdem soll clientseitig die Überprüfung im besten Fall nur valide Werte durchlassen.“

Tschö, Auge

[JürgenB]

Hallo,

die eingebaute Validierung bei Zahleingaben ist meines Wissens nach browserabhängig und ersetzt keine weitere Validierung per Javascript und auf dem Server.

??? Was erzählst du mir das?

sorry, in der falschen Ebene geantwortet.

Der OP schrieb selbst:

„Mir ist bewusst, dass eine clientseitige Überprüfung umgangen werden kann und die serverseitige Prüfung nicht ersetzt, trotzdem soll clientseitig die Überprüfung im besten Fall nur valide Werte durchlassen.“

die browsereigene Validierung von Zahlen muss nicht umgangen werden, sie ist so stark browserabhängig, das man sie allenfalls als "nive to have" ansehen kann, darauf verlassen kann man sich nicht. Wenn schon clientseitig eine Prüfung stattfinden soll, dann ist Javascript erforderlich.

Gruß
Jürgen

[Auge]

Hallo

Der OP schrieb selbst:

„Mir ist bewusst, dass eine clientseitige Überprüfung umgangen werden kann und die serverseitige Prüfung nicht ersetzt, trotzdem soll clientseitig die Überprüfung im besten Fall nur valide Werte durchlassen.“

die browsereigene Validierung von Zahlen muss nicht umgangen werden, sie ist so stark browserabhängig, das man sie allenfalls als "nive to have" ansehen kann

Dass die Attribute nicht die alleinige Prüfung sein können, ist klar. Das ist, so interpretiere ich den zitierten Satz, offensichtlich auch dem OP klar. Dass die Attribute im eigentlichen Sinne nicht einmal eine Prüfung an sich sind, sollte auch klar sein. Aber da, wo sie funktionieren, können sie dem Benutzer die Eingabe erleichtern, indem sie ungültige Eingaben von vornherein ausschließen.

darauf verlassen kann man sich nicht. Wenn schon clientseitig eine Prüfung stattfinden soll, dann ist Javascript erforderlich.

Unbestritten. Natürlich nur zusätzlich zur serverseitigen Prüfung.

Tschö, Auge

[Chris234]

Hallo,

ich habe wohl zu viel Hoffnung in die Attribute gesteckt, dass diese eine ungültige Eingabe von vornherein ausschließen können. Ich hatte gehofft, dass ich mir damit das Javascript auf Clientseite sparen könnte, da auf dem Server eine unabhängige Validierung der Eingaben läuft, aber ich wollte zusätzlich dem Benutzer die Eingabe erleichtern, so dass er vor dem Absenden des Formulars sieht, dass die Werte nicht akzeptiert werden.

Dann komme ich wohl leider nicht um das zusätzliche Javascript herum.

Vielen Dank, Chris 234

[Auge]

Hallo

ich habe wohl zu viel Hoffnung in die Attribute gesteckt, dass diese eine ungültige Eingabe von vornherein ausschließen können. …

Wenn sie funktionieren, können sie das bei Benutzung des HTML-Formulars bei ausgeschlossener Manipulation des HTML-Quelltextes tatsächlich leisten. Falls der Anwender die Attribute wissentlich und willentlich umgeht oder einen „unfähigen“ Browser benutzt, kann er natürlich alles eingeben, was er will. Daher ist dies keine Prüfung auf ungültige Eingaben.

Ich hatte gehofft, dass ich mir damit das Javascript auf Clientseite sparen könnte, da auf dem Server eine unabhängige Validierung der Eingaben läuft …

Kannst du doch, wenn du damit leben willst, dass ungültige Eingaben „erst“ auf dem Server erkannt und behandelt werden.

… aber ich wollte zusätzlich dem Benutzer die Eingabe erleichtern, so dass er vor dem Absenden des Formulars sieht, dass die Werte nicht akzeptiert werden.

Nun ja, für einige Browser funktioniert das, für andere nicht oder nicht vollständig. Anwender jener Browser, in denen das funktioniert, haben einen Mehrwert, für Anwender, in deren Browsern das nicht funktioniert, gibt es (im Normalfall) keinen Unterschied zwischen nicht vorhandenen und nicht funktionierenden Attributen.

Dann komme ich wohl leider nicht um das zusätzliche Javascript herum.

Wenn du eine browserseitge Vorprüfung der Eingaben durchführen willst, ja.

Tschö, Auge

[Gunnar Bittersmann]

@@Chris234

Dann komme ich wohl leider nicht um das zusätzliche Javascript herum.

„Das JavaScript funzt nicht!“
„Packen wir noch mehr JavaScript drauf!“

😱

Im Gegenteil!

1. Sorge dafür, dass das Formular ohne JavaScript funktioniert. Es sollte mich wundern, wenn dann nicht auch die Validierung funktionieren sollte.

2. Wenn du auf dieser Grundlage die UX mit JavaScript noch verbessern kannst, dann tu es.

LLAP 🖖

[Chris234]

Ich teste mit Chrome 61.0.3163.100 64Bit. Laut caniuse sollten die Attribute verwendbar sein.

[1unitedpower]

Wie schickst du das Formular ab? Ich sehe keinen Submit-Button, der beim Auslösen die Formular-Validierung anstoßen würde. Deine beiden Buttons sind explizit keine Submit-Buttons, das sagst du mit type="button".

[Chris234]

Hallo, das Formular wird über den zweiten Button "sps-schreiben" abgeschickt. Dies wird im Hintergrund durch einen onclick über Javascript weiterverarbeitet. Über submit klappt die Verarbeitung über das Javascript anschließend leider nicht, da müsste ich später nochmal dran um das eventuell zu realisieren. Macht das einen Unterschied für die Prüfung?

Chris234

[Gunnar Bittersmann]

@@Chris234

das Formular wird über den zweiten Button "sps-schreiben" abgeschickt. Dies wird im Hintergrund durch einen onclick über Javascript weiterverarbeitet.

Im Glücksfall.

“While it’s tempting to think that only a small minority of visitors will miss out on a site’s JavaScript, the truth is that everybody is a non‐JavaScript user until the JavaScript has finished loading ...if the JavaScript finishes loading. Flaky connections, interfering network operators, and unpredictable ad‐blocking software can torpedo the assumption that JavaScript will always be available.
“The problem is not with people deliberately disabling JavaScript in their browsers. Although that’s a use case worth considering, it’s not the most common cause of JavaScript errors.”
—Jeremy Keith, Resilient web design, Chapter 4

Warum willst du das Abschicken des Formulars vom Glück abhängig machen? Warum nicht die Technik verwenden, die nicht auf Glück angewiesen ist: HTML‽

Übrigens hast du noch nicht einmal ein Formular …

Macht das einen Unterschied für die Prüfung?

… kein Formular, keine Formularvalidierung.

LLAP 🖖

[dedlfix]

Tach!

das Formular wird über den zweiten Button "sps-schreiben" abgeschickt. Dies wird im Hintergrund durch einen onclick über Javascript weiterverarbeitet.

Im Glücksfall.

Wenn man eine SPS-Maschine steuert, dann passiert das in einer abgegrenzen Umgebung durch einen genau bekannten Personenkreis und nicht im großen weiten Internet. Der "Glücksfall" kann also durch entsprechend formulierte Bedingungen erzwungen werden. "Muss mit Browser X, dem Standardbrowser der Firma, und mit Konfiguration YZ funktionieren". Das Problem ist hier bei weitem nicht so relevant wie dargestellt.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Wenn man eine SPS-Maschine steuert, dann passiert das in einer abgegrenzen Umgebung durch einen genau bekannten Personenkreis und nicht im großen weiten Internet. Der "Glücksfall" kann also durch entsprechend formulierte Bedingungen erzwungen werden.

Indem man das JavaScript ins HTML eingebettet.

"Muss mit Browser X, dem Standardbrowser der Firma, und mit Konfiguration YZ funktionieren". Das Problem ist hier bei weitem nicht so relevant wie dargestellt.

Dennoch bleibt die Frage: Wenn man Webtechnologien einsetzt, warum setzt man dann nicht Webtechnologien ein?

Mit anderen Worten: Warum für eine interne Anwendung etwas ganz anderes tun als man für eine Webanwendung tun würde? „Weil man’s kann“ wäre ein zu schwaches Argument.

LLAP 🖖

[dedlfix]

Tach!

"Muss mit Browser X, dem Standardbrowser der Firma, und mit Konfiguration YZ funktionieren". Das Problem ist hier bei weitem nicht so relevant wie dargestellt.

Dennoch bleibt die Frage: Wenn man Webtechnologien einsetzt, warum setzt man dann nicht Webtechnologien ein?

Mit anderen Worten: Warum für eine interne Anwendung etwas ganz anderes tun als man für eine Webanwendung tun würde? „Weil man’s kann“ wäre ein zu schwaches Argument.

Man braucht nicht in jedem Fall die kompletten Eigenschaften der Webtechniken für eine konkrete Anwendung. Deswegen sehe ich es als legitim an, sich auf den Teil zu beschränken, der zielführend ist (oder erscheint). "Weil man's nicht muss" wäre hier das Argument.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Deswegen sehe ich es als legitim an, sich auf den Teil zu beschränken, der zielführend ist (oder erscheint). "Weil man's nicht muss" wäre hier das Argument.

„Man muss keine in Browsern bereits vorhandene Funktionalität verwenden, sondern kann dasselbe ja nochmal mit JavaScript nachbauen.“

Merkste selber, ne?

LLAP 🖖

[Chris234]

Wenn man eine SPS-Maschine steuert, dann passiert das in einer abgegrenzen Umgebung durch einen genau bekannten Personenkreis und nicht im großen weiten Internet. Der "Glücksfall" kann also durch entsprechend formulierte Bedingungen erzwungen werden. "Muss mit Browser X, dem Standardbrowser der Firma, und mit Konfiguration YZ funktionieren". Das Problem ist hier bei weitem nicht so relevant wie dargestellt.

Wie dedlfix schon angemerkt hat, werden die Seiten tatsächlich nur firmenintern genutzt und müssen somit nur mit Chrome oder dem IE funktionieren und nach Admin-Richtlinien ist JavaScript immer aktiviert. Dementsprechend ist die Frage nach der Verfügbarkeit von JavaScript nicht vom Glück abhängig.

Vielleicht jetzt eine dumme Frage, wieso habe ich kein Formular?

[Gunnar Bittersmann]

@@Chris234

… und nach Admin-Richtlinien ist JavaScript immer aktiviert. Dementsprechend ist die Frage nach der Verfügbarkeit von JavaScript nicht vom Glück abhängig.

Wie ich Jeremy Keith zitiert hatte, ist „JavaScript aktiviert“ keine hinreichende Bedingung für „JavaScript wird ausgeführt“.

Vielleicht jetzt eine dumme Frage, wieso habe ich kein Formular?

Was fragst du mich das? Du warst es doch, der kein form-Element verwendet hat.

LLAP 🖖

[Chris234]

Das frage ich mich gerade auch, warum ich kein form-Element verwendet habe. Ich habe nun ein richtiges Formular erstellt und die Prüfung funktioniert wie gewünscht. Vielen Dank für den Hinweis.

Chris234

[JürgenB]

Hallo Gunnar,

Macht das einen Unterschied für die Prüfung?

… kein Formular, keine Formularvalidierung.

da muss ich jetzt nachfragen: Hängt die Prüfung auf gültige Zahleingaben im <input type="number" …> davon ab, ob das <input> innerhalb eines <form> notiert ist?

Gruß
Jürgen

[Matthias Apsel]

Hallo JürgenB,

da muss ich jetzt nachfragen: Hängt die Prüfung auf gültige Zahleingaben im <input type="number" …> davon ab, ob das <input> innerhalb eines <form> notiert ist?

Ja. Auch bei required gibt (vielleicht auch nur gab) es Unterschiede.

Bis demnächst
Matthias