nicht angemeldet
Datenkonsistenzprüfung beim Verlassen eines input-feldes
Hallo,
ich habe eine Javascript Funktion, die beim Verlassen eines Input-Feldes prüft, ob eine Zahl eingegeben wurde. Falls nicht, wird eine Alert-Message angezeigt und das betroffene Inputfeld wird wieder selektiert. Somit ist es nicht möglich, das Feld zu verlassen ohne eine gültige Eingabe zu machen.
Der dafür zuständige Code der Funktion lautet:
function isNumber(inputField, alertMsg)
{
[...Zusätzliche Überprüfungen ...]
if((inputField.value == '') || !isNaN(inputField.value))
{
return true;
}
else
{
alert(alertMsg);
try
{
inputField.focus();
inputField.select();
}
catch (e) {}
return false;
}
}
Das funktioniert unter Internet Explorer perfekt, im Mozilla Firefox jedoch bleibt der Benutzer nicht im betroffenen Feld, sondern kann heraus navigieren. Meine erste Vermutung war, dass es an einer unterschiedlichen Reihenfolge der Events (onChange, onBlur, etc ...) liegt, konnte aber nichts diesbezügliches finden.
Hat von euch jemand eine Idee?
Danke
Thomas
-
yo,
Somit ist es nicht möglich, das Feld zu verlassen ohne eine gültige Eingabe zu machen.
zu deinem javascript problem kann ich nicht viel sagen, glaube aber alert kann unter FF nicht ausgeführt werden. worauf ich aber hinweisen wollte ist, dass sehr wohl auch mit dem IE felder ohne gültige abgabe abgeschickt werden können. deswegen muss du auch serverseitig die eingaben überprüfen, falls das nicht schon längst geschehen ist.
Ilja
-
yo,
Somit ist es nicht möglich, das Feld zu verlassen ohne eine gültige Eingabe zu machen.
zu deinem javascript problem kann ich nicht viel sagen, glaube aber alert kann unter FF nicht ausgeführt werden.
Also das Alert-Popup erscheint im richtigen Fall ganz schön sowohl im IE als auch im Firefox, nur der Focus stimmt im Firefox nicht.
worauf ich aber hinweisen wollte ist, dass sehr wohl auch mit dem IE felder ohne gültige abgabe abgeschickt werden können. deswegen muss du auch serverseitig die eingaben überprüfen, falls das nicht schon längst geschehen ist.
Theoretisch kann der Benutzer auch im IE was falsches eingeben, praktisch nicht weil er einfach aus dem Inputfeld nicht rauskommt und somit den Speicher-Button nicht bedienen kann.
Aber auch auf Datenbankseite findet eine weitere Kontrolle statt, schon alleine weil Javascript und HMTL nicht wirklich zur gewährleistung von Datenkonsistenz erfunden wurden. Aber wir möchten dem Benutzer ein unnützes Absenden von Daten wenn möglich ersparen, daher auch die Kontrolle auf Oberflächenseite.
Ilja
lg
Thomas
-
Moin!
Theoretisch kann der Benutzer auch im IE was falsches eingeben, praktisch nicht weil er einfach aus dem Inputfeld nicht rauskommt und somit den Speicher-Button nicht bedienen kann.
Nichts ist nerviger, als wenn man als Benutzer nicht tun kann, was man will.
Nehmen wir nur mal an, der Benutzer kennt die auszufüllende Zahl gerade noch nicht, gibt erstmal "xxx" ein, um später nochmal drauf zurückzukommen - und kommt dann keinen Schritt mehr weiter, sondern wird festgehalten.
Extrem nervig könnte das sein.
Zumal er "dank" des Alert-Hinweises dann auch noch ganz woanders mit der Maus auf OK klicken muß, um die Eingabe dem Programmiererwunsch anzupassen.
Aber wir möchten dem Benutzer ein unnützes Absenden von Daten wenn möglich ersparen, daher auch die Kontrolle auf Oberflächenseite.
Wo ist da das Problem? Wenn der Benutzer keine Zahl eingeben will, wird man ihn durch Zwang nur dazu bringen können, irgendeine Zahl einzugeben. Ihn in seinem Arbeitsfluß zu unterbrechen, zu zwingen, das eben eingegebene Feld nochmal neu auszufüllen, obwohl er gedanklich schon einen Schritt weiter ist, halte ich eigentlich für sehr ungeschickt.
Der Benutzer ist für echte Fehlermeldungen, die ihm präsentiert werden, beim Abschicken (onsubmit) oder beim Betrachten der Ergebnisseite (mit Neuvorlage des Formulars und deutlich markierten Fehlerfeldern) am aufmerksamsten für Korrekturen.
Während der Eingabe hingegen stört das nach meinem Empfinden mehr, als dass es hilft.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Moin!
Theoretisch kann der Benutzer auch im IE was falsches eingeben, praktisch nicht weil er einfach aus dem Inputfeld nicht rauskommt und somit den Speicher-Button nicht bedienen kann.
Nichts ist nerviger, als wenn man als Benutzer nicht tun kann, was man will.
Seh ich nicht so. Das letzte Projektmeeting kann halt nicht am 44.13.2005 stattgefunden haben
Nehmen wir nur mal an, der Benutzer kennt die auszufüllende Zahl gerade noch nicht, gibt erstmal "xxx" ein, um später nochmal drauf zurückzukommen - und kommt dann keinen Schritt mehr weiter, sondern wird festgehalten.
Extrem nervig könnte das sein.
Dann kann er das Feld frei lassen oder 0 eingeben. Wie soll denn das System erkennen können, ob er eine unbewusste Fehlangabe gemacht hat, die Eingabe vergessen hat oder später angeben will?
Zumal er "dank" des Alert-Hinweises dann auch noch ganz woanders mit der Maus auf OK klicken muß, um die Eingabe dem Programmiererwunsch anzupassen.
Dann merkt er zumindest das etwas nicht passt.
Aber wir möchten dem Benutzer ein unnützes Absenden von Daten wenn möglich ersparen, daher auch die Kontrolle auf Oberflächenseite.
Wo ist da das Problem? Wenn der Benutzer keine Zahl eingeben will, wird man ihn durch Zwang nur dazu bringen können, irgendeine Zahl einzugeben.
Wenn es kein Pflichtfeld ist kann er ja auch keine Zahl eingeben. Nur wenn es ein Pflichtfeld ist muss er halt etwas angeben. Und die geplanten Kosten einer PRojektphase können nun mal nicht "viel" oder "wenig" sein, da sind nun mal Zahlen gefragt.
Der Benutzer ist für echte Fehlermeldungen, die ihm präsentiert werden, beim Abschicken (onsubmit) oder beim Betrachten der Ergebnisseite (mit Neuvorlage des Formulars und deutlich markierten Fehlerfeldern) am aufmerksamsten für Korrekturen.
Gibt sicher solche und solche. Mit persönlich ist eine eldung gleich bei der EIngabe am liebsten, dann vertue ich am wenigsten zeit. Weil dann gibt es noch irgendein Problem beim wieder laden der breits eingegeben Werte und ich darf alles nochmals eingeben. Auch nicht toll ...
Während der Eingabe hingegen stört das nach meinem Empfinden mehr, als dass es hilft.
Siehe oben: Gibt solche und solche. Und wenn der Kunde damit zufrieden ist: passt doch :-)
- Sven Rautenberg
lg
ThomasPS.: Eben aufgefallen: Ganz schlecht find ich da die Lösung in diesem Forum: Man klickt auf absenden und es passiert nix außer dass man nach ganz oben springt. Keine Meldung was denn fehlt oder ob überhaupt was fehlt ....
-
Moin!
PS.: Eben aufgefallen: Ganz schlecht find ich da die Lösung in diesem Forum: Man klickt auf absenden und es passiert nix außer dass man nach ganz oben springt. Keine Meldung was denn fehlt oder ob überhaupt was fehlt ....
Kann ich nicht bestätigen. Man erhält eine Meldung.
Oder wir reden von zwei unterschiedlichen Phänomenen.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Moin!
PS.: Eben aufgefallen: Ganz schlecht find ich da die Lösung in diesem Forum: Man klickt auf absenden und es passiert nix außer dass man nach ganz oben springt. Keine Meldung was denn fehlt oder ob überhaupt was fehlt ....
Kann ich nicht bestätigen. Man erhält eine Meldung.
Oder wir reden von zwei unterschiedlichen Phänomenen.
Also ich rede davon, dass man eine antwort eintippt und dann auf "Nachricht absenden" klickt, ohne Name und Mailadresse angegeben zu haben, bzw. den "ich habe die Charte gelesen" button anzuklicken.
Vielleicht aber ist die Meldung auch nur so klein, dass ich sie übersehe.
- Sven Rautenberg
PS.: hab nun auch das erset Mal eien Antwort nciht mit Firefox sondern mit IE erstellt, bekomme auch da keinerlei Hinweis ...
-
-
Hallo.
Das letzte Projektmeeting kann halt nicht am 44.13.2005 stattgefunden haben
Aber "letzten Donnerstag".
MfG, at
-
-
yo,
Theoretisch kann der Benutzer auch im IE was falsches eingeben, praktisch nicht weil er einfach aus dem Inputfeld nicht rauskommt und somit den Speicher-Button nicht bedienen kann.
das ist ein trugschluss zu glauben, der user wäre gezwungen, das formular auch so abzuschicken, wie es angedacht ist.
Aber auch auf Datenbankseite findet eine weitere Kontrolle statt, schon alleine weil Javascript und HMTL nicht wirklich zur gewährleistung von Datenkonsistenz erfunden wurden.
sicherlich sollte die datenbank soviel wie möglich abfangen. aber in dem falle wäre es besser, wenn fehlerhafte daten schon vor der datenbank durch eine serverseitige technik abgefangen wir. besteht eigentlich kein grund, das dbms unnötig zu beschäftigen.
Aber wir möchten dem Benutzer ein unnützes Absenden von Daten wenn möglich ersparen, daher auch die Kontrolle auf Oberflächenseite.
nichts dagegenen zu sagen, nur eben das man sich bewußt sein soll, dass eine prüfung auf client seite nicht ausreicht und man davon ausgehen muss, dass alle diese kontrollen auch leicht umgangen werden können.
Ilja
-
yo,
Theoretisch kann der Benutzer auch im IE was falsches eingeben, praktisch nicht weil er einfach aus dem Inputfeld nicht rauskommt und somit den Speicher-Button nicht bedienen kann.
das ist ein trugschluss zu glauben, der user wäre gezwungen, das formular auch so abzuschicken, wie es angedacht ist.
Eh nicht, es gibt immer Lücken, aber es kann schon ein sehr großer Prozentsatz der normalen Benutezr an dieser Stelle abgedeckt werden. Natürlich kann es immer Denkfehler in der Umsetzung unf Fehler im Code geben die es dem Benutzer ermöglichen was anderes abzuschicken. Und einen Proxy dazwischen hängen und die Daten vor dem Absenden einfach direkt noch mal zu ändern, das geht ja auch immer.
Aber auch auf Datenbankseite findet eine weitere Kontrolle statt, schon alleine weil Javascript und HMTL nicht wirklich zur gewährleistung von Datenkonsistenz erfunden wurden.
sicherlich sollte die datenbank soviel wie möglich abfangen. aber in dem falle wäre es besser, wenn fehlerhafte daten schon vor der datenbank durch eine serverseitige technik abgefangen wir. besteht eigentlich kein grund, das dbms unnötig zu beschäftigen.
Womit wäre das möglich? Und worin besteht der Vorteil es der DBMS nicht anzulasten? Das weniger an notwendiger Leistung dort brauch ich dann ja ahlt woanders, oder? (Kenn mich da nicht so echt aus und bin für jeden Tipp dankbar)
[...}
Ilja
lg
Thomas
-
-
-
-
Hallo Thomas!
ich habe eine Javascript Funktion, die beim Verlassen eines Input-Feldes prüft, ob eine Zahl eingegeben wurde. Falls nicht, wird eine Alert-Message angezeigt und das betroffene Inputfeld wird wieder selektiert. Somit ist es nicht möglich, das Feld zu verlassen ohne eine gültige Eingabe zu machen.
function isNumber(inputField, alertMsg)
{[...Zusätzliche Überprüfungen ...]
if((inputField.value == '') || !isNaN(inputField.value))
{
return true;
}
else
{
alert(alertMsg);
try
{
inputField.focus();
inputField.select();
}
catch (e) {}
return false;
}
}
Das funktioniert unter Internet Explorer perfektDas wundert mich.
if(inputField.value == '') return true
Akzeptiert doch, dass keine Zahl eingegeben wurde.if(!isNaN(inputField.value)) return true
Akzeptiert doch auch, dass keine Zahl eingegeben wurde.Viele Grüße
H-P Ortner
-
Hallo Thomas!
ich habe eine Javascript Funktion, die beim Verlassen eines Input-Feldes prüft, ob eine Zahl eingegeben wurde. Falls nicht, wird eine Alert-Message angezeigt und das betroffene Inputfeld wird wieder selektiert. Somit ist es nicht möglich, das Feld zu verlassen ohne eine gültige Eingabe zu machen.
function isNumber(inputField, alertMsg)
{[...Zusätzliche Überprüfungen ...]
if((inputField.value == '') || !isNaN(inputField.value))
{
return true;
}
else
{
alert(alertMsg);
try
{
inputField.focus();
inputField.select();
}
catch (e) {}
return false;
}
}
Das funktioniert unter Internet Explorer perfektDas wundert mich.
if(inputField.value == '') return true
Akzeptiert doch, dass keine Zahl eingegeben wurde.Es handelt sich um kein Pflichtfeld, somit ist ein Leer-String auch akzeptabel. Wird das Feld als Pflichtfeld definiert greift eine andere Abfrage (die Pflichtfeldkontrolle eben).
if(!isNaN(inputField.value)) return true
Akzeptiert doch auch, dass keine Zahl eingegeben wurde.isNaN gibt true zurück falls es sich um keine Zahl handelt. und false, falls es sich um eine Zahl handelt. Darum die Verneinung, weil ich möchte ja quasi true zurück bekommen wenn es eine Zahl ist.
Viele Grüße
lg
H-P Ortner
Thomas
-
-
Hallo,
das scheint eine generelle Sperre zu sein, um JavaScript-Missbrauch zu verhindern: Im blur-Handler kann man nicht die focus-Methode des Elements aufrufen, bei der der blur-Event passierte. Eigentlich logisch.
Du kannst das, wenn du unbedingt willst, umgehen, indem du focus etwas verzögert aufrufst. Gecko fällt der Zusammenhang zwischen blur und focus dann nicht mehr auf:
function onload () { document.getElementById("feld1").onblur = test; } function test () { if (this.value != '' || isNaN(this.value)) { this.onblur = null; alert("Fehler!"); var elem = this; window.setTimeout(function () { elem.focus(); elem.select(); elem.onblur = test; }, 1); } }<form action=""> <input type="text" name="feld1" id="feld1"> <input type="text" name="feld2"> </form>Ob das so klug ist, ist natürlich zu bezweifeln. Ich würde die Formularüberprüfung nicht beim blur durchführen bzw. keinen automatischen focus() durchführen.
Mathias
-
Hallo,
das scheint eine generelle Sperre zu sein, um JavaScript-Missbrauch zu verhindern: Im blur-Handler kann man nicht die focus-Methode des Elements aufrufen, bei der der blur-Event passierte. Eigentlich logisch.
Scheint dann aber nur im Firefox der Fall zu sein, im IE gehts ja (was ja nichts heißen mag). Aber warum bitte ist es ein Sicherheitsmanko ein bestimmtes Feld fokusieren zu können? Damit alleine kann ich ja nicht wirklich was kaputt machen.
Du kannst das, wenn du unbedingt willst, umgehen, indem du focus etwas verzögert aufrufst. Gecko fällt der Zusammenhang zwischen blur und focus dann nicht mehr auf:
[... Viel Code ...]
Ob das so klug ist, ist natürlich zu bezweifeln. Ich würde die Formularüberprüfung nicht beim blur durchführen bzw. keinen automatischen focus() durchführen.
Wie würdest du es dann machen? Die zweite große Möglichkeit wäre natürlich erst beim Senden zu sagen: 1) In Feld xy bitte eine Zahl, 2) In feld yx bitte ein Datum im Format DD.MM.YYYY und in Feld 3) bitte einen kommentar mit mindestens 10 Zeichen.
Oder würdest du es auf einem anderen Event machen? zB On-Change?
lg und Danke, die Zeitverzögerung werde ich mal ausprobieren.
Thomas
Mathias
-
Hallo,
Hallo Mathias
Du kannst das, wenn du unbedingt willst, umgehen, indem du focus etwas verzögert aufrufst. Gecko fällt der Zusammenhang zwischen blur und focus dann nicht mehr auf:
function onload () {
document.getElementById("feld1").onblur = test;
}
function test () {
if (this.value != '' || isNaN(this.value)) {
this.onblur = null;
alert("Fehler!");
var elem = this;
window.setTimeout(function () {
elem.focus();
elem.select();
elem.onblur = test;
}, 1);
}
}> > ~~~html <form action=""> > <input type="text" name="feld1" id="feld1"> > <input type="text" name="feld2"> > </form>ich hab meinen Code jetzt nur sehr, sehr geringfügig verändert:
function isNumber(inputField, alertMsg)
{[...Zusätzliche Überprüfungen ...]
if((inputField.value == '') || !isNaN(inputField.value))
{
return true;
}
else
{
alert(alertMsg);window.setTimeout(function () {
try
{
inputField.focus();
inputField.select();
}
catch (e) {}}, 1);
return false;
}
}Das reicht schon aus damit das Ganze auch unter Firefox funktioniert. Könnten sich durch meine Abänderungen (bzw. starken vereinfachungen) irgendwelche Probleme ergeben die ich jetzt noch nicht bedacht habe, bzw. wozu das Erstellen einer neuen Kopie des Inputelements und das Löschen und wieder anlegen der onBlur-Funktion?
Mathias
Danke und liebe Grüße
Thomas
-
Yerf!
Ob das so klug ist, ist natürlich zu bezweifeln. Ich würde die Formularüberprüfung nicht beim blur durchführen bzw. keinen automatischen focus() durchführen.
Ich würde in onBlur vor allem kein Alert aufrufen... schon mal probiert, was passiert, wenn man mit einem falschen Wert im Feld einen Taskwechsel macht (also auf ein Fenster eines anderen Programmswechselt)? Zumindest bei meinen Versuchen kam da der Firefox komplett aus dem Tritt und hatte plötzlich keinen Cursor mehr für die Eingabefelder. Erst ein erfolgreicher Taskwechsel weg vom Firefox und wieder zurück hat das wieder in Ordnung gebracht. Der Fuchs mag es schienbar nicht, wenn man seinen Blur-Vorgang durch ein Alert unterbricht...
Vorschlag: mach doch kein nerviges Alert, sondern markier das Eingabefeld mit dem falschen Wert farblich.
Gruß,
Harlequin
-
Yerf!
Ob das so klug ist, ist natürlich zu bezweifeln. Ich würde die Formularüberprüfung nicht beim blur durchführen bzw. keinen automatischen focus() durchführen.
Ich würde in onBlur vor allem kein Alert aufrufen... schon mal probiert, was passiert, wenn man mit einem falschen Wert im Feld einen Taskwechsel macht (also auf ein Fenster eines anderen Programmswechselt)? Zumindest bei meinen Versuchen kam da der Firefox komplett aus dem Tritt und hatte plötzlich keinen Cursor mehr für die Eingabefelder. Erst ein erfolgreicher Taskwechsel weg vom Firefox und wieder zurück hat das wieder in Ordnung gebracht. Der Fuchs mag es schienbar nicht, wenn man seinen Blur-Vorgang durch ein Alert unterbricht...
Vorschlag: mach doch kein nerviges Alert, sondern markier das Eingabefeld mit dem falschen Wert farblich.
Ja, die Idee besteht eh beim Drücken des Senden-Buttons alle Fehleingaben zu markieren und aufzulisten, würde nur halt einen extremen Programmieraufwand hervorrufen.
Weisst du wie es mit anderen Events wie zB onChange aussieht? verhalten die sich gleich, bzw. verursachen die auch Probleme?
Gruß,
Harlequin
lg
Thomas-
Moin!
Vorschlag: mach doch kein nerviges Alert, sondern markier das Eingabefeld mit dem falschen Wert farblich.
Ja, die Idee besteht eh beim Drücken des Senden-Buttons alle Fehleingaben zu markieren und aufzulisten, würde nur halt einen extremen Programmieraufwand hervorrufen.
Nein, nicht wirklich - wenn vernünftige Strukturen dem Javascript sagen, welche Datenrichtlinien einzuhalten sind, ist die Umsetzung sowohl von Prüfungen onchange/onblur als auch onsubmit kein Zusatzaufwand.
- Sven Rautenberg
--
"Love your nation - respect the others." -
Yerf!
Weisst du wie es mit anderen Events wie zB onChange aussieht? verhalten die sich gleich, bzw. verursachen die auch Probleme?
onChange hat den Nachteil, das es nur einmal feuert. D.h. wenn der Benutzer ohne Änderung ein 2. Mal versucht das Feld zu verlassen bekommt er keine Meldung mehr. Es steht aber weiterhin eine falsche Eingabe im Feld.
Gruß,
Harlequin
-
-
-