Welcher Button wurde geklickt

[pl]

hi,

mit document.forms[0].addEventListener('submit', cp2bin, false) wird das Submit abgefangen. Im Formular gibt es 3 Buttons die das auslösen. Gibt es innerhalb der Funktion cp2bin eine Möglichkeit herauszukriegen welcher Button geklickt wurde?

Bitte mal um Hinwweises.

[Gunnar Bittersmann]

@@pl

mit document.forms[0].addEventListener('submit', cp2bin, false) wird das Submit abgefangen. Im Formular gibt es 3 Buttons die das auslösen. Gibt es innerhalb der Funktion cp2bin eine Möglichkeit herauszukriegen welcher Button geklickt wurde?

Ja.

Bitte mal um Hinwweises.

Für genauere Hinwweises bitte more input.

LLAP 🖖

[Rolf B]

Hallo pl,

sieht schlecht aus. Scheint eine Lücke zu sein. Oder die JavaScript-Götter halten es für unwichtig.

Die Frage ist, wie immer: was willst Du tun, kannst Du es anders lösen?

Methode und Action des POST kannst Du mit dem formAction- und formMethod-Attribut der Buttons überschreiben, wenn es Dir nur darum geht. Das funkt dann auch ohne JavaScript.

Der brute-force Ansatz (vorgeschlagen auf Stackoverflow) wäre ein click-Handler auf den Buttons, der in einem selbsterfundenen Property des Form eine "ich war's" Info hinterlässt. Der Submit-Handler müsste diese Info dann gleich wieder abräumen. Besser wüsste ich es nicht.

Rolf

[Rolf B]

Hallo pl,

es gibt noch die Möglichkeit, zu prüfen, welcher Button den Fokus hat. Das hilft Dir natürlich nicht wenn der User das Form mit ENTER in irgendeinem Input abschickt, aber dann musst Du Dir eh einen Default-Button überlegen.

function submitHandler(e) {
   let btn = e.currentTarget.querySelector("button:focus");
   ...
}

Letztlich hättest Du das jetzt aber alles selbst von der Ente bekommen können (oder vom unheiligen Bimbam, oder von der Werbeschleuder mit Bergblick).

Rolf

[pl]

he @Rolf B

funktioniert prima, danke! Ein <input> auf diese Art und Weise abzufragen geht auch.

Sinn der Aktion ist es, die Anwendung mit JS benutzerfreundlicher zu machen und auf ein Formular aufzusetzen ohne letzeres ändern zu müssen.

Also den Submit durch JS zu ersetzen. MfG

[pl]

ja @Rolf B

querySelector ist ein starkes Teil 😉

Das wars dann auch.

Für die Einen Progressive Enhancement, für mich ein sinnvoller Zeitvertreib.

Danke nochmal.

[beatovich]

hallo

hi,

mit document.forms[0].addEventListener('submit', cp2bin, false) wird das Submit abgefangen. Im Formular gibt es 3 Buttons die das auslösen. Gibt es innerhalb der Funktion cp2bin eine Möglichkeit herauszukriegen welcher Button geklickt wurde?

Bitte mal um Hinwweises.

teste mal

<button name="which_button" value="fred">Your label</button>

[Rolf B]

Hallo beatovich,

Problem ist das submit-Event, das hat das Form als currentTarget und kein Attribut, das den Auslöser des Submit verkündet. Oder hast Du was entdeckt was ich übersehen habe?

Rolf

[beatovich]

hallo

Hallo beatovich,

Problem ist das submit-Event, das hat das Form als currentTarget und kein Attribut, das den Auslöser des Submit verkündet. Oder hast Du was entdeckt was ich übersehen habe?

Mir gehts gar nicht um target oder current-target, sondern darum, dass der geklickte Button zu Formdata beiträgt.

[Rolf B]

Hallo beatovich,

auf meinem Chrome nicht. Ein input type="text" kommt, ein button oder input type="submit" nicht. Die Spec ist da etwas merkwürdig, sie reden dort von einem "submitter", der im FD eingetragen wird, und bei Stackoverflow meint jemand, der submitter sei undefiniert wenn das FormData aus JS manuell erzeugt wird. Hast Du andere Erkenntnisse?

<form method="POST" action="/foo">
<input name="foo" type="test">
<button id="b1" name="btn1" value="btn1">Btn1</button>
<button id="b2" name="btn2" value="btn2">Btn2</button>
<button id="b3" name="btn3" value="btn3">Btn3</button>
</form>

document.querySelector("form").addEventListener("submit", captureSubmit); 

function captureSubmit(e) {
   let f = new FormData(e.currentTarget);
   ["foo", "btn1", "btn2", "btn3"].forEach(name =>  console.log(name + ": " + f.get(name)));
   e.preventDefault();
}

Ausgabe:

foo: bar
btn1: null
btn2: null
btn3: null

Rolf

[Gunnar Bittersmann]

@@Rolf B

Was mache ich falsch?

U.a. document.querySelector("form") – wo das Ding doch schon mit document.forms[0] zur Verfügung steht.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Kann mir mal jemand erklären, warum man hier mit Minuspunkten überhauft wird, wenn man den Hinweis gibt, dass es wenig sinnvoll ist, die Nadel im Heuhaufen zu suchen, wenn man sie bereits in der Hand hält?

Oder einfach bloß mausgerutscht?

LLAP 🖖

[beatovich]

hallo

@@Gunnar Bittersmann

Kann mir mal jemand erklären, warum man hier mit Minuspunkten überhauft wird, wenn man den Hinweis gibt, dass es wenig sinnvoll ist, die Nadel im Heuhaufen zu suchen, wenn man sie bereits in der Hand hält?

Oder einfach bloß mausgerutscht?

Nö. Aber nicht durch mich. Du sollst eben sprachlich wieder zurechtgerückt werden.

Ich übrigens auch.

[Gunnar Bittersmann]

@@beatovich

Du sollst eben sprachlich wieder zurechtgerückt werden.

1. Das mag ja sein.

Ich übrigens auch.

2. Das auch. 😆

3. Wird 1. kaum gelingen. 😈

4. Last, but not least: Ich sehe nichts, was in diesem Fall sprachlich wieder zurechtgerückt werden müsste.

LLAP 🖖

[Rolf B]

Hallo Gunnar,

Du wurdest von mir mit einem Minuspunkt überhäuft, weil du die Fragestellung klar erkannt und zielsicher missachtet hast.

So was geht mir auf den Keks. Minus wie „für die Frage nicht hilfreich“.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Du wurdest von mir mit einem Minuspunkt überhäuft, weil du die Fragestellung klar erkannt und zielsicher missachtet hast. […] Minus wie „für die Frage nicht hilfreich“.

Die Fragestellung hattest du mit Beat diskutiert; da wollte ich mich gar nicht reinhängen.

So was geht mir auf den Keks.

Dass man hier ungefragt Verbesserungsvorschläge bekommt, ist ein Feature dieses Forums, kein Bug. Es ist bedauerlich, wenn du das anders siehst.

LLAP 🖖

[beatovich]

hallo

@@Rolf B

Du wurdest von mir mit einem Minuspunkt überhäuft, weil du die Fragestellung klar erkannt und zielsicher missachtet hast. […] Minus wie „für die Frage nicht hilfreich“.

Die Fragestellung hattest du mit Beat diskutiert; da wollte ich mich gar nicht reinhängen.

So was geht mir auf den Keks.

Dass man hier ungefragt Verbesserungsvorschläge bekommt, ist ein Feature dieses Forums, kein Bug. Es ist bedauerlich, wenn du das anders siehst.

Ach komm, die rhetorische Komponente willst du aber jetzt nicht wegreden.

Welche Verbesserung siehst du denn bei document.forms gegenüber querySelector?

[Gunnar Bittersmann]

@@beatovich

Welche Verbesserung siehst du denn bei document.forms gegenüber querySelector?

Das sagte ich doch schon: „dass es wenig sinnvoll ist, die Nadel im Heuhaufen zu suchen, wenn man sie bereits in der Hand hält“.

• die Nadel: das form-Elementobjekt
• der Heuhaufen: das DOM
• die Hand: document.forms

Unnütze Operationen auf dem DOM kosten sinnlos Ausführungszeit und Strom (Akku). Beides negative Auswirkungen für den Nutzer.

LLAP 🖖

[beatovich]

hallo

@@beatovich

Welche Verbesserung siehst du denn bei document.forms gegenüber querySelector?

Das sagte ich doch schon: „dass es wenig sinnvoll ist, die Nadel im Heuhaufen zu suchen, wenn man sie bereits in der Hand hält“.

• die Nadel: das form-Elementobjekt
• der Heuhaufen: das DOM
• die Hand: document.forms

Unnütze Operationen auf dem DOM kosten sinnlos Ausführungszeit und Strom (Akku). Beides negative Auswirkungen für den Nutzer.

Da magst du recht haben im konkreten Fall. Im praktischen Fall wird man aber ein bestimmtes Formular nicht anhand eines form indexes suchen. Das wäre sehr unzuverlässig.

[Orlok]

Hallo beatovich

Da magst du recht haben im konkreten Fall. Im praktischen Fall wird man aber ein bestimmtes Formular nicht anhand eines form indexes suchen. Das wäre sehr unzuverlässig.

Muss man ja auch nicht.

<form id="name">

Wenn du dem Form eine ID gibst, kannst du es in der von document.forms zurückgegebenen HTMLCollection auch darüber ansprechen:

const form = document.forms.name;

Wenn die ID Zeichen enthält, die in Eigenschaftsnamen nicht erlaubt sind, kannst du die Klammernotation verwenden:

const form = document.forms['namespace-name'];

Die beiden Varianten mit Index oder ID auf das form zuzugreifen korrespondieren mit den beiden Methoden item und namedItem der HTMLCollection-Schnittstelle. Du könntest also auch schreiben:

const form = document.forms.namedItem('name');

Wäre aber unnötig umständlich.

Nebenbei bemerkt ist document.forms nicht die einzige nützliche Sammlung von Elementen.

Unter anderen gibt es noch:

• document.scripts gibt eine Sammlung der Skriptelemente.

• document.images gibt eine Sammlung der Bilder.

• document.links sammelt a und area-Elemente mit href-Attribut.

Siehe auch 3.1.1 The document Object.

Viele Grüße,

Orlok

[beatovich]

hallo

Der vollständigkeit halber: Jede id im HTML erzeugt eine Elementreferenz innerhalb des window Objekts. Ob das einem gefällt, ist aber eine andere Frage.

[pl]

hallo

Der vollständigkeit halber: Jede id im HTML erzeugt eine Elementreferenz innerhalb des window Objekts. Ob das einem gefällt, ist aber eine andere Frage.

Progressive Enhancement eines Formulars kann ja auch nicht sein, daß man das ganze <form> hinsichtlich dessen überarbeitet und mit IDs bestickt. PE muss mit dem funktionieren was vorhanden ist und zwar so, daß man es eben nicht verändern muss. Ergo kann man nicht davon ausgehen, daß das <form> per ID adressierbar ist.

Und idealerweise wird JS auch nicht ins HTML getippt sondern über eine externe Datei eingebunden.

Das ist ja das was hier auch tagtäglich gepredigt wird. Da hab ich es nunmalso gemacht und schon geht das Geschrei wieder los.

Aber danke an Deinen Eidgenossen Erich von Zofingen der in solchen Dingen stets zu sagen pflegte: Ein Kritiker ist wie eine Henne die gackert wenn andere Hühner Eier legen.

MfG

[beatovich]

hallo

Der vollständigkeit halber: Jede id im HTML erzeugt eine Elementreferenz innerhalb des window Objekts. Ob das einem gefällt, ist aber eine andere Frage.

Progressive Enhancement eines Formulars kann ja auch nicht sein, daß man das ganze <form> hinsichtlich dessen überarbeitet und mit IDs bestickt. PE muss mit dem funktionieren was vorhanden ist und zwar so, daß man es eben nicht verändern muss. Ergo kann man nicht davon ausgehen, daß das <form> per ID adressierbar ist.

Doch, davon sollst du ausgehen, wenn im form Element eine id definiert ist.

Ich will aber nicht empfehlen alles mit id-Attributen zu bestücken. Im Gegenteil. Aber der Betriebssicherheit halber kommt man nicht darum herum, einmaligen Komponenten eine ID in irgend einer Form zu geben.

Und idealerweise wird JS auch nicht ins HTML getippt sondern über eine externe Datei eingebunden.

Das spielt keine Rolle für das Verhalten.

[pl]

hallo

Doch, davon sollst du ausgehen, wenn im form Element eine id definiert ist.

für Progressive Enhancement ist es unerheblich auf welche Art und Weise das Formular selektiert wird.

Und idealerweise wird JS auch nicht ins HTML getippt sondern über eine externe Datei eingebunden. Das spielt keine Rolle für das Verhalten.

Hinsichtlich native PE ist das auch egal. Es hängen jedoch eine ganze Reihe weitere Dinge dran wie z.B. Konfigurierbarkeit, Wartbarkeit, Skalierbarkeit, Lesbarkeit, Teamarbeit, Wirtschaftlichkeit um nur ein paar zu nennen.

MfG

[Gunnar Bittersmann]

@@Orlok

<form id="name">

Wenn du dem Form eine ID gibst

Ich hätte gesagt: Wenn du Dem Formular einen Namen gibst.

kannst du es in der von document.forms zurückgegebenen HT.MLCollection auch darüber ansprechen:

const form = document.forms.name;

Aber in der Tat, ID geht auch. document.forms.<name> nimmt dasjenige Fomular, was zuerst im DOM gefunden wird, egal ob mit id="<name>" oder name="<name>".

<form id="foo" name="bar"></form>
<form id="bar" name="foo"></form>

console.log(document.forms.foo.id); // foo
console.log(document.forms.bar.id); // foo

console.log(document.forms.foo.name); // bar
console.log(document.forms.bar.name); // bar

Nachtrag: im Firefox ist das so.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Aber in der Tat, ID geht auch. document.forms.<name> nimmt dasjenige Fomular, was zuerst im DOM gefunden wird, egal ob mit id="<name>" oder name="<name>".

Nachtrag: im Firefox ist das so.

In Safari und Chrome hingegen:

<form id="foo" name="bar"></form>
<form id="bar" name="foo"></form>

console.log(document.forms.foo.id);   // foo
console.log(document.forms.bar.id);   // bar
console.log(document.forms.foo.name); // bar 
console.log(document.forms.bar.name); // foo

WebKits und Chromium präferieren ID gegenüber Namen.

Hm, welches Verhalten ist nun jetzt das richtige? 🤔 #lazyweb

LLAP 🖖

[beatovich]

hallo

@@Gunnar Bittersmann

Aber in der Tat, ID geht auch. document.forms.<name> nimmt dasjenige Fomular, was zuerst im DOM gefunden wird, egal ob mit id="<name>" oder name="<name>".

Nachtrag: im Firefox ist das so.

In Safari und Chrome hingegen:

<form id="foo" name="bar"></form>
<form id="bar" name="foo"></form>

console.log(document.forms.foo.id);   // foo
console.log(document.forms.bar.id);   // bar
console.log(document.forms.foo.name); // bar 
console.log(document.forms.bar.name); // foo

WebKits und Chromium präferieren ID gegenüber Namen.

Du kannst auch gegentesten ohne Bezug auf forms:

// Firefox

console.log(foo.id);   // foo
console.log(bar.id);   // bar
console.log(foo.name); // bar 
console.log(bar.name); // foo

Dass name eine Referenz direkt in window erzeugt, ist speziell für das form Element.

[dedlfix]

Tach!

Welche Verbesserung siehst du denn bei document.forms gegenüber querySelector?

Das sagte ich doch schon: „dass es wenig sinnvoll ist, die Nadel im Heuhaufen zu suchen, wenn man sie bereits in der Hand hält“.

• die Nadel: das form-Elementobjekt
• der Heuhaufen: das DOM
• die Hand: document.forms

Hier formulierst du die Sache deutlich angemessener als im ersten Posting, als du es als Fehler dargestellt hast. Eine Vorgehensweise, die zum selben Ergebnis kommt wie eine andere, kann nicht falsch sein. Beide sind gleichermaßen effektiv. Sie können sich aber in der Effizienz unterscheiden.

Unnütze Operationen auf dem DOM kosten sinnlos Ausführungszeit und Strom (Akku). Beides negative Auswirkungen für den Nutzer.

Fällt der Unterschied so deutlich aus? Ist es wirklich so, dass der Browser die o.g. Strukturen direkt vorhält und nicht erst beim Zugreifen on-the-fly erzeugt? Und muss für IDs ständig das DOM geparst werden, ohne dass er eine interne Liste pflegt?

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Hier formulierst du die Sache deutlich angemessener als im ersten Posting, als du es als Fehler dargestellt hast.

Das ist es auch. Es ist eine falsche Vorgehensweise; es ist ein Fehler. Kein syntaktischer, aber ein methodischer.

Zu Falschem sage ich „falsch“, einen Fehler nenne ich einen Fehler. Da irgendwas schönzureden ist nicht mein Ding.

Eine Vorgehensweise, die zum selben Ergebnis kommt wie eine andere, kann nicht falsch sein.

Riesige Löcher in die Erde reißen, Braunkohle abbaggern, um sie im Kraftwerk zu verheizen, kann nicht falsch sein? Kommt ja zum selben Ergebnis wie Windräder und Photovoltaik: Strom in der Steckdose. Merkste selber, dass deine Argumentation falsch ist?

Unnütze Operationen auf dem DOM kosten sinnlos Ausführungszeit und Strom (Akku). Beides negative Auswirkungen für den Nutzer.

Fällt der Unterschied so deutlich aus?

Je nach Größe des DOMs.

Aber es geht nicht mal darum, wie groß der Unterschied ist, sondern Unnötiges prinzipiell zu vermeiden. Es wäre sinnlos, verschiedene Programmiertechniken zu meistern: eine gute für großes DOM und eine schludrige für kleines.

Und es geht wohlgemerkt auch nicht darum, durch Mikrooptimierung die Lesbarkeit des Codes zu verschlechtern. Das sollte man nicht tun.

Ist es wirklich so, dass der Browser die o.g. Strukturen direkt vorhält und nicht erst beim Zugreifen on-the-fly erzeugt?

Natürlich hält der Browser die Strukturen vor: das DOM. In dieser Struktur will ein Element aber erstmal gefunden werden.

Und muss für IDs ständig das DOM geparst werden, ohne dass er eine interne Liste pflegt?

Bei IDs hast du wohl einen Punkt. Darum ging’s hier aber nicht.

LLAP 🖖

[dedlfix]

Tach!

Hier formulierst du die Sache deutlich angemessener als im ersten Posting, als du es als Fehler dargestellt hast.

Das ist es auch. Es ist eine falsche Vorgehensweise; es ist ein Fehler. Kein syntaktischer, aber ein methodischer.

Das ist nur eine Aussage, aber kein Beweis in der Sache.

Eine Vorgehensweise, die zum selben Ergebnis kommt wie eine andere, kann nicht falsch sein.

Riesige Löcher in die Erde reißen, Braunkohle abbaggern, um sie im Kraftwerk zu verheizen, kann nicht falsch sein? Kommt ja zum selben Ergebnis wie Windräder und Photovoltaik: Strom in der Steckdose. Merkste selber, dass deine Argumentation falsch ist?

Es wäre sehr nett, wenn du mir überlassen würdest, was ich merke und was nicht, danke. Ich sehe hier, den Vergleich einer Technik mit deren Nebenwirkungen zu einer anderen Technik, ohne Nebenwirkungen zu betrachten. Das trägt für mich nichts in der Sache bei.

In der eigentlichen Argumentation war auch nicht von Nebenwirkungen die Rede. Wenn also die Nebenwirkungen zum Effekt hinzugezählt werden sollen, dann ist es sicherlich günstig, sie auch zu benennen, damit nicht nur zwei beleglose Aussagen gegenüberstehen.

Unnütze Operationen auf dem DOM kosten sinnlos Ausführungszeit und Strom (Akku). Beides negative Auswirkungen für den Nutzer.

Fällt der Unterschied so deutlich aus?

Je nach Größe des DOMs.

Aber es geht nicht mal darum, wie groß der Unterschied ist, sondern Unnötiges prinzipiell zu vermeiden. Es wäre sinnlos, verschiedene Programmiertechniken zu meistern: eine gute für großes DOM und eine schludrige für kleines.

Definiere unnötig. Wenn ich lediglich die Oberfläche betrachte, ohne das zu berücksichtigen, was im Verborgenen nötig ist, wie kann ich dann das Ergebnis beurteilen?

Ist es wirklich so, dass der Browser die o.g. Strukturen direkt vorhält und nicht erst beim Zugreifen on-the-fly erzeugt?

Natürlich hält der Browser die Strukturen vor: das DOM. In dieser Struktur will ein Element aber erstmal gefunden werden.

Ja, und das ist beim Zugriff über document.forms inwiefern nicht nötig? Wenn der Browser beim Parsen des Dokuments bereits diese Verknüpfungen angelegt hat, dann kann er das genauso für die IDs der Elemente tun. In beiden Fällen kann auch das Gegenteil zutreffen, dass nichts vorab angelegt wurde und bei jedem Zugriff das DOM durchsucht wird, dass also document.forms lediglich syntactic sugar ist.

Ich weiß es nicht, was am Ende der Fall ist, deswegen hake ich hier nach, damit ich mir ein Bild machen kann zum "falsch" oder vielleicht doch nicht.

Und muss für IDs ständig das DOM geparst werden, ohne dass er eine interne Liste pflegt?

Bei IDs hast du wohl einen Punkt. Darum ging’s hier aber nicht.

Was für IDs gilt, kann prinzipiell auch für Elemente gelten, noch dazu bei solchen, für die es bereits eine Zugriffsabkürzung gibt. Wer sagt denn, dass document.querySelector('form') das DOM durchsucht und nicht vielleicht eine Abkürzung über document.forms nimmt?

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Natürlich hält der Browser die Strukturen vor: das DOM. In dieser Struktur will ein Element aber erstmal gefunden werden.

Ja, und das ist beim Zugriff über document.forms inwiefern nicht nötig?

Zum einen ist das eine ein Baum, das andere eine Liste. Entscheidender dürfte aber sein, dass das eine ein Heuhaufen ist, das andere nur ganz wenige Halme.

Wer sagt denn, dass document.querySelector('form') das DOM durchsucht und nicht vielleicht eine Abkürzung über document.forms nimmt?

Das wäre denkbar. Da steckt aber ein „Vielleicht“ drin. Kein Grund, als Programmierer auf diese hypothetische Möglichkeit zu setzen und nicht selbst die Abkürzung einzuschlagen.

LLAP 🖖

[dedlfix]

Tach!

Wer sagt denn, dass document.querySelector('form') das DOM durchsucht und nicht vielleicht eine Abkürzung über document.forms nimmt?

Das wäre denkbar. Da steckt aber ein „Vielleicht“ drin. Kein Grund, als Programmierer auf diese hypothetische Möglichkeit zu setzen und nicht selbst die Abkürzung einzuschlagen.

Ich habe da zwar ein Vielleicht drin, aber in deiner Aussage steckt auch noch kein Beweis, dass document.forms bereits zugriffsfertig existiert. Es ist erstmal nur augenscheinlich vorhanden.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Ich habe da zwar ein Vielleicht drin, aber in deiner Aussage steckt auch noch kein Beweis, dass document.forms bereits zugriffsfertig existiert. Es ist erstmal nur augenscheinlich vorhanden.

Hm, ich sagte: document.forms > document.querySelector('form') (wobei > für „besser als“ steht).

Du meinst, dass document.querySelector('form') genauso gut sein könnte, wenn das intern auf document.forms zurückgreift. (Ein Methodenaufruf mehr sei geschenkt.)

Oder dass document.forms genauso schlecht sein könnte, weil beim Parsen des Dokuments gar keine Liste der vorhandenen Formulare angelegt wird, sondern erst bei Bedarf im Heuhaufen genannnt DOM gesucht wird.

Also dass gilt document.forms ≥ document.querySelector('form').

Beides halte ich für sehr unwahrscheinlich, wobei ich ersterem noch mehr Chancen einräumen würde. Man kann es ohne in die JS-Engine-Interna reinzuschauen nicht gänzlich ausschließen, ich würde aber meinen Arsch verwetten, dass das Gleichheitszeichen nicht gilt.

Auf keinen Fall gilt aber document.forms < document.querySelector('form').

Ich halte meine Empfehlung aufrecht, document.forms zu verwenden und nicht document.querySelector('form').

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Ich halte meine Empfehlung aufrecht, document.forms zu verwenden und nicht document.querySelector('form').

Auch wenn in Empfehlung der Fehler mit drinzustecken scheint, ist diese Aussage um Längen besser und netter als der Stein des Anstoßes.

Bis demnächst
Matthias

[dedlfix]

Tach!

Ich halte meine Empfehlung aufrecht, document.forms zu verwenden und nicht document.querySelector('form').

Das ist ja auch ok so, das als Empfehlung auszusprechen. Ich würde das auch so verwenden, wenn ich dazu Bedarf hätte. Der Stein des Anstoßes war, den querySelector als falsch hinzustellen, ohne dafür einen Beleg beibringen zu können. Es war vielleicht nur eine flapsige Formulierung, inspiriert durch die Frage von Rolf B. Aber wie du siehst, kam sie genausowenig gut bei ihm an, wie die Minusbewertung dafür bei dir.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Ich halte meine Empfehlung aufrecht, document.forms zu verwenden und nicht document.querySelector('form').

Das ist ja auch ok so, das als Empfehlung auszusprechen.

Wer meiner Empfehlung nicht folgt, der begeht einen Fehler. 😈

Ernsthaft: Ich halte deine Einwände für so unwahrscheinlich, dass ich die Verwendung von document.querySelector('form') hier weiterhin als Fehler ansehe.

LLAP 🖖

[Rolf B]

Hallo Gunnar,

es juckt mich ja, an dein Podest noch ein Minus zu kleben.

Ich erkenne durchaus an, dass document.forms hier der bessere Weg ist. Kürzerer Code, kein magic string, und sehr wahrscheinlich auch schnellere Laufzeit. querySelector ist also weniger effizient.

Aber: Ineffektiv = Fehler ≠ Ineffizient

Dass querySelector('form') ineffektiv sei, das wirst Du nicht behaupten wollen. Es wäre ineffektiv, wenn das Dokument mehrere Forms enthielte und ich eigentlich das zweite Form bräuchte. Das war hier aber nicht Thema.

(@Christian Kruse: Wieso lässt das Forum das ! bzw : stehen, wenn ich != oder := tippe und im Sonderzeichen-Popup das ≠ oder ≈ auswähle?)

Rolf

[Christian Kruse]

Hallo Rolf,

(@Christian Kruse: Wieso lässt das Forum das ! bzw : stehen, wenn ich != oder := tippe und im Sonderzeichen-Popup das ≠ oder ≈ auswähle?)

Weil der Trigger-Charakter das = ist.

LG,
CK

[1unitedpower]

Unnütze Operationen auf dem DOM kosten sinnlos Ausführungszeit und Strom (Akku). Beides negative Auswirkungen für den Nutzer.

Fällt der Unterschied so deutlich aus?

Je nach Größe des DOMs.

In diesem Fall, ist der Unterschied in der Tat bemerkenswert.

JSPerf Benchmark

Es gibt aber auch einen semantischen Unterschied, document.forms liefert eine HTMLCollection, das ist potenziell anfälliger für Fehler als eine NodeList, die man durch document.querySelectorAll bekommt, weil sie sich automatisch aktualisiert, wenn sich das DOM ändert.

[dedlfix]

Tach!

Unnütze Operationen auf dem DOM kosten sinnlos Ausführungszeit und Strom (Akku). Beides negative Auswirkungen für den Nutzer.

Fällt der Unterschied so deutlich aus?

Je nach Größe des DOMs.

In diesem Fall, ist der Unterschied in der Tat bemerkenswert.

JSPerf Benchmark

Das ist doch mal eine Aussage. Da gibts also noch Potential, ähnlich wie bei den IDs, einen Index aufzubauen. Ob sich das lohnt, ist eine andere Frage, die die Browserhersteller vermutlich besser beantworten können. Wie sieht aber der Unterschied aus, wenn das Formular per ID gesucht wird?

dedlfix.

[Gunnar Bittersmann]

@@1unitedpower

Es gibt aber auch einen semantischen Unterschied, document.forms liefert eine HTMLCollection, das ist potenziell anfälliger für Fehler als eine NodeList, die man durch document.querySelectorAll bekommt, weil sie sich automatisch aktualisiert, wenn sich das DOM ändert.

Das wäre nur dann relevant, wenn man Formulare mit JavaScript ins DOM hängt. Wenn man aber das tut und sich die Referenzen darauf nicht merkt, sondern wenn man ein Formular später wieder braucht, sich das aus dem DOM raussucht, dann macht man auch was ziemlich falsch.

LLAP 🖖

[Matthias Apsel]

Hallo 1unitedpower,

Es gibt aber auch einen semantischen Unterschied, document.forms liefert eine HTMLCollection, das ist potenziell anfälliger für Fehler als eine NodeList, die man durch document.querySelectorAll bekommt, weil sie sich automatisch aktualisiert, wenn sich das DOM ändert.

Naja, es ist wohl eher nicht davon auszugehen, dass auf einer Seite vogelwild Förmchen-Wechsel-Dich gespielt wird.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Es gibt aber auch einen semantischen Unterschied, document.forms liefert eine HTMLCollection, das ist potenziell anfälliger für Fehler als eine NodeList, die man durch document.querySelectorAll bekommt, weil sie sich automatisch aktualisiert, wenn sich das DOM ändert.

Naja, es ist wohl eher nicht davon auszugehen, dass auf einer Seite vogelwild Förmchen-Wechsel-Dich gespielt wird.

Naja, bei einer SPA passiert das schon.

Aber wie gesagt, ist auch dann die Verwendung von document.querySelector / document.querySelectorAll falsch.

LLAP 🖖

[dedlfix]

Tach!

Naja, es ist wohl eher nicht davon auszugehen, dass auf einer Seite vogelwild Förmchen-Wechsel-Dich gespielt wird.

Naja, bei einer SPA passiert das schon.

Zumindest bei Angular ist das Zugreifen auf Elemente (so es überhaupt derart explizit notwendig ist) einfacher, als sie sich händisch mit document.querySelector() und Co. herauszusuchen.

Aber wie gesagt, ist auch dann die Verwendung von document.querySelector / document.querySelectorAll falsch.

Für mich ist eher deine Sturheit in der Angelegenheit falsch.

dedlfix.

[Orlok]

Ach Rolf …

Minus wie „für die Frage nicht hilfreich“.

… du weißt doch, „uns gibt es nur mit Meinung und ungebetener Beratung.“ — Chräcker

Gunnars Hinweis mag dir bei deiner eigentlichen Frage nicht weitergeholfen haben, aber er war fachlich richtig. Deswegen einen Minuspunkt zu verteilen ist doch auch nicht sinnvoll. Hättest es ja auch einfach stehen lassen und ignorieren können. So habe ich mich gezwungen gesehen, deine −1 durch ein +1 meinerseits auszugleichen. :-)

Was man in so einer Situation gerne übersieht ist, dass es sich hier um eine öffentliche Veranstaltung handelt. Man weiß nie, wer alles mitliest und gegebenenfalls Code ungeprüft übernimmt. Deswegen sind solche kleinen Hinweise durchaus wertvoll. Wenn nicht für dich, dann doch vielleicht für jemand anderes.

Viele Grüße,

Orlok

[pl]

Im Selfwiki ist ja auch von Progressive Enhancment die Rede. Was jedoch fehlt sind ein paar Beispiele und Ideen für Lösungsansätze.

Die Frage ob ein Form per document.forms oder querySelector adressiert wird, dürfte auf jeden Fall auch Bestandteil eines diesbezüglichen Wikiartikels sein.

MfG

[dedlfix]

Tach!

Im Selfwiki ist ja auch von Progressive Enhancment die Rede. Was jedoch fehlt sind ein paar Beispiele und Ideen für Lösungsansätze.

Die Frage ob ein Form per document.forms oder querySelector adressiert wird, dürfte auf jeden Fall auch Bestandteil eines diesbezüglichen Wikiartikels sein.

Inwiefern siehst du da ein Progressive Enhancement? document.forms ist uralt. document.querySelector() ist zwar jünger (außerdem gibts noch das ebenfalls uralte document.getElementsByName()), aber das zu verwenden bringt keinerlei Vorteil im Sinne von Verbesserung in neueren Browsern gegenüber der bisherigen Technik (eventuelle Unterschiede in den internen Implementierungen nicht weiter beachtend).

dedlfix.

[beatovich]

hallo

auf meinem Chrome nicht. Ein input type="text" kommt, ein button oder input type="submit" nicht. Die Spec ist da etwas merkwürdig, sie reden dort von einem "submitter", der im FD eingetragen wird, und bei Stackoverflow meint jemand, der submitter sei undefiniert wenn das FormData aus JS manuell erzeugt wird. Hast Du andere Erkenntnisse?

Hab gleich selber getestet.

<form onsubmit="console.log( new FormData(this) );return false;">
<input type="text" name="text" value="i am text">
<button type="submit" name="which_button" value="fred">Fred</button>
</form>

Die Konsole zeigt nicht mal das Textfeld an.

[pl]

hi @Rolf B

auf meinem Chrome nicht. Ein input type="text" kommt, ein button oder input type="submit" nicht. Die Spec ist da etwas merkwürdig, sie reden dort von einem "submitter", der im FD eingetragen wird, und bei Stackoverflow meint jemand, der submitter sei undefiniert wenn das FormData aus JS manuell erzeugt wird. Hast Du andere Erkenntnisse?

jQuery.serialize() verhält sich genauso wie FD: <input type="submit"> und <button> werden nicht übernommen bzw. übertragen. Das ist ja auch logisch und gut so, wenn die allesamt übertragen würden könnte man die ja gar nicht mehr unterscheiden serverseitig.

Was der bei Stackoverflow mit 'submitter' meinte, nenne ich Schlüsselparameter, also die legt der Entwickler fest und im Fall FD o.a. JS-Serializer sind die als name+value händisch anzuhängen, z.B. mit FD.append();

MfG

PS: Schlüsselparameter serverseitig. Also welcher button gecklickt wurde:

    my $self = shift;
    if( $self->param('cp2bin') ){
        my $cp = $self->param('cp');
        $self->{STASH}{cp} = $self->trim( $self->ents($cp) );
        $self->{STASH}{bin} = $self->cp2bin($cp) || do{
            my $f = $@ =~ /(.*?)at/ ? $1 : 'Fehlerhafte Eingabe!';
            return $self->errmsg("$f");
        };
    }
    elsif($self->param('bin2cp')){
        my $bin = $self->param('bin');
        $self->{STASH}{bin} = $self->trim($self->ents($bin));
        $self->{STASH}{cp} = $self->bin2cp($bin) || do{
            my $f = $@ =~ /(.*?)at/ ? $1 : 'Fehlerhafte Eingabe!';
            return $self->errmsg("$f");
        };
    }
    elsif( $self->param('re') ){ $self->redirect }
    else{ $self->errmsg('Unbekannter Parameter!') }

[Rolf B]

Hallo pl,

du wechselst das Thema. Serverseitig sind die Daten da, weil der Name des Submit-Buttons gepostet wird.

Clientseitig finde ich das blöd gelöst - der Browser weiß ja ganz genau was den Submit ausgelöst hat (Beweis: Dein Perl-Script) und könnte es darum im submit-Handler auch den FormData bereitstellen. Nach meiner Recherche von heut nachmittag tat Chrome das wohl auch mal. Aber sie habe es in die 50ern ausgebaut und zwingt statt dessen die Entwickler zu einem anderen Konstrukt.

Wenn Du mit einer serverseitigen Erkennung auskommst und es im JavaScript nicht brauchst, ist das ja auch eine Lösung.

Rolf

[pl]

Hi @Rolf B

du wechselst das Thema

Nicht ich, sondern Beat und Du hatte das Thema gewechselt: Zu FormData!

Infolgedessen ging es mir darum, darauf hinzuweisen, daß man seine Schlüsselparameter dem FormDataobjekt selbst hinzufügen muss. Weil

1. new FormData(form) nur die Nutzdaten erfasst
2. also nicht den name+value des geklickten Buttons
3. Schlüsselparameter notwendig sind zur Ablaufsteuerung

und es ohnehin gut ist, Nutzdaten von Schlüsselparametern zu trennen.

In der hier dargestellten Anwendung wird zwar nichts parametrisiert aber das Prinzip der Logik ist doch dasselbe:

Herauszufinden welcher Button geklickt wurde.

Womit wir wieder beim Thema wären. MfG

[Gunnar Bittersmann]

@@pl

Dein Postin war erneut falsch formatiert:

Ich hab das mal wieder berichtigt. Wäre schön, wenn du das selbst hinbekämst.

LLAP 🖖

[pl]

hi @Rolf B

Wenn Du mit einer serverseitigen Erkennung auskommst und es im JavaScript nicht brauchst, ist das ja auch eine Lösung.

Es geht immer um Beides! Egal ob ein serverseitiger oder clientseitiger Prozess gestartet werden soll, die Prozesskontrolle ist nur möglich wenn bekannt ist welcher Button geklickt wurde. Außerdem gibt es ja nicht nur name+value an Schaltflächen sondern auch in angehängten Querystrings in <a href>.

MfG

[pl]

hi @Rolf B

hier kannst Du legacy form-data und FormData nebeneinander testen. Der Submibutton hat name=control und value=1

Übertragen wird dieses Pärchen nur bei einem native Submit also was der Browser selber tut. FormData nimmt den Buton nicht mit, da verhalten sich bei mir FF und Chrome gleich.

MfG

[pl]

hallo

Mir gehts gar nicht um target oder current-target, sondern darum, dass der geklickte Button zu Formdata beiträgt.

FormData ist hier gar nicht im Spiel. Vielmehr ist ein ganz normales <form> gegeben was 3 Submitbuttons hat die einen serverseitigen Prozess auslösen. Dafür wird der Default-Enctype benutzt und ansonsen haben sowohl die <input>-Felder als auch die Buttons jeweils name+value Attribute. Beim Submit geht also alles zusammen über den Default Enctype ab zum Server und der schickt ein mit dem Ergebnis gerendertes HTMLTemplate reture.

Ziel meines heutigen Zeitvertreibes war es, den serverseitigen Prozess komplett durch einen clientseitigen Prozess zu ersetzen. Das heißt, daß man hierzu gar keinen Enctype braucht, weil die Eingaben den Browser nicht verlassen sondern an Ort und Stelle verarbeitet werden.

MfG

[pl]

habe ich hier den gesamten JS Code ausgelagert.

Nun, wenn diese JS Datei im <head>-Bereich geladen wird, kann ja das <form> gar nicht adressiert werden weil das noch gar nicht vorhanden ist.

Also muss die HTML Datei ja doch geändert werden, nun gut. Die Frage ist, was würdet Ihr denn empfehlen, den Eventhandler document.forms[0].addEventListener('submit', cc, false); setzen oder das JS Script am Ende der HTML Datei einbinden?

MfG

[Matthias Apsel]

Hallo pl,

habe ich hier den gesamten JS Code ausgelagert.

Man sieht leider keine JS-Datei.

Nun, wenn diese JS Datei im <head>-Bereich geladen wird, kann ja das <form> gar nicht adressiert werden weil das noch gar nicht vorhanden ist.

Also muss die HTML Datei ja doch geändert werden, nun gut.

Warum?

document.addEventListener('DOMContentLoaded', init); 
function init() { /* */ }

Bis demnächst
Matthias