JS: Formularwerte beim absenden ausgeben

[Pit]

Hallo,

ich habe bei einem Formular das seltsame verhalten, dass nciht alle Formularwerte im Script ankommen.

Wie kann ich per JS/Jquery alle abgesendeten Keys und Values angeben lassen? Kann ich das über eine Schleife machen, ohne die Keys selber zu kennen?

Pit

[pl]

Hallo,

Wie kann ich per JS/Jquery alle abgesendeten Keys und Values angeben lassen?

jQ kennt 2 Funktionen zum Serialisieren eines Forms:

$(form).serialize() und $(form).serializeArray(). Nimm Letztere und übergebe das Array an JSON wie folgt: JSON.stringify(array, null,2) und diesen Dump schreibe <pre>-formatted ins DOM.

so

MfG

[dedlfix]

Tach!

Wie kann ich per JS/Jquery alle abgesendeten Keys und Values angeben lassen? Kann ich das über eine Schleife machen, ohne die Keys selber zu kennen?

Du kannst mit dem FormData-Objekt arbeiten. Dem übergibst du eine Referenz auf das Formular (zum Beispiel document.forms[0]) und kannst dann über die Formular-Einträge iterieren.

dedlfix.

[Rolf B]

Hallo dedlfix,

das FormData-Objekt ist sicherlich ein Ansatz, aber wie wir aber neulich festgestellt haben, enthält es das Key-Value Paar nicht, das den submittenden Button bezeichnet (sofern über einen Button submitted wurde).

Wenn man wirklich genau sehen will, was wie zum Server geht, guckt man im Browser ins Netzwerk-Tab der Entwicklerwerkzeuge und schaut sich den Body des POST Requests an.

Rolf

[dedlfix]

Tach!

das FormData-Objekt ist sicherlich ein Ansatz, aber wie wir aber neulich festgestellt haben, enthält es das Key-Value Paar nicht, das den submittenden Button bezeichnet (sofern über einen Button submitted wurde).

Ups, unerwartet ... aber standardkonform.

Unter Interface FormData steht

"The FormData(form) constructor must [...] constructing the entry list for form."

Und dort sind buttons ausgeklammert. Zu input type=submit hab ich nichts finden können, aber die gehen auch nicht.

Interessanterweise steht da was zu einem submitter, und Buttons, die submitter sind, sind vom Ausklammern ausgenommen, aber es steht nicht da, wie der "optional submitter" anzugeben ist. Außerdem gibts dazu noch einen offenen Feature-Request.

dedlfix.

[pl]

@Rolf B

das FormData-Objekt ist sicherlich ein Ansatz, aber wie wir aber neulich festgestellt haben, enthält es das Key-Value Paar nicht, das den submittenden Button bezeichnet (sofern über einen Button submitted wurde).

Das ist ja so auch richtig. Denn es kann ja auch mehrere Buttons geben, wenn die allesamt mit name+value am Server ankämen könnte man ja gar nicht unterscheiden welcher Button resp. <input type=submit> geklickt wurde.

Von daher verhalten sich jQuery.serialize() und jQuery.serializeArray() genauso wie FormData.

MfG

[dedlfix]

Tach!

das FormData-Objekt ist sicherlich ein Ansatz, aber wie wir aber neulich festgestellt haben, enthält es das Key-Value Paar nicht, das den submittenden Button bezeichnet (sofern über einen Button submitted wurde).

Das ist ja so auch richtig. Denn es kann ja auch mehrere Buttons geben, wenn die allesamt mit name+value am Server ankämen könnte man ja gar nicht unterscheiden welcher Button resp. <input type=submit> geklickt wurde.

Deine Begründung passt nicht zum Thema. Es ging nicht darum, was beim Server ankommt, sondern ob man mit Javascript sehen kann, was beim Server ankommen wird. Und da war der Vorschlag FormData nicht zielführend, weil da - im Gegensatz zu den letzlich übertragenen Werten - der das Submit auslösende Button gar nicht enthalten ist.

Wenn du also eine Begründung hast, warum der auslösende Button zwar am Server ankommt, aber nicht in das FormData-Objekt aufgenommen wird, dann wäre ich ganz Ohr.

dedlfix.

[pl]

@dedlfix

Deine Begründung passt nicht zum Thema. Es ging nicht darum, was beim Server ankommt, sondern ob man mit Javascript sehen kann, was beim Server ankommen wird.

Hab ich hier längst beschrieben wie das geht. Auch mit einem praktischen Beispiel wo man sich das angucken kann wie sowas aussieht!

MfG

[dedlfix]

Tach!

Deine Begründung passt nicht zum Thema. Es ging nicht darum, was beim Server ankommt, sondern ob man mit Javascript sehen kann, was beim Server ankommen wird.

Hab ich hier längst beschrieben wie das geht. Auch mit einem praktischen Beispiel wo man sich das angucken kann wie sowas aussieht!

Beides leidet am selben Problem, um das es in diesem Teilthread ging. Es fehlt das name-value-Pärchen vom Submit-Button.

dedlfix.

[pl]

Es fehlt das name-value-Pärchen vom Submit-Button.

Oft genug erklärt!

[Rolf B]

Hallo pl,

Denn es kann ja auch mehrere Buttons geben, wenn die allesamt mit name+value am Server ankämen

Schon, aber kann nicht der Grund dafür sein, den Button aus FormData herauszunehmen. Denn wenn ein Submit-Button geklickt wurde und das Submit-Event läuft, dann weiß das DOM ganz genau, welcher Button der Auslöser war. Er wird ja auch in die Nachricht an den Server geschrieben.

Erfolgt der Submit per ENTER-Taste oder per .submit() Methode, dann gibt's keinen Submitter. Wobei es sinnvoll wäre, das der Submit-Methode mitteilen zu... oops - wenn ich form.submit() aufrufe, wird das Submit-Event gar nicht gefeuert und es gibt auch keine Validaion, das muss ich also programmtechnisch also eh besser per click()-Methode auf dem gewünschten Button lösen.

Alles sehr strange.

Rolf

[pl]

hi @Rolf B

wenn mit Focus in einem Eingabefeld Enter gedrückt wurde, ist der Button auch im Request, das habe ich gerade getestet. Das ist auch der Fall wenn es zu einem Button mehrere Inputfelder gibt.

Wenn es mehrere Submitbuttons und mehrere Eingabefelder gibt, löst Enter in einem beliebigen Eingabefeld ein Submit aus wobei name+value nur eines Submitbuttons gesendet wird. Das kann dazu führen, daß die Anwendung nicht das tut was der Benutzer beabsichtigte!

MfG

[Rolf B]

Hallo pl,

ja, das ist leider BAD (Bullshit As Designed). Hier ist eine Stackoverflow-Diskussion dazu.

Allerdings ist es mit HTML5 eigentlich definiert worden: 4.10.21.2. Implicit submission, insofern kann es sein, dass die Problematik ein Überbleibsel aus HTML 4 Zeiten ist. Dass der Button nicht im FormData landet, ist dann um so merkwürdiger.

Rolf

[pl]

@Rolf B

Es gbt immer Möglichkeiten. Z.B. <textarea> statt <input> und das Problem ist gelöst. Und wenn User unbedingt mit Enter arbeiten wollen, dann wird das Form eben so designed daß es eindeutig funktioniert.

Dass der Button nicht im FormData landet, ist dann um so merkwürdiger.

Ne, das ist völlig in Ordnung. Wenn Du einige eigene Erfahrungen im Umgang mit Schlüsselparametern gemacht hast, wirst Du auch verstehen warum.

MfG

[Rolf B]

Hallo pl,

das Minus ist nicht von mir. Aber deine Antwort kommt mir jetzt wirr vor. Manchmal erweckst Du den Eindruck, dass Du nicht mehr weißt wo der Thread hergekommen ist, und dann irgendwas antwortest was Dir gerade in den Sinn kommt. Lassen wir das hier - das Problem im FormData haben wir erörtert und können es nicht ändern.

Der eigentliche Drops ist ausgelutscht genug und dem OP hilft diese Teildiskussion nicht weiter.

Rolf

[pl]

Guten morgen @Rolf B

Manchmal erweckst Du den Eindruck, dass Du nicht mehr weißt wo der Thread hergekommen ist

Wie kommst Du denn darauf? Hier gehts darum, wie man einen dump erzeugt um damit zu prüfen welche Felder erfasst wurden.

Da ist FormData zwar das was dafür am ungeeignetsten ist, es ist jedoch so, daß sich FormData genauso verhält wie jQuery.serialize() was die Datenerfasung betrifft.

Im Grunde genommen geht es eben nicht darum wie man schlechthin ein Formular serialisiert sondern darum wie man ein Formular auf eine sinnvolle Datenstruktur liest die man sich als Dump im Browser ausgeben kann.

Es geht also um ein Thema was jeden Entwickler freut: Fehlersuche und Debugging. Und siehe da, es gibt jQuery.serializeArray sowie JSON was man als dafür als geeignete Werkzeuge einsetzen kann!

Und wenn der Dump dann im Browser liegt, was dann? Richtig, da geht es um die Energie des Verstehens!

Denn der schönste Dump nützt nichts wenn man ihn nicht deuten kann.

MfG

PS: Das Thema "Wie erzeuge ich aus einem Formular eine geeignete Datenstruktur" hatten hier wir hier übrigens hier im Forum vor gar nicht langer Zeit, siehe mein Beitrage im diesbezüglichen Thread. Hier ist das Ergebnis der Diskussion.

[Rolf B]

Hallo pl,

https://api.jquery.com/serializeArray schreibt:

No submit button value is serialized

Was ändert es also am Grundproblem? Du hast ja insofern recht, dass ein serializeArray Ergebnis sich einfacher ausgeben lässt als wenn man erstmal mit .entries() über FormData iterieren muss.

Zum Debugging der vollständigen client-generierten Antwort aus einem Form-Submit ist der Netzwerktrace im Browser das einfachste Mittel. Man muss nicht alles mit JS lösen.

Wenn man im Client per JS auf den Submit reagieren will und dafür den Submitter kennen muss, hilft der Netzwerktrace natürlich nicht, aber das Thema und Lösungsideen dazu hatten wir ja schon in einem anderen Thread.

Rolf

[pl]

hi @Rolf B

https://api.jquery.com/serializeArray schreibt:

No submit button value is serialized

Was ändert es also am Grundproblem?

Daß der Button nicht dabei ist, ist ja kein Problem sondern ein normales Verhalten. Dh., daß man den Schlüsselparameter selbst hinzufügen muss. Und je nachdem, was vorliegt, wird das entweder eine Stringoperation paramString += '&control=1' oder ein param.push({name:'control',value:'1'}) oder ein FD.append('control','1') wenn das name+value des relevanten Buttons sind.

So handhabt man das mit jedem Schlüsselparameter, also auch mit Solchen die nicht an Buttons gebunden sind. In vielen AdminBackends nach dem MVC Pattern hat man ja oft genug beides nebeneinander.

MfG

[Rolf B]

Hallo pl,

ich habe Kopfschmerzen. Und in der Wand neben mir ist eine schädelförmige Vertiefung mit ein paar roten Flecken. Keine Ahnung woher das kommt.

Das Grundproblem ist: Wie prüfe und debugge ich, welche Daten von einem Form gepostet wurden. Was ich eingangs schrieb war: Nicht mit FormData, nicht mit serializeArray, weil beidem der Submitbutton fehlt. Man kann das per Workaround ergänzen. Aber nicht für diesen Zweck. Es ist zu umständlich. Also: Diese Aufgabe löst man besser nicht mit JavaScript. Sondern mit dem Netzwerktrace-Tab der Entwicklerwerkzeuge. Da steht alles, was man braucht.

Davon sind wir abgeglitten zu einer neuen Diskussion über "sind die Buttons im FormData oder serializeArray drin". Nein, sind sie nicht, ich halte es persönlich für Käse, dass sie es selbst bei einem submit via Button nicht sind, aber das ist für die Thematik des Threads völlig wurscht und ich will hier auch keinen Workaround diskutieren, den man schreiben kann wenn man ihn braucht. Das haben wir zwei nämlich schon anderswo getan und da ist für mich ein Haken dran. Wie man Schlüsselparameter in URLs handhabt, oder Properties von Objekten oder FormData ergänzt, musst Du mir auch nicht erklären. Dass dieses technische Detail ein Problem sei, war nie die Frage. Aber immerhin weiß ich jetzt was Du mit dem Hinweis auf Schlüsselparameter überhaupt meintest, das war mir oben zu generisch um es sinnvoll zuordnen zu können.

Rolf

[pl]

hi @Rolf B

Die Frage war:

Wie kann ich per JS/Jquery alle abgesendeten Keys und Values angeben lassen?

und nicht wie man bei einem legacy POST in die Entwicklerkonsole schaut!

Die Antwort steht längst hier: https://forum.selfhtml.org/self/2018/dec/19/js-formularwerte-beim-absenden-ausgeben/1739072#m1739072

MfG

PS: Scheinbar hat sich die Frage ja geändert!

Edit Rolf B: Spitze Klammern ergänzt damit es ein Link wird

[dedlfix]

Tach!

Wie kann ich per JS/Jquery alle abgesendeten Keys und Values angeben lassen?

und nicht wie man bei einem legacy POST in die Entwicklerkonsole schaut!

Die Antwort steht längst hier: https://forum.selfhtml.org/self/2018/dec/19/js-formularwerte-beim-absenden-ausgeben/1739072#m1739072

Und sie ist nach wie vor unzureichend, weil das name-value-Pärchen vom Submit-Button fehlt.

dedlfix.

[pl]

Tach!

Wie kann ich per JS/Jquery alle abgesendeten Keys und Values angeben lassen?

und nicht wie man bei einem legacy POST in die Entwicklerkonsole schaut!

Die Antwort steht längst hier: https://forum.selfhtml.org/self/2018/dec/19/js-formularwerte-beim-absenden-ausgeben/1739072#m1739072

Und sie ist nach wie vor unzureichend, weil das name-value-Pärchen vom Submit-Button fehlt.

Nach wie vor ist das ein normales Verhalten von jQuery.serialze()!

[Auge]

Hallo

Wie kann ich per JS/Jquery alle abgesendeten Keys und Values angeben lassen?

und nicht wie man bei einem legacy POST in die Entwicklerkonsole schaut!

Die Antwort steht längst hier: https://forum.selfhtml.org/self/2018/dec/19/js-formularwerte-beim-absenden-ausgeben/1739072#m1739072

Und sie ist nach wie vor unzureichend, weil das name-value-Pärchen vom Submit-Button fehlt.

Nach wie vor ist das ein normales Verhalten von jQuery.serialze()!

… und somit nicht die Lösung des Problems.

Tschö, Auge

[pl]

Richtig! Die Lösung des Problems besteht darin, sich selbst um die Schlüsselparameter zu kümmern. Was natürlich gewisse Grundkenntnisse und ggf. auch Erfahrungen voraussetzt.

MfG

[dedlfix]

Tach!

Nach wie vor ist das ein normales Verhalten von jQuery.serialze()!

Ja, das wissen wir bereits. Und weil das so ist, ist das eben nicht die gesuchte Lösung zur Aufgabenstellung alle abgesendeten Keys und Values anzuzeigen.

dedlfix.

[Rolf B]

Hallo pl,

das Problem war:

ich habe bei einem Formular das seltsame verhalten, dass nicht alle Formularwerte im Script ankommen.

Die Problemstellung ist etwas ambivalent, man weiß nicht ob er die Werte im Client- oder Serverscript vermisst. Ich habe es als Serverscript gedeutet.

Demnach war die Frage nicht zielführend, wegen der Nachteile der von Dir verlinkten Antwort. Und das habe ich begründet und eine Alternative genannt.

Das hat mich aber abgelenkt von dem Pfad, den unser Erklärbär zu trampeln begonnen hat, und der vermutlich das meiste Lösungspotenzial hat. Immerhin bestätigt das meine Hypothese mit "Script=Serverscript".

Rolf

[Rolf B]

Nachtrag: Ich werde an diesem Thread-Teil nicht weiter teilnehmen.

Rolf

[1unitedpower]

das FormData-Objekt ist sicherlich ein Ansatz, aber wie wir aber neulich festgestellt haben, enthält es das Key-Value Paar nicht, das den submittenden Button bezeichnet (sofern über einen Button submitted wurde).

Wenn man wirklich genau sehen will, was wie zum Server geht, guckt man im Browser ins Netzwerk-Tab der Entwicklerwerkzeuge und schaut sich den Body des POST Requests an.

Könnte man das mit einem ServiceWorker auch programmatisch ermitteln?

[ursus contionabundo]

das seltsame verhalten, dass nicht alle Formularwerte im Script ankommen

Also ... entweder Du baust ein Skript a la

<?php 
header('Content-type: text/plain; charset="utf-8"');
print_r( $_GET );

(auch $_POST, $_SERVER, $_COOKIES, $_FILES, $_ENV kannst Du so ausgeben) oder schlicht eines mit:

<?php phpinfo();

oder dieses und zeigst mit dem Action-Attribut des Formulars darauf oder Du schaust in die Entwicklerwerkzeuge.

Tipp: Meistens sind es kleine Typos in den Namen... oder vergessene Namen oder halt doppelte Namen für Inputs.

Noch ein Tipp: Falls Du Daten mit GET überträgst und zugleich URL-Rewriting benutzt, dann kann es sein, das ein Item der Formulardaten einen Schlüssel (Namen) hat, der bei Rewrite ebenfalls belegt wird. Dann könnte etwas herauskommen wie:

/foo/bar.php?ort=hier&ort=oder+da

Dein Ansatz, die Daten mit JS zu überprüfen (sieh auch hier auf die Keys), hat eigentlich nur dann einen Sinn, wenn die Formulare auch dynamisch zusammengebaut werden.

[Pit]

Hallo,

Dein Ansatz, die Daten mit JS zu überprüfen (sieh auch hier auf die Keys), hat eigentlich nur dann einen Sinn, wenn die Formulare auch dynamisch zusammengebaut werden.

Ja, genau deshalb mache ich das auch. Das Formular setzt sich aus Bausteinen zusammen, je nach Vorgehensweise im Gesamtscript. Serverseitig ist klar, was ankommt, das fange ich testhalber zum Ausgeben über das $_REQUEST-Array ab. Da fehlen aber Einträge, die ich eigentlich erwartet hätte, daher will ich mal schauen, was überhaupt vom Client aus gesendet wird.

Pit

[ursus contionabundo]

Kann es sein, dass beim dynamischen Zusammenbau ein verfrühter </form>-Tag in den Code gerät?

Der Mozilla zeigt Dir auch den "berechneten" Quelltext an. STRG+a, rechte Maustaste: Auswahl-Quelltext-anzeigen.

[Pit]

Kann es sein, dass beim dynamischen Zusammenbau ein verfrühter </form>-Tag in den Code gerät?

Sollte nicht, aber unmöglich ist es auch nicht :(

Der Mozilla zeigt Dir auch den "berechneten" Quelltext an. STRG+a, rechte Maustaste: Auswahl-Quelltext-anzeigen.

Was bedeutet "berechneter" Quelltext?

Pit

[Matthias Apsel]

Hallo Pit,

Was bedeutet "berechneter" Quelltext?

Browser ergänzen z.B. optionale Tags und korrigieren fehlerhaften Quelltext.

<p>Ein Absatz,
  <p> geschachtelt.</p> 
</p>

Der FF macht daraus:

<p>Ein Absatz,</p>
<p> geschachtelt.</p> 
<p></p>

Bis demnächst
Matthias

[ursus contionabundo]

Was bedeutet "berechneter" Quelltext?

Browser ergänzen z.B. optionale Tags und korrigieren fehlerhaften Quelltext.

Und das Resultat der vielfältigen Bemühungen des JS-Interpreters fließt da auch ein...

Noch ein Tipp: im Inspektor(Name des Teil der Entwicklertools im Firefox) kann man sich das betroffene Formular auch ansehen. Der Inspektor zeigt dessen Elemente nach den Korrektur durch "mod_quirx" und eben nach den Mühen des JS-Interpreters.

Nicht per POST oder GET übertragene Werte von Formularelementen fehlen übrigens oft weil diese keinen NAME haben.

Ich weiß das sehr genau. Erspare mir tunlichst die Pein der Erinnerung als Folge einer möglichen Frage warum ich DAS so gar GENAU weiß.

[pl]

Da fehlen aber Einträge, die ich eigentlich erwartet hätte,

Welche Einträge sind das denn?

[pl]

Hallo,

ich habe bei einem Formular das seltsame verhalten, dass nciht alle Formularwerte im Script ankommen.

Wie kann ich per JS/Jquery alle abgesendeten Keys und Values angeben lassen? Kann ich das über eine Schleife machen, ohne die Keys selber zu kennen?

Nun, wenn Du die Keys nicht kennst, wie willst Du dann prüfen ob sie gesendet wurden?

MfG