nicht angemeldet
Rolf ẞ
Henry
Gunnar Bittersmann
Camping_RIDER
Gunnar Bittersmann
MudGuard
Gunnar Bittersmann
dedlfix
Gunnar Bittersmann
dedlfix
Camping_RIDER
Hallo,
ist es möglich dass das onchange="this.form.submit()" nur dann ausgeführt wird, wenn ich nicht auf dem Punkt "-- Bitte wählen --" bin? Denn sonst bekomme ich leere Einträge in die Datenbank.
JürgenB<form action="" method="POST">
<label for="status">Status</label>
<select name="status" id="status" onchange="this.form.submit()">
<option value="">-- Bitte wählen --</option>
<option value="1">Online</option>
<option value="2">Offline</option>
<option value="3">Gelöscht</option>
<option value="4">Rückfrage</option>
</select>
</form>
EDIT: Hab es mit required getestet, allerdings ohne Erfolg. Der Eintrag wird dennoch abgeschickt.
Rolf ẞ
Hallo Sophie,
Wenn Du keinen Ready-Handler mit addEventListener-Registrierung schreiben willst, kannst Du auch bei onchange bleiben - ist ja deine Seite - und rufst darin eine Javascript-Funktion auf die Du in einem Script-Block anderswo auf der Seite notierst. Also z.B.
<input ... onchange="sendStatusValue(this)">
…
</input>
<script>
function sendStatusValue(statusSelect) {
// statusSelect ist das HTML Objekt für das Select-Element
// hier kannst Du den Wert abfragen und nach Bedarf selectElement.form.submit()
// aufrufen
}
Der EventHandler für eine addEventListener Registrierung sähe ähnlich aus, der bekommt nur automatisch ein "event" Objekt mit, bei dem Du im target-Property das Select-Element findest.
So, und nun kommt der SelfHTML-typische Sermon. Bei Nichtgefallen einfach ignorieren 😉.
Wenn Du doppelte Werte bekommst, solltest Du Dir aber auch Gedanken über dein UI-Design machen. Es ist nicht fehlertolerant. Change wird gefeuert sobald man einen Wert auswählt. Vielleicht war man zu hektisch oder verklickt sich. Und schwups hat man was geschickt was man nicht will. SELECT-Elemente mit Auto-Submit sind kontra-intuitiv. Das musst Du gegen den Komfort aufrechnen, nicht "speichern" drücken zu müssen. Vielleicht machst Du besser eine Liste aus Buttons. Oder doch einen Submit-Button, das ist intuitiver.
Rolf
Hallo Rolf,
- required greift nicht, weil "bitte wählen" ein Wert ist. Also ist die 'required' Bedingung erfüllt. Ich mag mich auch irren - ich guck noch mal.
Gruss
Henry
Hallo Henry,
es ist merkwürdig. Preselektiere mal einen anderen Wert und wähle dann "none" - es wird submitted.
Rolf
Hallo Rolf B,
required greift nicht, weil "bitte wählen" ein Wert ist. Also ist die 'required' Bedingung erfüllt. Ich mag mich auch irren - ich guck noch mal.
Nein, der Wert ist nicht gegeben, denn in value="" steht nicht drin, somit ist dieses leer? required geht doch nicht nach der Bezeichnung? Wäre mir zumindest neu.
Den Rest verstehe ich leider nicht, was du meinst.
Hallo Sophie,
kannst Du auch nicht, war Müll. Sorry.
Rolf
Hallo,
ich habe es jetzt so getestet, leider funktioniert das automatische abschicken nicht
<form action="" method="POST">
<label for="status">Status</label>
<select name="status" id="status" onchange="sendStatusValue(this)">
<option value="">-- Bitte wählen --</option>
<option value="1">Online</option>
<option value="2">Offline</option>
<option value="3">Gelöscht</option>
<option value="4">Rückfrage</option>
</select>
</form>
function sendStatusValue(statusSelect) {
var status = $('#status');
if (status != "" ) {
selectElement.form.submit()
} else {
alert("Bitte einen Wert wählen");
}
}
Hallo Sophie,
ich habe es jetzt so getestet, leider funktioniert das automatische abschicken nicht
Das Q&D Beispiel von Rolf funktioniert schon mal auf die Schnelle.
Die endgültige Lösung, dürfte wahrscheinlich anders ausfallen als du im Moment probierst. Daher eine Frage, ich vermute, das Select ist nur ein Teilauszug aus dem Formular, denn sonst wäre die Prüfung ja sinnlos. Also gehe ich davon aus, du hast mehrere solcher Select und sobald eines aktiviert wird soll aber das ganze Formular gesendet werden?
Da bietet sich natürlich eine separate Funktion an, die auch noch andere Sachen abgleicht und ausführt. Ist meine Vermutung richtig und könntest Du dann ein wenig mehr vom Formular zeigen
Gruss
Henry
Hallo Henry,
ich habe mehrere Formulare auf der Seite, aber jedes Formular steht für für sich. Daher ist das der ganze Code, den ich vorhin gepostet habe.
Hallo Sophie,
ich habe mehrere Formulare auf der Seite, aber jedes Formular steht für für sich. Daher ist das der ganze Code, den ich vorhin gepostet habe.
hmmm.. dann verstehe ich das nicht schließlich sendet das Form ja nur, sobald jemand einen Eintrag auswählt (eben change) und dann sofort also wie gewollt. Also bei mir (IE11) tut sich sonst nichts. Oder ich verstehe dich falsch?
Gruss
Henry
Hallo Sophie,
ein potenzieller Fehler und ein definitiver Fehler.
Potenziell: steht das Script vor dem Select-Statement? Sonst findet er das nicht. Siehst Du in der Konsole der Browser-Entwicklungstools. Mit einem Ready-Handler ist das egal, weil der erst läuft wenn das DOM steht. Ein Inline-Script wird ausgeführt, wo es steht - und wenn es hinter dem SELECT steht, dann existiert die Funktion beim Parsen des SELECT noch nicht (hatte den gleichen Fehler eben selber gemacht).
Definitiv: $("#status") ist nicht der Wert des Select-Elements. jQuery liefert Dir ein "wrapped set", d.h. eine Liste der gefundenen Elemente. Diese Liste kann auch leer sein, d.h. du musst nie abfragen, ob $("#status") ein wrapped set ist oder nicht. An den Wert kommst Du, indem Du noch .val() anhängst. Lies die Doku von jQuery!
Aber: Du brauchst hier kein jQuery - du bekommst das Select-Element direkt als Parameter mit. Du musst nur statusSelect.value abfragen.
Rolf
Hallo Sophie,
hier noch mal eine Alternative - wenn du jQuery einsetzt, ist das machbar.
$(document).on("change", ".autosubmit", function(evt) {
if (evt.target.value)
evt.target.form.submit();
});
Dieser Aufruf registriert einen change-Eventhandler auf dem DOKUMENT, also ganz oben im DOM, mit einem nachgelagerten Filter. D.h. jedes change kommt dort an (Stichwort event bubbling), und jQuery fragt dann, ob es von einem Element kommt, das die Klasse autosubmit hat. Wenn ja, wird geprüft ob der value nicht leer ist und dann submittet.
Du musst also nichts weiter tun, als diesen Eventhandler zu registrieren und den Feldern, die bei change submitten sollen, die Klasse autosubmit zu geben. Und es ist auch egal, wo dieses Script-Stück platziert ist, das document-Objekt gibt's immer.
Hat mit einem Select in meinem Fiddle geklappt...
Rolf
Hallo Rolf,
ich habe vorhin schon gesagt dass ich mit Eventhandler und Co. nichts anfangen kann. Jetzt kommst du damit schon wieder.
Hab es jetzt so umgesetzt, aber das Formular wird nicht abgeschickt
function sendStatusValue(statusSelect) {
if (statusSelect.value > "" ) {
selectElement.form.submit();
} else {
alert("Bitte etwas auswählen");
}
}
In den else Bereich geht er.
Hallo,
ich habe vorhin schon gesagt dass ich mit Eventhandler und Co. nichts anfangen kann.
das ist nicht gut. Ändere das.
> if (statusSelect.value > "" ) {
was willst mit diesem Vergleich erreichen? Ich hätte != genommen.
Gruß
Jürgen
Hallo Sophie,
EDIT: Hab es mit required getestet, allerdings ohne Erfolg. Der Eintrag wird dennoch abgeschickt.
Wo genau hast du denn required eingesetzt, sollte nämlich funktionieren?
Gruss
Henry
Hallo Henry,
Wo genau hast du denn required eingesetzt, sollte nämlich funktionieren?
hab es so getestet
<form action="" method="POST">
<label for="status">Status</label>
<select name="status" id="status" onchange="this.form.submit()" required>
<option value="">-- Bitte wählen --</option>
<option value="1">Online</option>
<option value="2">Offline</option>
<option value="3">Gelöscht</option>
<option value="4">Rückfrage</option>
</select>
</form>
Wird dennoch abgeschickt.
Hallo Sophie,
Yup, gerade gefiddelt. Sollte eigentlich greifen. Ich gucke noch.
Rolf
Hallo Ingrid,
wenn man das autosubmit rausnimmt und einen Submit-Button einbaut, greift "required". Ich müsste es recherchieren, habe aber eigentlich die nächsten Wochen keine Zeit dafür (weil Urlaub 😂) - irgendwas war mit Validation-Attributen und Javascript, das greift nicht automatisch ineinander.
Brute-Force "Lösung" - für Schnellentschlossene. Modernes Webdesign ist anders - siehe oben.
onchange="if (this.value) { this.form.submit(); }"
Rolf
@@Sophie
<form action="" method="POST"> <label for="status">Status</label> <select name="status" id="status" onchange="this.form.submit()"> <option value="">-- Bitte wählen --</option> <option value="1">Online</option> <option value="2">Offline</option> <option value="3">Gelöscht</option> <option value="4">Rückfrage</option> </select> </form>
Ich halte select für keine gute Idee.
Besser sind in den allermeisten Fällen Radio-Buttons:
<form method="POST" onchange="this.submit()">
<fieldset>
<legend>Status</legend>
<label><input type="radio" name="status" value="1" required> Online</label>
<label><input type="radio" name="status" value="2" required> Offline</label>
<label><input type="radio" name="status" value="3" required> Gelöscht</label>
<label><input type="radio" name="status" value="4" required> Rückfrage</label>
</fieldset>
<button>Status ändern</button>
</form>
(Die HTML-Spec sagt: action="" ist nicht erlaubt, einfach weglassen. required bei jedem der Radio-Buttons ist empfohlene Praxis, siehe Beispiel 23)
Du lauschst jetzt aufs change-Event des form-Elements.
Wie bereits gesagt, sollte das nicht im HTML-Code stehen. Stattdessen gibts du dem Formular einen Namen:
<form method="POST" name="status-form">
und registrierst den Eventhandler:
var statusFormElement = document.forms['status-form'];
statusFormElement.addEventListener('change', function () { this.submit(); });
Näheres dazu bei molily: Fortgeschrittene Ereignisverarbeitung. (Den Teil ab „Event-Handling gemäß Microsoft für ältere Internet Explorer“ kannst du wohl ignorieren; IE 8 und älter dürfte nicht mehr relevant sein.)
Den Submit-Button hab ich eingefügt, damit das Formular auch ohne JavaScript bedienbar ist. Wenn JavaScript ausgeführt wird, dann kann der mit JavaScript(!) ausgeblendet werden:
statusFormElement.querySelector('button').setAttribute('hidden', '');
LLAP 🖖
Besser sind in den allermeisten Fällen Radio-Buttons:
In diesem Fall wären Submit-Buttons wohl die noch bessere Wahl. Da spart man sich im Übrigen den JavaScript-Teil gleich ganz.
@@1unitedpower
Besser sind in den allermeisten Fällen Radio-Buttons:
In diesem Fall wären Submit-Buttons wohl die noch bessere Wahl. Da spart man sich im Übrigen den JavaScript-Teil gleich ganz.
Du meinst so:
<form method="POST">
<button name="status" value="1">Online</button>
<button name="status" value="2">Offline</button>
<button name="status" value="3">Gelöscht</button>
<button name="status" value="4">Rückfrage</button>
</form>
Ja, find ich gut.
LLAP 🖖
Hallo 1unitedpower,
In diesem Fall wären Submit-Buttons wohl die noch bessere Wahl...
Normalerweise schon, in diesem speziellen Fall ist es aber wohl dem Komfort geschuldet. Denn, so wie ich das sehe, anhand anderer Threads, ist Sophie immer noch mit ihrem geschlossenen Adminbereich beschäftigt und da würde ich dann auch nicht unbedingt regelkonform arbeiten.
Was sich mir aber immer noch nicht erschließt, was genau das Problem ist. Sie ruft eine Seite auf, dort mehrere Formulare mit Select, sobald (und zwar genau erst dann) sie dort rumspielt, geht der Post raus. Also besteht doch gar keine Gefahr, dass die leeren Values aktiviert werden. Was genau verstehe ich denn da nicht?
Gruss
Henry
Aloha ;)
Zusätzlich zu den weiteren Hinweisen, die dir gegeben wurden:
So etwas…
Denn sonst bekomme ich leere Einträge in die Datenbank.
…solltest du unbedingt serverseitig verhindern. Die clientseitige Vermeidung ist zwar sinnvoll (schon alleine für die UX), aber die serverseitige Vermeidung ist hier aus Sicherheitsgründen wohl angebracht.
Nur, falls du das nicht sowieso schon gemacht hast - das geht aus deiner Frage nicht hervor.
Grüße,
RIDER
@@Camping_RIDER
Denn sonst bekomme ich leere Einträge in die Datenbank.
…solltest du unbedingt serverseitig verhindern. […] die serverseitige Vermeidung ist hier aus Sicherheitsgründen wohl angebracht.
Inwiefern sollten sich da Sicherheitslücken öffenen?
LLAP 🖖
Hi,
Denn sonst bekomme ich leere Einträge in die Datenbank.
…solltest du unbedingt serverseitig verhindern. […] die serverseitige Vermeidung ist hier aus Sicherheitsgründen wohl angebracht.
Inwiefern sollten sich da Sicherheitslücken öffenen?
da offensichtlich bisher keine serverseitige Validierung stattfindet, kann man der Datenbank alles unterjubeln.
cu,
Andreas a/k/a MudGuard
@@MudGuard
Denn sonst bekomme ich leere Einträge in die Datenbank.
…solltest du unbedingt serverseitig verhindern. […] die serverseitige Vermeidung ist hier aus Sicherheitsgründen wohl angebracht.
Inwiefern sollten sich da Sicherheitslücken öffenen?
da offensichtlich bisher keine serverseitige Validierung stattfindet, kann man der Datenbank alles unterjubeln.
Ja, und? Dann steht ein komischer Wert für Status in der DB. Was hat das mit Sicherheit zu tun?
Das man jedewede Nutzereingaben vor dem Eintragen in die DB kontextgerecht behandelt, ist klar. Das hat nichts mit Validierung zu tun.
LLAP 🖖
Tach!
Das man jedewede Nutzereingaben vor dem Eintragen in die DB kontextgerecht behandelt, ist klar.
Jedwede Daten. Es gibt da keinen Unterschied, ob sie aus Nutzereingaben stammen oder aus anderen Quellen. Und zudem betrifft das nur das Einfügen in SQL-Statements. Prepared Statements können das ohne spezielle Behandlung.
dedlfix.
@@dedlfix
Das man jedewede Nutzereingaben vor dem Eintragen in die DB kontextgerecht behandelt, ist klar.
Jedwede Daten.
Ja, wie immer. 😉
Allerdings: Wenn man was anderes als Nutzereingaben in die DB schreibt, könnte das auf einen Softwaredesign-Fehler hindeuten.
LLAP 🖖
Tach!
Allerdings: Wenn man was anderes als Nutzereingaben in die DB schreibt, könnte das auf einen Softwaredesign-Fehler hindeuten.
Nein, wieso? Es gibt genügend Daten, die nicht von Menschenhand getippt werden. Wo sollte man die denn sonst hinschreiben als in eine Datenbank? Ein ganz kleines Beispiel wären regelmäßige Messdaten eines Sensors. Die wird wohl kaum jemand per Hand eintragen wollen.
dedlfix.
Allerdings: Wenn man was anderes als Nutzereingaben in die DB schreibt, könnte das auf einen Softwaredesign-Fehler hindeuten.
Unique Identifier? Änderungsdatum? Referenzen auf beteiligte Datensätze in anderen Tabellen?
Aloha ;)
Denn sonst bekomme ich leere Einträge in die Datenbank.
…solltest du unbedingt serverseitig verhindern. […] die serverseitige Vermeidung ist hier aus Sicherheitsgründen wohl angebracht.
Inwiefern sollten sich da Sicherheitslücken öffenen?
da offensichtlich bisher keine serverseitige Validierung stattfindet, kann man der Datenbank alles unterjubeln.
Ja, und? Dann steht ein komischer Wert für Status in der DB. Was hat das mit Sicherheit zu tun?
Berechtigte Frage, einfache Antwort:
Aus der Frage des TO geht hervor, dass die Maßnahmen, die clientseitig getroffen werden, verhindern sollen, dass leere Einträge in die Datenbank kommen. Ergo sind leere Einträge in der Datenbank nicht erwünscht und sollen verhindert werden. Wären leere Einträge in der Datenbank egal müssten sie auch clientseitig nicht verhindert werden.
Demnach stehen, wenn serverseitig nicht validiert wird, dann vielleicht doch mal leere Einträge in der Datenbank - während der TO denkt, sowas könne nicht mehr vorkommen, weil es sei ja schon verhindert.
Ja, das ist ein Schuss ins Blaue, der TO könnte auch wissen was er tut und die Werte aus der Datenbank vor ihrer Verwendung prüfen. Wir wissen aber beide, dass genau das oft nicht der Fall ist.
Und zu guter letzt: Gerade bei Software, die „wächst“, reicht es oft (aus Sicherheitsgründen) nicht, zu denken „ach ja, ich prüf ja später vor der Verwendung die Daten, also muss ich sie nach der Eingabe nicht prüfen“, weil der Nachfolger im Job, der gerade nach dem Peter-Prinzip seine Stufe der Unfähigkeit erreicht hat, bestimmt davon ausgeht, dass die Daten in der Datenbank alle geprüft und validiert sind.
Robustheit ist hier das Stichwort, und Robustheit (auch gegenüber mir selbst als Programmierer und meiner eigenen Schusseligkeit und Vergesslichkeit) ist ein Sicherheitsmerkmal. Deshalb spreche ich hier von Sicherheitsgründen.
Grüße,
RIDER
@@Camping_RIDER
Ja, und? Dann steht ein komischer Wert für Status in der DB. Was hat das mit Sicherheit zu tun?
Berechtigte Frage, einfache Antwort:
Zu einfache Antwort.
Aus der Frage des TO geht hervor, dass die Maßnahmen, die clientseitig getroffen werden, verhindern sollen, dass leere Einträge in die Datenbank kommen. Ergo sind leere Einträge in der Datenbank nicht erwünscht und sollen verhindert werden.
nicht erwünscht ≠ nicht sicher.
„sollen verhindert werden“ ist keine Antwort auf die Frage: Was hat das mit Sicherheit zu tun?
Wären leere Einträge in der Datenbank egal müssten sie auch clientseitig nicht verhindert werden.
nicht egal = nicht erwünscht ≠ nicht sicher.
Demnach stehen, wenn serverseitig nicht validiert wird, dann vielleicht doch mal leere Einträge in der Datenbank
Das sagte ich bereits: Ja, und? Dann steht ein komischer Wert für Status in der DB.
während der TO denkt, sowas könne nicht mehr vorkommen, weil es sei ja schon verhindert.
Was hat das mit Sicherheit zu tun?
Robustheit ist hier das Stichwort
Richtig. Robustheit ≠ Sicherheit.
und Robustheit (auch gegenüber mir selbst als Programmierer und meiner eigenen Schusseligkeit und Vergesslichkeit) ist ein Sicherheitsmerkmal. Deshalb spreche ich hier von Sicherheitsgründen.
Du verwendest hier „Sicherheit“ im umgangssprachigen Sinn: Sicherzugehen, dass das Programm nichts unerwartetes tut. Das ist aber nicht das, was unter dem Begriff „Sicherheit“ im Kontext Webprogrammierung gemeinhin verstanden wird.
LLAP 🖖
Hallo Camping_RIDER,
nützlicher Verweis, kannte ich noch nicht, danke. Das erklärt dann auch warum oft fachlich völlig inkompetente Menschen, das höchste Amt eines Fachbereichs bekleiden dürfen, eben Minister der jeweiligen Fachrichtung.
Gruss
Henry
Hallo Henry,
wobei das nicht stimmt. Minister sind Behördenleiter. Da die Fachkompetenz ohnehin in den Etagen darunter sitzt, spiel die Fachkompetenz der Minister eine untergeordnete Rolle. Wichtig ist für Minister wie im übrigen Management, Menschen führen zu können. – Und nein, ich will damit nicht behaupten, Minister könnten das.
MfG, at
Hallo at,
wobei das nicht stimmt. Minister sind Behördenleiter. Da die Fachkompetenz ohnehin in den Etagen darunter sitzt, spiel die Fachkompetenz der Minister eine untergeordnete Rolle. Wichtig ist für Minister wie im übrigen Management, Menschen führen zu können. – Und nein, ich will damit nicht behaupten, Minister könnten das.
Menschen führen und hohe Entscheidungsgewalt haben in einem Fachbereich von dem man Null Ahnung hat und sich dort auf des Wissen der Untergebenen verlassen... na ja.
Na dann gilt aber gleiches Recht für alle... Ich wollte vor etlichen Jahren mal wissen ob es funktioniert eine Anwaltskanzlei nach amerikanischem Vorbild aufzumachen, also Firma gründen Anwälte einstellen, usw... Das durfte ich nicht ohne selbst fertiger Jurist zu sein, aber Justizminister werden, das dürfte ich 😉
Gruss
Henry
Hallo Henry.
Menschen führen und hohe Entscheidungsgewalt haben in einem Fachbereich von dem man Null Ahnung hat und sich dort auf des Wissen der Untergebenen verlassen... na ja.
Hätte ich „null Ahnung“ gemeint, hätte ich es geschrieben.
Na dann gilt aber gleiches Recht für alle…
Weil …? – Juristen haben in unserem Rechtssystem eine Sonderstellung, die sich in anderen Zusammenhängen noch viel deutlicher zeigt.
Ich wollte vor etlichen Jahren mal wissen ob es funktioniert eine Anwaltskanzlei nach amerikanischem Vorbild aufzumachen, also Firma gründen Anwälte einstellen, usw... Das durfte ich nicht ohne selbst fertiger Jurist zu sein, aber Justizminister werden, das dürfte ich 😉
Das klingt plausibel.
MfG, at