Javascript-Validierung: Eingaben nach Fehlern überprüfen und entsprechend reagieren

[borisbaer]

Hallo! Ich habe mein JS-Script zur Formular-Validierung so weit fertig, als dass es bei Verstößen die richtige Fehlermeldung anzeigt (siehe problematische Seite).

Jedoch kriege ich es nicht hin, dass das Event.preventDefault() nur dann feuert, wenn auch wirklich Fehlermeldungen vorliegen.

Zunächst habe ich ein globales Array namens errors definiert, das beim Hinzufügen bzw. Löschen einer Fehlermeldung befüllt oder geleert wird. Das hat auch prinzipiell funktioniert, doch dann musste ich merken, dass dieser Weg bei mehreren Formularen auf einer Seite nicht funktioniert, denn jedes einzelne Formular befüllt dieses Array gleichermaßen.

Der letzte Versuch war, ein lokales Array namens errors befüllen zu lassen, doch irgendwie hat das nicht so recht hingehauen, da ich es nicht hingekriegt habe, die Fehlermeldung in den Funktionen „hochzureichen“. Deshalb suche ich nach einer Möglichkeit, dieses JS-Script (validation.js) so zu ergänzen, dass am Ende die validate-Funktion weiß, ob noch Fehler vorliegen oder nicht.

Ich bitte um Hilfe!

Grüße
Boris

[Rolf B]

Hallo borisbaer,

doch dann musste ich merken, dass dieser Weg bei mehreren Formularen auf einer Seite nicht funktioniert, denn jedes einzelne Formular befüllt dieses Array gleichermaßen.

Das scheint mittlerweile gelöst zu sein. Wenn ich bei Registrierung was eingebe, passiert bei Login nichts mehr.

Aaaaaber...

• Ich habe ein Zeichen im Benutzernamen eingetippt und das ganze Formular wird rot. WTF? Du solltest im input-Event nur das Element prüfen, das gerade bearbeitet wird, und Tests wie "mind. 2 Zeichen" im input zu prüfen ergibt keinen Sinn. Ob die Eingabe zu kurz ist, weißt Du erst, wenn der User das Feld verlässt (change-Event). Ob es sinnvoll ist, im blur-Event Validierungen durchzuführen, weiß ich auch nicht. Ich tabbe nur durch's Formular und gleich wird alles rot - das ist ganz schön deprimierend.

• Ich wollte Benutzername "Müller" eingeben. → Der Benutzername darf nur alphanumerische Zeichen enthalten. WTF?

• Deine Password-Reveal Button funktioniert nicht.

Dann habe ich mir deinen Code angeschaut.

document.addEventListener( 'DOMContentLoaded', () => {

	const formSb = document.querySelectorAll( 'form button:not([type="button"])' );
	formSb.forEach( node => {
		const form = node.closest( 'form' );
		node.onclick = e => {

Das ist in mehrfacher Beziehung der falsche Ansatz.

1. Du musst nicht die Submit-Buttons suchen und dann deren Form, sondern direkt die Forms. Denn so läufst Du für das sign-up und das sign-in Form zweimal da durch. Gut, dass Du onclick und onkeydown verwendst und nicht addEventListener.
2. Form-Validation macht man nicht im click-Handler des submit-Buttons, sondern im submit-Event des Forms
3. Feld-Validation macht man nicht im keydown-Handler eines input-Elements, sondern im input-Event für Sofortprüfungen und im change-Event für Prüfungen beim Verlassen des Feldes.
4. Das erspart Dir dann auch den setTimeout im keydown-Event. Der ist vermutlich drin, damit die FM nicht schon kommt, bevor Du die Taste losgelassen hast...

		if ( rule === 'verify' ) {

			input.onblur = () => {

				fetch( `/verify?${input.name}=${encodeURIComponent( value )}` )

WHOA! Du setzt bei jedem Tastendruck zweimal einen neuen blur-Handler. Aber eben auch erst bei einem Tastendruck. Ohne einen Tastendruck gibt's keinen blur-Handler. Da die verify-Regel bei jedem Tastendruck angestoßen wird, solltest Du an dieser Stelle keine Eventhandler registrieren. Sowas macht man einmal vorneweg. Aber wie auch immer - der fetch sollte nicht im onblur passieren, sondern im change-Event.

Kennst Du eigentlich unsere Wiki-Artikel zur browsereigenen Validierung in HTML und JavaScript? Die nimmt Dir etliche deiner Probleme automatisch ab, weil sie die Fehlerbehandlung pro Formular durchführt.

Damit würde dein validation.js ganz anders aussehen und vieles, was Du jetzt manuell programmiert hast, automatisch passieren.

Rolf

[borisbaer]

Hallo Rolf,

• Ich habe ein Zeichen im Benutzernamen eingetippt und das ganze Formular wird rot. WTF? Du solltest im input-Event nur das Element prüfen, das gerade bearbeitet wird, und Tests wie "mind. 2 Zeichen" im input zu prüfen ergibt keinen Sinn. Ob die Eingabe zu kurz ist, weißt Du erst, wenn der User das Feld verlässt (change-Event). Ob es sinnvoll ist, im blur-Event Validierungen durchzuführen, weiß ich auch nicht. Ich tabbe nur durch's Formular und gleich wird alles rot - das ist ganz schön deprimierend.

ja, so wollte ich es auch nicht lassen. Ist nur zum Testen.

• Ich wollte Benutzername "Müller" eingeben. → Der Benutzername darf nur alphanumerische Zeichen enthalten. WTF?

Auch hier ... von diesen Regeln sind manche nur Platzhalter, auch sie sind nur zum Testen da. Ich habe leider noch keine RegEx für a-z, a-Z, 0-9, Umlaute, Leerzeichen und was man sonst noch vielleicht erlauben sollte. Wenn man jenseits der alphanumerischen Zeichen geht, dann ergeben sich ja gleich ganz viele Eventualitäten, die man beachten muss. Darum kümmere ich mich später.

• Deine Password-Reveal Button funktioniert nicht.

Hmm, bei mir geht er. 🤷‍♂️

1. Du musst nicht die Submit-Buttons suchen und dann deren Form, sondern direkt die Forms. Denn so läufst Du für das sign-up und das sign-in Form zweimal da durch. Gut, dass Du onclick und onkeydown verwendst und nicht addEventListener.
2. Form-Validation macht man nicht im click-Handler des submit-Buttons, sondern im submit-Event des Forms

form.forEach( node => {
	⋮
	node.onsubmit = e => {

		if ( node.name === 'sign-in' ) {
			if ( !validate( username, [ { name: 'required' } ] ) )
				e.preventDefault();
			if ( !validate( password, [ { name: 'required' } ] ) )
				e.preventDefault();
		}

		if ( node.name === 'sign-up' ) {
			if ( !validate( username, [ { name: 'required' }, { name: 'minlength', param: 2 }, { name: 'maxlength', param: 20 }, { name: 'alphanumeric' }, { name: 'verify' } ] ) )
				e.preventDefault();
			⋮
		}
	}
});

Ist das so besser?

3. Feld-Validation macht man nicht im keydown-Handler eines input-Elements, sondern im input-Event für Sofortprüfungen und im change-Event für Prüfungen beim Verlassen des Feldes.

Was meinst du mit „input-Event für Sofortprüfungen“? Kenne ich leider nicht.

4. Das erspart Dir dann auch den setTimeout im keydown-Event. Der ist vermutlich drin, damit die FM nicht schon kommt, bevor Du die Taste losgelassen hast...

Andersrum. Damit die Fehlermeldung nicht erst nach dem nächsten Tastenschlag erscheint.

WHOA! Du setzt bei jedem Tastendruck zweimal einen neuen blur-Handler. Aber eben auch erst bei einem Tastendruck. Ohne einen Tastendruck gibt's keinen blur-Handler. Da die verify-Regel bei jedem Tastendruck angestoßen wird, solltest Du an dieser Stelle keine Eventhandler registrieren. Sowas macht man einmal vorneweg. Aber wie auch immer - der fetch sollte nicht im onblur passieren, sondern im change-Event.

Okay, das ist gut zu wissen, danke! Wäre es dann nicht vielleicht sogar besser für die den verify-Check direkt ein onchange in den input zu schreiben? Z.B. onchange="validate( this, [ { name: 'verify' } ] );".

Kennst Du eigentlich unsere Wiki-Artikel zur browsereigenen Validierung in HTML und JavaScript? Die nimmt Dir etliche deiner Probleme automatisch ab, weil sie die Fehlerbehandlung pro Formular durchführt.

Kannte ich noch nicht, danke! Muss ich mir mal genauer anschauen. Sieht jedenfalls vielversprechend aus. Ich wusste z.B. nicht, dass man invalid als Event Listener benutzen kann. Aber kann man hier auch gleich mehrere Fehlermeldungen pro Feld anzeigen lassen? Also z.B. „braucht Großbuchstaben“, „braucht Sonderzeichen“ oder so.

Ein Problem bleibt bei mir zudem noch bestehen. Beim onsubmit-Event muss ja ein preventDefault her. Du siehst, dass ich es oben mehrmals stehen habe. Ich möchte diese Redundanz vermeiden. die validate-Funktion gibt bei mir momentan ein true aus, falls keine Fehler vorliegen und ansonsten false. Wie kann ich das Script so schreiben, dass ich nicht dauernd das e.preventDefault() reinschreiben muss?

Theoretisch müsste ich ja schauen, ob mindestens eine validate-Funktion ein false ausgibt und dann preventDefault() aufrufen. Gehe ich aber z.B. so vor, dass ich schreibe …

if (
	!validate( username, [ { name: 'required' } ] )
		||
	!validate( password, [ { name: 'required' } ] )
)
	e.preventDefault();

… dann funktioniert das Ein- und Ausblenden der Fehlermeldungen nicht mehr richtig …

Grüße
Boris

[Rolf B]

Hallo borisbaer,

ich bin dieses Wochenende 100% belegt und kann erst am Montag schauen.

Rolf

[Gunnar Bittersmann]

@@borisbaer

Ich habe leider noch keine RegEx für a-z, a-Z, 0-9, Umlaute, Leerzeichen und was man sonst noch vielleicht erlauben sollte.

Da kann ich helfen: .+. Man sollte alles erlauben. Die Nutzer wissen am besten, wie sie heißen.

Das heißt: man braucht keinen RegExp. Und auch gar keine Prüfung (außer ob überhaupt was eingegeben wurde).

---

	node.onsubmit = e => {

Ist das so besser?

Gut ist es nicht. Wofür steht e? Element? Event? Irgendwas anderes? Man muss überlegen.

Benenne Variablen sinnvoll: event.

---

3. Feld-Validation macht man nicht im keydown-Handler eines input-Elements, sondern im input-Event für Sofortprüfungen und im change-Event für Prüfungen beim Verlassen des Feldes.

Was meinst du mit „input-Event für Sofortprüfungen“? Kenne ich leider nicht.

Bei Eingaben und beim Verlassen des Eingabefelds feuern verschiedene Events; kannste dir in diesem Codepen ansehen.

---

Aber kann man hier auch gleich mehrere Fehlermeldungen pro Feld anzeigen lassen? Also z.B. „braucht Großbuchstaben“, „braucht Sonderzeichen“ oder so.

Nein! Davon sollte man nicht mehrere Fehlermeldungen anzeigen, sondern exakt 0 (in Worten: null).

Es sind keine Fehler des Nutzers, sondern Fehler des Entwicklers, des Produktmanagers, des Designers. Von Passwörtern zu verlangen, sie müssten Zeichen aus bestimmten Zeichenklassen enthalten ist – Entschuldigung für mein Französisch – völliger bullshit. Das war’s auch vor 8 Jahren schon.

Was man machen kann: die Sicherheit eines Passworts prüfen und – je nach Anwendung – zumindest mittlere Sicherheit verlangen.

🖖 Живіть довго і процвітайте

[Der Martin]

Hallo,

Aber kann man hier auch gleich mehrere Fehlermeldungen pro Feld anzeigen lassen? Also z.B. „braucht Großbuchstaben“, „braucht Sonderzeichen“ oder so.

Nein! Davon sollte man nicht mehrere Fehlermeldungen anzeigen, sondern exakt 0 (in Worten: null).

Es sind keine Fehler des Nutzers, sondern Fehler des Entwicklers, des Produktmanagers, des Designers. Von Passwörtern zu verlangen, sie müssten Zeichen aus bestimmten Zeichenklassen enthalten ist – Entschuldigung für mein Französisch – völliger bullshit.

naja, das stimmt so nicht ganz. Die Sicherheit eines Passworts hängt von mehreren Faktoren ab. Von der Länge natürlich, aber auch von der Anzahl der möglichen verwendbaren Zeichen. Und von der Entropie, also sozusagen der Chaotizität: Passwörter mit einer für Außenstehende völlig zufälligen Kombination von Zeichen sind schwerer zu erraten, und die Wahrscheinlichkeit, dass sie durch Wörterbuch-Angriffe gefunden werden, ist geringer als etwa bei "wiesel22".

Gegen Brute Force nützt das freilich nichts. Hier hilft nur Länge und eine möglichst große Menge von Zeichen, die benutzt werden können.

Eine der größten Sünden sind allerdings Passwörter, die aus dem sozialen und privaten Umfeld des Nutzers erraten werden können. Etwa die Namen oder Geburtstage von guten Freunden oder Familienangehörigen.

Einen schönen Tag noch
 Martin

[Gunnar Bittersmann]

@@Der Martin

Es sind keine Fehler des Nutzers, sondern Fehler des Entwicklers, des Produktmanagers, des Designers. Von Passwörtern zu verlangen, sie müssten Zeichen aus bestimmten Zeichenklassen enthalten ist – Entschuldigung für mein Französisch – völliger bullshit.

naja, das stimmt so nicht ganz.

Doch, was ich sagte stimmt schon. Was du ausführst

Die Sicherheit eines Passworts hängt von mehreren Faktoren ab. […] Hier hilft nur Länge und eine möglichst große Menge von Zeichen, die benutzt werden können.

widerspricht dem von mir Gesagtem nicht. Ich wollte ja nicht die Menge von Zeichen einschränken, die benutzt werden können.

Ein Passwort aus 20 Kleinbuchstaben ist immer noch sicherer als eins aus 8 Zeichen mit Groß- und Kleinbuchstaben, Ziffern und u.a. Zeichen. Bspw. ein Satz, den sich der Nutzer leicht merken kann. Und wenn der Satz in CamelCase geschrieben wird, sind auch Großbuchstaben dabei.

Eine der größten Sünden sind allerdings Passwörter, die aus dem sozialen und privaten Umfeld des Nutzers erraten werden können.

Das trifft natürlich auch auf ganze Sätze zu.

🖖 Живіть довго і процвітайте

[borisbaer]

Hallo Gunnar,

Da kann ich helfen: .+. Man sollte alles erlauben. Die Nutzer wissen am besten, wie sie heißen.

Das heißt: man braucht keinen RegExp. Und auch gar keine Prüfung (außer ob überhaupt was eingegeben wurde).

prinzipiell hast du ja recht, ist wohl eher eine Geschmackssache des Website-Betreibers. Auch wenn Benutzername wie aaaaaaaaaaaa nicht so toll sind, vor allem wenn ein anderer Benutzer aaaaaaaaaaaaa heißt. Aber ich verstehe deinen Punkt.

Gut ist es nicht. Wofür steht e? Element? Event? Irgendwas anderes? Man muss überlegen.

Benenne Variablen sinnvoll: event.

Best I can do is ev. Aber mal im Ernst: e wird doch allenthalben als Abkürzung für Event benutzt. Also, ich denke da immer sofort an Event.

Bei Eingaben und beim Verlassen des Eingabefelds feuern verschiedene Events; kannste dir in diesem Codepen ansehen.

Danke für die Veranschaulichung! Aber wenn ich eine Funktion auf oninput feuere, dann müsste das ja in Ordnung sein, nicht? Dann kann ich mir das onkeydown sparen.

Nein! Davon sollte man nicht mehrere Fehlermeldungen anzeigen, sondern exakt 0 (in Worten: null).

Es sind keine Fehler des Nutzers, sondern Fehler des Entwicklers, des Produktmanagers, des Designers. Von Passwörtern zu verlangen, sie müssten Zeichen aus bestimmten Zeichenklassen enthalten ist – Entschuldigung für mein Französisch – völliger bullshit. Das war’s auch vor 8 Jahren schon.

Da bin ich wohl einfach blindlings der Konvention gefolgt

Was man machen kann: die Sicherheit eines Passworts prüfen und – je nach Anwendung – zumindest mittlere Sicherheit verlangen.

Alternativ eine Passwort-Stärke einzufordern, wie es unter deinem Link gemacht wird, ist sicher die bessere Vorgehensweise. Aber kann man dieses Ding so einfach nachbauen?

Vielen Dank für die Hinweise!

Boris

[Raketenwilli]

Aber mal im Ernst: e wird doch allenthalben als Abkürzung für Event benutzt. Also, ich denke da immer sofort an Event.

Ach. Und gar nicht an „Error“?

[Tabellenkalk]

Hallo,

Aber mal im Ernst: e wird doch allenthalben als Abkürzung für Event benutzt. Also, ich denke da immer sofort an Event.

Ach. Und gar nicht an „Error“?

Also ich denk da immer an(s) Essen…

Gruß
Kalk

[Der Martin]

Hi,

Aber mal im Ernst: e wird doch allenthalben als Abkürzung für Event benutzt. Also, ich denke da immer sofort an Event.

Ach. Und gar nicht an „Error“?

Oder Element. Oder Exception.

Also ich denk da immer an(s) Essen…

Jaja, was sagte der Herrgott, als er das Ruhrgebiet erschaffen hatte? - Essen ist fertig!

Einen schönen Tag noch
 Martin

[Gunnar Bittersmann]

@@borisbaer

Best I can do is ev.

Evangelisch?

Aber mal im Ernst: e wird doch allenthalben als Abkürzung für Event benutzt. Also, ich denke da immer sofort an Event.

Code ist meist nicht nur für dich, sondern auch für andere. Ich sehe keinen Sinn darin, kryptische Variablennamen zu verwenden. Don’t make me think!

Danke für die Veranschaulichung! Aber wenn ich eine Funktion auf oninput feuere, dann müsste das ja in Ordnung sein, nicht? Dann kann ich mir das onkeydown sparen.

Ja. keydown ist sowieso falsch, da es von der falschen Voraussetzung ausgeht, Nutzer würden das Eingabefeld ausschließlich per Tastatureingabe füllen. input feuert auch beim Reinziehen von Drag and Drop mit der Maus, bei Spracheingabe, …

BTW, JavaScript-Eventnamen fangen nicht mit on… an. Das tun die entsprechenden HTML-Attribute; aber die sollte man möglichst meiden.

Von Passwörtern zu verlangen, sie müssten Zeichen aus bestimmten Zeichenklassen enthalten ist – Entschuldigung für mein Französisch – völliger bullshit. Das war’s auch vor 8 Jahren schon.

Da bin ich wohl einfach blindlings der Konvention gefolgt

Million Fliegen können nicht irren: Scheiße schmeckt gut. 💩🪰🪰🪰

Was man machen kann: die Sicherheit eines Passworts prüfen und – je nach Anwendung – zumindest mittlere Sicherheit verlangen.

Alternativ eine Passwort-Stärke einzufordern, wie es unter deinem Link gemacht wird, ist sicher die bessere Vorgehensweise. Aber kann man dieses Ding so einfach nachbauen?

Nicht nachbauen. Etwas Fertiges (und Geprüftes!) verwenden. Der Codepen bindet zxcvbn von https://cdnjs.cloudflare.com/ajax/libs/zxcvbn/4.4.2/zxcvbn.js ein. Das sollte man bei eigenen Projekten besser selbst hosten.

🖖 Живіть довго і процвітайте

[Raketenwilli]

Code ist meist nicht nur für dich,

Und selbst wenn.

Ich würde mir, so denn überhaupt verfügbar, nicht unbedingt zutrauen, meine alten BASIC-Skripte zu lesen. Da fehlt ganz entschieden die Kladde, ich der ich notiert hatte, was die „anno 16KB-RAM-Rechner“ notgedrungen zweibuchstabigen Variablennamen wohl bedeuten… bzw. was diese beeinhalten.

[Gunnar Bittersmann]

@@Raketenwilli

Code ist meist nicht nur für dich,

Und selbst wenn.

Ich würde mir, so denn überhaupt verfügbar, nicht unbedingt zutrauen, meine alten BASIC-Skripte zu lesen. Da fehlt ganz entschieden die Kladde, ich der ich notiert hatte, was die „anno 16KB-RAM-Rechner“ notgedrungen zweibuchstabigen Variablennamen wohl bedeuten… bzw. was diese beeinhalten.

Sowohl das Ich aus der Vergangenheit als auch das Ich aus der Zukunft sind Fremde.

🖖 Живіть довго і процвітайте

[Der Martin]

Hallo,

Ich würde mir, so denn überhaupt verfügbar, nicht unbedingt zutrauen, meine alten BASIC-Skripte zu lesen. Da fehlt ganz entschieden die Kladde, ich der ich notiert hatte, was die „anno 16KB-RAM-Rechner“ notgedrungen zweibuchstabigen Variablennamen wohl bedeuten… bzw. was diese beeinhalten.

das ist dann aber der damaligen BASIC-Implementierung und den insgesamt sehr beschränkten Ressourcen der damaligen Computer geschuldet. Obwohl gerade der C64 zum Zeitpunkt seiner Markteinführung bahnbrechend war. Ganze 64k RAM (davon 38k für BASIC verfügbar), Grafik- und Soundchips mit bis dato ungeahnten Möglichkeiten.
Okay, wenig später kamen dann Geräte wie der Atari ST oder der Amiga, die das alles wieder in den Schatten stellten. Aber das ist ja normal. Fortschritt eben.

Wenn ich aber heute ein altes Projekt wieder rauskrame, das ich vor, sagen wir, 20 Jahren programmiert habe, kann ich meinen eigenen C-Code fast sofort wieder wie Prosa lesen und bin innerhalb kurzer Zeit wieder "drin". Das liegt einerseits daran, dass ich schon sehr früh angefangen habe, sprechende Bezeichner zu verwenden und klar erkennbare, mehr oder weniger in sich geschlossene Blöcke zu formulieren. Und ich habe schon immer sozusagen am rechten Bildschirmrand ausführlich kommentiert, so dass auch ein Fremder direkt mitlesen kann, was ich mir da gedacht habe und wie es funktioniert.

Das hat mir vor etwa 3 Jahren ein Kollege bestätigt, der sich interessehalber ein C-Projekt von mir angeschaut hat, das ich um 2000 begonnen und im Abstand von ein paar Jahren immer mal wieder ergänzt oder erweitert habe.

Einen schönen Tag noch
 Martin

[borisbaer]

BTW, JavaScript-Eventnamen fangen nicht mit on… an. Das tun die entsprechenden HTML-Attribute; aber die sollte man möglichst meiden.

Hat das mit on irgendwelche Nachteile?

Million Fliegen können nicht irren: Scheiße schmeckt gut. 💩🪰🪰🪰

Für Fliegen stimmt das aber doch.

Nicht nachbauen. Etwas Fertiges (und Geprüftes!) verwenden. Der Codepen bindet zxcvbn von https://cdnjs.cloudflare.com/ajax/libs/zxcvbn/4.4.2/zxcvbn.js ein. Das sollte man bei eigenen Projekten besser selbst hosten.

Gut zu wissen, danke!

[Gunnar Bittersmann]

@@borisbaer

BTW, JavaScript-Eventnamen fangen nicht mit on… an. Das tun die entsprechenden HTML-Attribute; aber die sollte man möglichst meiden.

Hat das mit on irgendwelche Nachteile?

Separation of concerns. Himmel und Hölle:

(aus: CSS preprocessors for the best of both worlds)

Im HTML-Code stehen der Inhalt und dessen Struktur. Im JavaScript-Code steht dynamisches Verhalten der Webseite. Genau dort sollten die Eventhandler angegeben werden.

🖖 Живіть довго і процвітайте

[Raketenwilli]

Das Du die Daten auf dem Server nochmals verifizieren musst ist klar.

Aber warum willst Du etwas mit Javascript „stricken“, was anno 2022 der Browser ohnehin schon kann? Schau doch mal die Attribute für Inputs durch:

https://wiki.selfhtml.org/wiki/HTML/Elemente/input

Wenn Du vereinfachte oder aussagekräftigere Fehlermeldungen (z.B. bei Inputs mit einen zu erfüllenden Regex) willst, dann schau hier nach:

https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/invalid_event

Das gilt insbesondere, weil Du ja (soweit ich mich erinnere) an einem „Framework“ für diese Formulardaten arbeitest. Ich hatte (wohl) Dir auf den Weg gegeben, dass Du dann also auch das Formular aus dem Objekt heraus erzeugen kannst. Und, naja: Warum also nicht auch die individuellen Fehlermeldungen? Für die gibt es schlicht und einfach keine einfach umsetzbaren Regeln, denn die sind sachlich immer vom konkreten Input abhängig.

---

Dann wäre da noch was. Ich hab mal in Dein Profil geschaut. Du wertest sehr oft Deine Antworten in von Dir eröffnten Threads à la „Jo. Dieser oder jener Tipp hat funktioniert.“ als „akzeptierte Antwort“. Der Haken ist aber dafür, Beiträge zu markieren, welche Dir die Lösung oder den Weg zur Lösung gezeigt haben und soll allenfalls im Ausnahmefall für eigene Beiträge genutzt werden - nämlich wenn man selbst darauf kam.

Ein gewisser, aktuell in den IT- und Wirtschaftsnachrichten omnipräsenter Elon tut sowas, klar. Aber irgendwie beschämst Du damit diejenigen, welche Dir geholfen haben.

[borisbaer]

Aber warum willst Du etwas mit Javascript „stricken“, was anno 2022 der Browser ohnehin schon kann? Schau doch mal die Attribute für Inputs durch:

https://wiki.selfhtml.org/wiki/HTML/Elemente/input

Nun ja, wohl unter falschen Prämissen angefangen zu arbeiten. Ich kenne halt die Formular-Felder, die so gestrickt sind, dass da z.B. steht, der Benutzername muss die und die Anforderung erfüllen. Das habe ich aufgeschnappt bzw. gehen auch viele Tutorial zu dem Thema so vor.

Wenn Du vereinfachte oder aussagekräftigere Fehlermeldungen (z.B. bei Inputs mit einen zu erfüllenden Regex) willst, dann schau hier nach:

https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/invalid_event

Jo. Dieser Tipp funktioniert! Zumindest, wenn man es nicht so haben will, dass der Benutzer quasi Live-Feedback bei jedem Tastenschlag erhält. Wie gesagt, ich habe unter bestimmten Prämissen angefangen zu arbeiten. Nächstes Mal frage ich vorher nach.

Das gilt insbesondere, weil Du ja (soweit ich mich erinnere) an einem „Framework“ für diese Formulardaten arbeitest. Ich hatte (wohl) Dir auf den Weg gegeben, dass Du dann also auch das Formular aus dem Objekt heraus erzeugen kannst.

Wie meinen? Das Formular aus Objekten zusammenzusetzen?

Und, naja: Warum also nicht auch die individuellen Fehlermeldungen? Für die gibt es schlicht und einfach keine einfach umsetzbaren Regeln, denn die sind sachlich immer vom konkreten Input abhängig.

Ich verstehe nicht ganz, was du damit meinst. Ja, ich generiere in der Model- und Controller-Klasse die individuellen Fehlermeldungen. Aber das gilt nur für PHP.

---

Dann wäre da noch was. Ich hab mal in Dein Profil geschaut. Du wertest sehr oft Deine Antworten in von Dir eröffnten Threads à la „Jo. Dieser oder jener Tipp hat funktioniert.“ als „akzeptierte Antwort“. Der Haken ist aber dafür, Beiträge zu markieren, welche Dir die Lösung oder den Weg zur Lösung gezeigt hat und soll allenfalls im Ausnahmefall für eigene Beiträge genutzt werden - nämlich wenn man selbst darauf kam.

Ein gewisser, aktuell in den IT- und Wirtschaftsnachrichten omnipräsenter Elon tut sowas, klar. Aber irgendwie beschämst Du damit diejenigen, welche Dir geholfen haben.

Danke für den Hinweis. Sollte ganz sicher nicht so verstanden werden. Ist schlicht Unwissenheit gewesen. In Zukunft markiere ich anders!

[Raketenwilli]

Nun ja, wohl unter falschen Prämissen angefangen zu arbeiten. Ich kenne halt die Formular-Felder, die so gestrickt sind, dass da z.B. steht, der Benutzername muss die und die Anforderung erfüllen. Das habe ich aufgeschnappt bzw. gehen auch viele Tutorial zu dem Thema so vor.

Tipps vom Trainer:

1. Tutorials sind das eine, Handbücher das andere.
2. Youtube-Zeug ist oft ganz krass, weil die Youtuber auch nur andere, alte schriftliche Tutorials nachstellen und faktisch nie auf Nebenbedingungen oder Nebenwirkungen eingehen. Und eigene „Blitzideen“ päsentieren. Vom Blitz getroffen zu werden ist aber „Scheiße“.
3. Bei allen Arten von scheinbaren Poblemlösungsrezepten: eigenes Hirn benutzen, hinterfragen, ob es das sein kann, immer auf das Datum achten…

[Auge]

Hallo

Tipps vom Trainer:

1. Tutorials sind das eine, Handbücher das andere.
2. Youtube-Zeug ist oft ganz krass, weil die Youtuber auch nur andere, alte schriftliche Tutorials nachstellen und faktisch nie auf Nebenbedingungen oder Nebenwirkungen eingehen. Und eigene „Blitzideen“ päsentieren. Vom Blitz getroffen zu werden ist aber „Scheiße“.
3. Bei allen Arten von scheinbaren Poblemlösungsrezepten: eigenes Hirn benutzen, hinterfragen, ob es das sein kann, immer auf das Datum achten…

Keine Widerrede von mir, nur eine persönliche Umsortierungsempfehlung. Ich würde den Punkt drei auf die Position eins setzen. Mit dem Altersfilter für Tutorials kann man, zumindest bei dauerhaft gepflegter Software, schon mal alle mutmaßlich veralteten Anleitungen aus dem Aufmerksamkeitsbereich aussortieren. Danach erst folgen für mich die Punkte eins und zwei der Trainerempfehlung (in ihrer natürlichen Reihenfolge).

Tschö, Auge

[Raketenwilli]

Wie meinen? Das Formular aus Objekten zusammenzusetzen?

Du hattest doch Deine Klasse bzw. Dein Objekt für die Validierung der Daten.

Da wird genau einmal der Regex, z.B. für den Benutzername fest gelegt.

Dann baust Du einen „getter“, welcher genau das HTML für das Formulfeld zurück gibt.

also etwa

public function getInput( $id=false ) {
  if( $id and ! empty( $this->inputs[$id] ) ) {
    return '<input'
           . ' id="'          . $this->inputs[$id]['HtmlId'] . '"'
           . ' name="'        . $this->inputs[$id]['HtmlId'] . '"'
           . ' pattern="'     . $this->inputs[$id]['pattern'] . '"'
           . ' placeholder="' . $this->inputs[$id]['placeholder'] . '"'
           . ' />';
   } else {
       trigger_error(
        'Versuch, ein Input zu erzeugen, welches nicht konfiguriert ist',
        E_USER_ERROR
       );
       return false;
   }

(In Wahrheit wird es komplizierter), z.b. wenn Du auch noch einen anderen Typ (type="number", dann wöglich auch min, max, ste) beachten willst.

Und wenn die Daten via POST wieder ankommen, dann erzeugst Du ein Objekt der gleichen Klasse mit gleichen Eigenschaften und steigst mittels einer anderen Methode in die Prüfung ein, ziehst Dir anhand der ID das Pattern und gibst true oder false zurück...

Vorteil: Du kannst alle erforderlichen oder von Dir als erforderlich angesehenen Limits zentral an einer Stelle notieren.

Vorteil: Du kannst bei einem Fehlschlag der Prüfung gleich das Forumular neu erzeugen.

[Rolf B]

Hallo Raketenwilli,

Dann baust Du einen „getter“, welcher genau das HTML für das Formulfeld zurück gibt.

Zu beachten ist bei sowas, dass man (a) Datenhaltung von HTML Generierung getrennt halten sollte und (b) ein solcher HTML Generator auch vorbelegte Felder erzeugen können muss (Stichwort "Affenformular").

Vorbelegung funktioniert je Eingabewidget anders, d.h. ein "getInput" ist mit value vorzubelegen und ein "getSelect" mit der Präselektion der option oder ein getRadio mit dem Prächeck eines Radiobuttons.

Dein Getter erzeugt nur leere Felder. Ein OO Ansatz sollte aber einem Controller die Möglichkeit bieten, aus View-Template und Model einen ausgefüllten View zu erzeugen und dann zu rendern.

Ein Getter für select muss die ganze Select-Gruppe mit den Options erzeugen; ein Getter für radio eine Radiogruppe. Ein Getter für input sollte die Option haben, eine datalist zu ergänzen.

Es wäre auch hilfreich, das Label-Element gleich mit zu erzeugen. Eine standardisierte Form-Generierung sollte keine unterschiedlichen HTML Konstrukte für Label und Eingabeelement haben. Find ich.

Im Endeffekt wird das alles sehr schnell sehr komplex, und ehe man es sich versieht hat man sowas wie ASP.PHP…

Rolf

[Raketenwilli]

Ich habe gerade mal ein altes Projekt verwirklicht:

Zwei Listen

• bekannt oft verwendeter Passwörter aus Cracks
• deutscher, österreichischer, schweizerischer Wörter aus diversen Wörterbüchern
• sortiert, alles Kleinbuchstaben
• Mindestlängen von 6 oder 8 Zeichen
• ca. 2 Mio Einträge

https://code.fastix.org/Projekte/Passwort-Cracklist/

Hint:

Die Listen sind ausgepackt (jeweils) über 30 MB groß. Ich würde nicht versuchen, den Abgleich im Browser zu machen, sondern serverseitig eine Datenbank bemühen, denn die Datenbänker haben viel Hirnschmalz für die Indizierung verwendet...

Die Anleitung, um mit verketteten Unix-Befehlen ebensolche Listen nach Hinzufügen weiterer Wortlisten zu erstellen, ist dabei.

[borisbaer]

Vielen Dank für die Listen! 👍

Die Listen sind ausgepackt (jeweils) über 30 MB groß. Ich würde nicht versuchen, den Abgleich im Browser zu machen, sondern serverseitig eine Datenbank bemühen, denn die Datenbänker haben viel Hirnschmalz für die Indizierung verwendet...

Leider sind da meine Datenbank-Kenntnisse noch unzureichend, denn ich weiß nicht, wie man solche Listen dort einpflegt.

Die Anleitung, um mit verketteten Unix-Befehlen ebensolche Listen nach Hinzufügen weiterer Wortlisten zu erstellen, ist dabei.

Genau die werde ich mir bei Gelegenheit durchlesen! Ich hoffe, ich komme zurecht. 🤯

[Raketenwilli]

Leider sind da meine Datenbank-Kenntnisse noch unzureichend, denn ich weiß nicht, wie man solche Listen dort einpflegt.

Hm, je nach verwendetem Datenbankserver sieht das dann so aus:

Anlegen der puren Tabelle:

CREATE TABLE `cracklist` (
    `words`   VARCHAR(255) NOT NULL,
    `reverse` VARCHAR(255)
);

Einlesen der Daten als einspaltiges CSV:

LOAD DATA INFILE 'cracklist.txt' 
INTO TABLE `cracklist`
LINES TERMINATED BY '\n'
;

ggf.(!) Erzeugen der Daten für Reverse-LIKE, Nützlich, wenn geprüft werden soll, ob ein Passwort der Beginn oder das Ende eines bekannten Wortes sein soll - denn 'LIKE '%ABC' kann den Index nicht nutzen, aber LIKE 'CBA%' kann es. Ohne die Nutzung des Index wird die Abfrage dauern, erwärmt aber auf jeden Fall sinnlos die Erde.

UPDATE `cracklist`
SET `reverse`=REVERSE(`words`)

Erzeugen des Index:

CREATE INDEX `words`
ON `cracklist` ( `words`, `reverse` );

Ach so. Die Dateien habe ich mit gzip gepackt. Das Entpacken auf dem Server mit gzip -d datei.txt.gz resultiert im Verschwinden der gepackten Datei und Erscheinen der ausgepackten Datei „datei.txt“.