nicht angemeldet
Checkboxen Value prüfen bei "unchecked"
MudGuardHallo
in einem PHP Script werden checkboxen dynamisch erstellt.
so ähnlich..
..
$sqldata = getDatafrom DB();
<input type=checkbox name="mycheckbox[]" value="$sqldata['number']">
Bei einem Post submit bekommt man ja alle Checkboxen die gesetzt sind.
Wie aber kann man die herausfinden, die nicht gesetzt sind?
Ich will das Ganze dazu verwenden, um in eine DB später ein Update einer Spalte zu machen.
Für gesetzte Werte ein Update mit =1 , für ungesetzte = 0,
Gruss
Werner
-
Hello,
in einem PHP Script werden checkboxen dynamisch erstellt.
so ähnlich..
..
$sqldata = getDatafrom DB();
<input type=checkbox name="mycheckbox[]" value="$sqldata['number']">Bei einem Post submit bekommt man ja alle Checkboxen die gesetzt sind.
Wie aber kann man die herausfinden, die nicht gesetzt sind?Man muss eben vorher festlegen, welche man zurück erwartet und das dann anschließend auch kontrollieren.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
<input type=checkbox name="mycheckbox[]" value="$sqldata['number']">
Die Best Practice hier ist, mit einem <input type="hidden" name="…" value="0"> für jeden Datensatz zu arbeiten. Dann gibt es eine <input type="checkbox"> mit demselben name, aber value="1". Ist die Checkbox aktiviert, wird 1 übertragen, ansonsten 0.
Das ist natürlich nicht möglich, wenn es dutzende Felder mit name="mycheckbox[]" gibt. Dann würde ich raten, für jeden Datensatz ein eindeutigen Namen zu verwenden:
name="cats[0]"
name="cats[1]"
name="cats[2]"
usw.Mathias
-
Tach!
Die Best Practice hier ist, mit einem <input type="hidden" name="…" value="0"> für jeden Datensatz zu arbeiten. Dann gibt es eine <input type="checkbox"> mit demselben name, aber value="1". Ist die Checkbox aktiviert, wird 1 übertragen, ansonsten 0.
Genauer gesagt, die Werte vom Hidden-Input werden immer übertragen, die von der Checkbox nur bei Häkchen drin. Somit bekommt man im Häkchen-Fall 0 und 1 im Querystring oder in den POST-Daten. Wenn PHP zwei Input-Werte mit demselben Namen bekommt, werden beide nacheinander in $_GET oder $_POST geschrieben. Das letzte überschreibt dabei das erste, welches dann nicht mehr zu sehen ist. Es ist deshalb wichtig, dass das Hidden-Input vor der Checkbox notiert wird.
dedlfix.
-
hi,
<input type=checkbox name="mycheckbox[]" value="$sqldata['number']">
Die Best Practice hier ist, mit einem <input type="hidden" name="…" value="0"> für jeden Datensatz zu arbeiten. Dann gibt es eine <input type="checkbox"> mit demselben name, aber value="1". Ist die Checkbox aktiviert, wird 1 übertragen, ansonsten 0.
Na, als Best Practice wurde ich das nicht bezeichnen, sowas Umständliches ist mir noch nie untergekommen ;)
Aber: Jede Idee hat was!
Und wenn schon umständlich, dann richtig mit JavaScript und AJAX: JS zum zusammenbauen einer servergefälligen Datenstruktur (1), Ajax zum Übertragen.
- Was mit konventionellen Form-Elementen und einem schnöden Submit gar nicht geht.
Viele Grüße.
-
- Was mit konventionellen Form-Elementen und einem schnöden Submit gar nicht geht.
Input-Gruppierung über class-Attribute:
Die Idee die dahintersteckt: class-Names sind gleichnamige Schlüssel in einem Objekt, das wird clientseitig so zusammengebaut, dass serverseitig die Werte direkt über den Namen adressierbar sind.
Is nur Hobby, nix für Profi :)
-
Meine Herren!
Die Idee die dahintersteckt: class-Names sind gleichnamige Schlüssel in einem Objekt
Wieso nicht die vorhanden Kapazitäten nutzen, das name-Attribut ist für die Kodierung der Daten vorgesehen:
<form action="foo" enctype="application/x-www-form-urlencoded"> <input name="person[familienname]"> <input name="person[rufname]"> <button>Absenden</button> </form> <textarea name="person[anschrift]">Diese Art der Notation ist mit den bestehenden Formular-Kodierungs-Algorithmen kompatibel. Und zukünftige Algorithmen werden mit hoher Wahrscheinlichkeit abwärtskompatibel zu dieser Notation entworfen. So wie es derzeit auch mit dem JSON-Formular-Kodierungs-Algorithmus geschieht.
das wird clientseitig so zusammengebaut, dass serverseitig die Werte direkt über den Namen adressierbar sind.
Der Server kann nicht durch Zauberhand erraten, wie Daten zu verstehen sind, die ihm gesendet werden. Diese Information steckt man dem Webserver über den MIMEType. Ein MIMEType application/json sagt dem Server da kommen JSON-Daten. Mit dem MIMEType text/plain sagen wir dem Server hier kommen perfide Text-Daten. Für die gängigen Formate bieten die Webserver den Entwicklern häufig eine integrierte Schnittstelle. Ein Beispiel:
Wenn wir das Formular dort oben an einen Apache-Webserver mit PHP schicken, kann ein PHP-Entwickler bequem über das $_POST-Array darauf zugreifen: Mit
$_POST['person']['rufname']können wir den Rufnamen intuitiv auslesen.Der MIMEType "application/octet-stream" ist in gewisserweise ein Sonderfall, sinngemäß teilt er dem Server mit: "Hier kommt ein Haufen Binärdaten, über die du nichts weiter wissen brauchst". Es kann alles kommen: Eine Bild, ein Zip-Archiv ein JSON-Objekt oder ein stinknormaler Text, für die Weiterverarbeitung sollte das egal sein. Der Server kann dem Backend-Entwickler also auch nicht weiter unter die Arme greifen, um mit den Daten fertig zu werden. Du als Entwickler kannst natürlich erraten, wie die Daten zu interpretieren sind, weil du ja selber das Formular dazu erstellt hast. Besser ist man verlässt sich nicht auf seine Fertigkeiten zu Raten, sondern man übermittelt einen aussagekräftigen MIMEType. Es ist auch möglich eigene MIMETypes zu senden: "application/x-hotti-eav" würde sich doch anbieten.
Übliche HTML-Formulare unterstützen nur drei MIMETypes "text/plain", "application/x-www-form-urlencoded" und "multipart/form-data". Leider ist nicht mal "application/json" dabei, wir können aber natürlich die Standard-Absende-Routine des Formulars unterbinden und mit Ajax trotzdem JSON senden, wenn wir darauf angewiesen sind. Wenn wir sowas aber machen, dann sollten wir mit Rücksicht auf die bestehenden Formular-Kodierungen nur Informationen verschicken, die für eine Kodierung vorgesehen sind, das sind a) offensichtlich die Werte der Formular-Felder und b) die Namen der Formular-Felder. Alles andere, insbesondere Klassennamen, sollten in so einem Work-Around IMHO keine Anwendung finden, weil sie keine trivialen Kandidaten für die Übermittlung sind (1).
So ähnlich sieht es bei den HTTP-Verben aus: Von HTML-Formularen werden bis heute nur "GET" und "POST" unterstützt, aber wir können wieder auf AJAX ausweichen, um dieses Problem zu umschiffen. Es gibt Bestrebungen der HTML-Working-Group dieses Problem zu lösen: http://cameronjones.github.io/form-http-extensions/index.html
- Mit dieser Einschränkung, wird deine Idee zur Lösung des ursprünglichen Problems in diesem Thread, natürlich hinfällig. Aber solche Einschränkungen helfen eben dabei strukturierte Software zu entwickeln und die Veranwortlichkeiten sauber getrennt zu halten.
--
“All right, then, I'll go to hell.” – Huck Finn
-
-
hi,
Bei einem Post submit bekommt man ja alle Checkboxen die gesetzt sind.
Wie aber kann man die herausfinden, die nicht gesetzt sind?Was machst Du serverseitig?
Ich will das Ganze dazu verwenden, um in eine DB später ein Update einer Spalte zu machen.
Für gesetzte Werte ein Update mit =1 , für ungesetzte = 0,Aha, Idee: DB-Design => Default-Wert festlegen, fertig.
MfG
-
Tach!
Ich will das Ganze dazu verwenden, um in eine DB später ein Update einer Spalte zu machen.
Für gesetzte Werte ein Update mit =1 , für ungesetzte = 0,
Aha, Idee: DB-Design => Default-Wert festlegen, fertig.Default-Werte werden bei einem Update nicht berücksichtigt. Man muss dabei schon explizit angeben, dass man statt 1 nun eine 0 haben möchte.
dedlfix.
-
hi,
Default-Werte werden bei einem Update nicht berücksichtigt.
Genauh! Setzen wir bereits im DB-Design den Default = 0 ...
Man muss dabei schon explizit angeben, dass man statt 1 nun eine 0 haben möchte.
... dann wird dieses Datenfeld den Wert = 0 bekommen, wenn beim Update der Wert fehlt.
Einfacher gehts nicht ;)
-
Tach!
Genauh! Setzen wir bereits im DB-Design den Default = 0 ...
... dann wird dieses Datenfeld den Wert = 0 bekommen, wenn beim Update der Wert fehlt.Neien! Default-Werte werden nur beim Insert berücksichtigt. Wenn sie beim Update berücksichtigt würden, müsste man ja zwangsweise alle Werte nochmal neu übergeben, wenn man darin keine Änderungen haben möchte (oder ... SET feld=feld notieren). Und man hätte solche und solche Felder, die einen täten sich ohne Zutun ändern, die anderen nicht.
dedlfix.
-
Mahlzeit,
Neien! Default-Werte werden nur beim Insert berücksichtigt.
Das geht nur mit ner Timestamp mit ON UPDATE CURRENT_TIMESTAMP.
Ist auch der einzige Fall, wo es Sinn macht. Zumindest ist mir noch kein anderer Fall untergekommen, wo das Sinn machen würde.--
42-
Tach!
Neien! Default-Werte werden nur beim Insert berücksichtigt.
Das geht nur mit ner Timestamp mit ON UPDATE CURRENT_TIMESTAMP.Naja, das ist nicht direkt ein Default-Wert (da gibt es nur bzw. extra noch DEFAULT CURRENT_TIMESTAMP) sondern eher eine Update-Regel, und die zieht auch nur bei einem einzigen Timestamp-Feld.
Ist auch der einzige Fall, wo es Sinn macht. Zumindest ist mir noch kein anderer Fall untergekommen, wo das Sinn machen würde.
Eben, wir müssen das hier nicht vertiefen, für den vorliegenden Fall hat das keine Bewandnis.
dedlfix.
-
Mahlzeit,
Neien! Default-Werte werden nur beim Insert berücksichtigt.
Das geht nur mit ner Timestamp mit ON UPDATE CURRENT_TIMESTAMP.
Ist auch der einzige Fall, wo es Sinn macht. Zumindest ist mir noch kein anderer Fall untergekommen, wo das Sinn machen würde.Each value can be given as an expression, or the keyword DEFAULT to set a column explicitly to its default value.
Aber in Fakt ist die Umsetzung mit gleichnamigen Checkboxen ziemlich ungeschickt. Ich würde den Checkboxen unterschiedliche und zweckmäßige Namen geben und gut isses.
Schönen Abend.
--
Wer Bahnhof versteht, sollte wenigstens einen Fahrplan haben.-
Mahlzeit,
Each value can be given as an expression, or the keyword DEFAULT to set a column explicitly to its default value.
Ja, bei einem INSERT ist das klar, aber ich habe nichts gefunden, dass es auch bei einem UPDATE greift. Das würden mir ja evtl. Daten überschrieben, die nicht verändert werden dürfen.
--
42-
Tach!
Each value can be given as an expression, or the keyword DEFAULT to set a column explicitly to its default value.
Ja, bei einem INSERT ist das klar, aber ich habe nichts gefunden, dass es auch bei einem UPDATE greift. Das würden mir ja evtl. Daten überschrieben, die nicht verändert werden dürfen.Es greift nur dann bei einem UPDATE, wenn man das explizit notiert. Dann hat man aber nichts gewonnen, denn ob man SET field=DEFAULT oder SET field=0 schreibt, bleibt sich vom Aufwand her gleich. Man muss es immer notieren, wozu man dann auch immer am Server entscheiden muss, ob man das DEFAULT oder einen anderen Wert übergibt. Und in dem Fall kann man statt DEFAULT auch gleich 0 (oder was auch immer der Wert für nicht angehakt ist) übergeben. Einen Automatismus, der bei einem UPDATE Default-Werte setzt gibt es weiterhin nicht.
dedlfix.
-
Hello,
Einen Automatismus, der bei einem UPDATE Default-Werte setzt gibt es weiterhin nicht.
Hast Du diese Aussage mit KK Gunnar abgesprochen vorher?
Es gibt nämlich Triggers. Und die sind sehr wohl in der Lage, beim Update definierte Werte in ein Datenfeld einzutragen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Tach!
Einen Automatismus, der bei einem UPDATE Default-Werte setzt gibt es weiterhin nicht.
Hast Du diese Aussage mit KK Gunnar abgesprochen vorher?
Es gibt nämlich Triggers. Und die sind sehr wohl in der Lage, beim Update definierte Werte in ein Datenfeld einzutragen.Selbst programmieren kann man vieles. Das Argument in diesem Teil-Thread war aber, ohne etwas zu tun, Default-Werte ins UPDATE zu bekommen. Die Trigger-Variante scheitern hier am "ohne etwas zu tun".
dedlfix.
-
Mahlzeit,
Es gibt nämlich Triggers. Und die sind sehr wohl in der Lage, beim Update definierte Werte in ein Datenfeld einzutragen.
Das ist aber kein Default-Wert, sondern, wie du selbst sagst, ein definierter Wert, der über eine externe Funktion eingetragen wird.
--
42
-
-
-
-
-
-
Hi,
Genauh! Setzen wir bereits im DB-Design den Default = 0 ...
... dann wird dieses Datenfeld den Wert = 0 bekommen, wenn beim Update der Wert fehlt.Neien! Default-Werte werden nur beim Insert berücksichtigt.
Dohoch. Aber nur, wenn Du die von hotti dem Radneuerfinder konzipierte Datenbank hot-hotter-hotti-db verwendest. Sollte es die noch nicht geben, wird er die sicher heute abend noch schnell schreiben ...
;-)
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
-
-
-
-
Lieber WernerK,
ich als Laie würde so vorgehen:
1.) aktuellen Datensatz auslesen
Damit ist eine Struktur vorgegeben (z.B. Array), inklusive der Datentypen der jeweiligen Werte (z.B. string/bool/int)
2.) die per POST hereinkommenden Daten damit abgleichen (wo kein POST-Schlüssel vorhanden und der Datentyp bool, "false" annehmen)
3.) Wertänderungen (nur diese!) in ein UPDATE formulieren und Datensatz in der DB aktualisieren.
Liebe Grüße,
Felix Riesterer.
--
"Wäre die EU ein Staat, der die Aufnahme in die EU beantragen würde, müsste der Antrag zurückgewiesen werden - aus Mangel an demokratischer Substanz." (Martin Schulz, Präsident des EU-Parlamentes)-
Tach!
ich als Laie würde so vorgehen:
1.) aktuellen Datensatz auslesen
2.) die per POST hereinkommenden Daten damit abgleichen (wo kein POST-Schlüssel vorhanden und der Datentyp bool, "false" annehmen)
3.) Wertänderungen (nur diese!) in ein UPDATE formulieren und Datensatz in der DB aktualisieren.Und damit hat man ein potenzielles TOCTTOU-Problem. Zwischen 1. und 3. können parallel laufende Prozesse den Datensatz ändern. Das muss nicht zwangsläufig ein Problem im vorliegenden Anwendungsfall sein. Andererseits, wenn man die Sache noch weiter betrachtet, kann das auch auftreten, wenn Zweitens wegfällt und durch den Input-Hidden-Trick die Daten gleich speicherbar geliefert werden. Erstens war dann ein früherer Request und zwischenzeitliche Änderungen werden durch Drittens auch nicht berücksichtigt. Wenn das aber ein Problem darstellt, muss man sowieso noch ein etwas anderes Geschütz auffahren. Zum Beispiel einen ausreichend fein auflösenden Timestamp mitpflegen, und den bei Erstens abfragen und beim Update vergleichen. Wenn er nicht mehr stimmt, kann das Update keinen Datensatz aktualisieren.
dedlfix.
-