Robert B.: Braucht noch wer jQuery?

0184

Braucht noch wer jQuery?

  1. 1
  2. 0
    1. 0
  3. 2
    1. 0
    2. 1
      1. 2
        1. 0
          1. 1
            1. 2
      2. 0
        1. 1
        2. 0
    3. 2
      1. 1
        1. 0
        2. 0
  4. 1
  5. 7

    Ein gutes Wort für jQuery

    1. 0
      1. 1
  6. 0
    1. 0
      1. 0
        1. 0
          1. 0
            1. 0
              1. 0
                1. 0
                  1. 0
                    1. 0
                      1. 0
                        1. 0
                        2. 0
                        3. 0
                          1. -2
                          2. 0
                            1. 0
                              1. -1
                                1. 0
                                2. 0
                                  1. 0
                                    1. 4
                                    2. 0
                                      1. -1
                                        1. 0
                                        2. 0
                                          1. 0
                                          2. 0
                                            1. 0
                                            2. 0
                                              1. 0
                                            3. 1
                                              1. 0
                                                1. 2
                                                  1. 0
                                                    1. 1
                                                      1. -1
                            2. 0
                            3. 2
                        4. 0
                          1. 0
                            1. 0
                              1. 0
                                1. 1
                                  1. 0

                                    jquery vs modern JS

                                    1. 2
                                      1. 0
                        5. 0
                          1. 0
                            1. 0
                              1. 0
                                1. 1
                                  1. 0
                                    1. 0
                      2. 0
                        1. 0
                          1. 0
                            1. 0
          2. 0
      2. 0
        1. 0
          1. 0
            1. 1
              1. 0

                FromData toString und Kontextwechsel

                1. 4
                  1. 0
                    1. 2
                      1. -1
                        1. 1
                          1. 0
                    2. 0

                      Typisch für OOP Overload

                      1. 0
                2. 2
                  1. 0
                    1. 0
                  2. 0
                    1. 0
                      1. 0
                        1. 1
                        2. 1
                          1. 0
                            1. 0
                              1. 0
                                1. 0
                          2. 0
                            1. 2
                          3. 0
                            1. 0
                              1. 0
                            2. 0
                              1. 1
    2. 0
      1. 2
        1. 0
          1. 4
            1. 0
              1. 0
                1. -1
                  1. 0
                    1. 0
                      1. 0
                        1. -1
                          1. 3
                          2. 6
                            1. -3
                              1. 4
                                1. -2
                                  1. 0
                                    1. -1
                                      1. 2
                                        1. 0
                                          1. 1
                                            1. 0
                                          2. 2
                                            1. -2
                                              1. 2
                                                1. -2
                                                  1. 2
                                                    1. 1
                                                      1. 0
                                                        1. 0
                                                          1. 0
                                                      2. 0
                                                        1. 3
                                                    2. 0

                                                      Framework und serialize

                                                      1. 2
                                                        1. -1

                                                          Schlechter Programmierstil

                                                  2. 3
                                            2. -1

                                              Datenstrukturen aus Formulareingaben

                                              1. 2
                                                1. 0
                                                  1. 0
                                                    1. -1
                                                      1. 1
                                                        1. -2
                                                          1. 0
                                                            1. -1
                                                          2. 1
                                                            1. 1
                                                              1. 0
                                                            2. -1
                                                              1. 2
                                                                1. 0
                                                                  1. 0
                                                                    1. -1
                                                                    2. -1
                                                                      1. 0
                                                                        1. -1
                                                                          1. 1
                                                          3. 3
                                                            1. -1
                                                              1. 1
                                                                1. 0
                                                                  1. 1
                                                                    1. -1
                                                          4. 1
                                                        2. 0
                                              2. 0
                                              3. 0
  7. 1
    1. 0
  8. 1

Moin,

hier im Forum ist ja schon immer wieder über die Verwendung, das Pro und Kontra zu jQuery diskutiert worden. Die Meinung mancher Forumsteilnehmer (mir eingeschlossen), dass man oftmals jQuery durch Vanilla JS ersetzen kann, wird anscheinend auch von größeren Projekten geteilt.

Neben CSS als neuem JavaScript wird das wohl das nächste große Ding.

Viele Grüße
Robert

  1. Hallo Robert,

    ich mag es eigentlich ganz gerne, weil es einige Dinge schön kompakt macht. Vor allem dann, wenn man auch noch den IE supporten muss. Und da meine App im Intranet läuft, ist mir der Datenoverhead ziemlich schnuppe.

    Ich renoviere gerade eine seit ASP.NET 1.x gewachsene Web-Anwendung als SPA, und habe da auf requireJS und jQuery aufgesetzt. Kenn ich, mag ich, funktioniert für mich. Hätte ich jQuery weggelassen, dann hätte ich vermutlich angefangen, selbst ein paar Funktionen zu schreiben die die kompakte Syntax von JQ bieten. Oder würde, wie die Kollegen im großen Nachbarprojekt, auf react aufsetzen. Aber ich wollte fertig werden, keine steilen Lernkurven erklimmen.

    Rolf

    -- sumpsi - posui - clusi
  2. M.E. ist die entscheidende Frage dabei, ob man etwas komplett Neues beginnt, oder etwas Bestehendes weiterentwickelt. Ein bestehendes, individuelles System mit hinreichend komplexer Infrastruktur auf Vanilla-JS umzubauen, um die im Verhältnis dann doch überschaubaren Kilobytes einzusparen, halte ich für komplett drüber.

    1. Moin Mitleser,

      M.E. ist die entscheidende Frage dabei, ob man etwas komplett Neues beginnt, oder etwas Bestehendes weiterentwickelt. Ein bestehendes, individuelles System mit hinreichend komplexer Infrastruktur auf Vanilla-JS umzubauen, um die im Verhältnis dann doch überschaubaren Kilobytes einzusparen, halte ich für komplett drüber.

      Die Frage ist auch, wie viel der Kilobytes brauche ich oder kann ich einsparen. Code, der nicht geliefert wird, muss auch nicht geparst und compiliert werden. Davon sollte die Performance profitieren: weniger HTTP(S)-Transfer, weniger Compiler-Zeit.

      Viele Grüße
      Robert

  3. Hi there,

    hier im Forum ist ja schon immer wieder über die Verwendung, das Pro und Kontra zu jQuery diskutiert worden. Die Meinung mancher Forumsteilnehmer (mir eingeschlossen), dass man oftmals jQuery durch Vanilla JS ersetzen kann, wird anscheinend auch von größeren Projekten geteilt.

    Naja, der größte Vorteil von jQuery war das Ausbügeln von Browser-Unfähigkeiten und -inkonsistenzen. Da hat sich in den letzten Jahren bei den Browsern wirklich viel getan, und daher fallen mittlerweile noch viel mehr Gründe weg, jQuery irgendwo einzusetzen. Ein echtes Problem ist, daß es mittlerweile eine halbe Generation von "Programmierern" gibt, die von Javascript nur so viel verstehen als sie wissen müssen, um jQuery bedienen zu können. Das ist schon alleine deshalb bedauerlich, weil dadurch das oftmals das Verständnis der Zusammenhänge fehlt.

    Neben CSS als neuem JavaScript wird das wohl das nächste große Ding.

    Sorry, aber das versteh ich nicht…

    1. Moin klawischnigg,

      Neben CSS als neuem JavaScript wird das wohl das nächste große Ding.

      Sorry, aber das versteh ich nicht…

      Da ist ein Link … 😉

      Schönes Wochenende
      Robert

    2. Hallo klawischnigg,

      @Robert B.

      hier im Forum ist ja schon immer wieder über die Verwendung, das Pro und Kontra zu jQuery diskutiert worden. Die Meinung mancher Forumsteilnehmer (mir eingeschlossen), dass man oftmals jQuery durch Vanilla JS ersetzen kann,…

      pure js anstelle jquery, ja das kenne ich hier, aber vanilla js anstelle jquery ist mir wohl entgangen.

      Ein echtes Problem ist, daß es mittlerweile eine halbe Generation von "Programmierern" gibt, die von Javascript nur so viel verstehen als sie wissen müssen, um jQuery bedienen zu können. Das ist schon alleine deshalb bedauerlich, weil dadurch das oftmals das Verständnis der Zusammenhänge fehlt.

      Das ist genau das Problem. Die "Webentwickler" werden immer mehr zum "Anwender" anstelle "Entwicklers". Was eigentlich ja nicht schlimm wäre, wenn die Grundlagen vorhanden sind, doch dem ist fortschreitend immer seltener. Und auch ich selbst ertappe mich oft dabei immer fauler zu werden und vieles zu vergessen, weil gibt ja schon so viele vorgefertigte Sachen, warum immer das Rad neu erfinden. Beruhigend dabei aber zu wissen, ich kann wenn ich will. 😉

      Gruss
      Henry

      -- Meine Meinung zu DSGVO & Co:
      „Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“
      1. Hallo Henry,

        pure js anstelle jquery, ja das kenne ich hier, aber vanilla js anstelle jquery ist mir wohl entgangen.

        Bis demnächst
        Matthias

        -- Rosen sind rot.
        1. Hallo Matthias,

          danke für die Links. Ist das mal cool 😉

          hier war mir das noch nicht bewusst…

          hier jetzt schon. Also VanillaJs = ein Witz, faszinierend. Ich bin voll drauf reingefallen, habe schon mehrfach im Netz Vjs-Scripte gesehen und dachte nur "nicht noch ein Framework", wäre nie drauf gekommen, dass es gar keins ist. Nochmals danke. 😉

          Gruss
          Henry

          -- Meine Meinung zu DSGVO & Co:
          „Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“
          1. Moin Henry,

            danke für die Links. Ist das mal cool 😉

            Und performant: Kein Bloat, geringe Größe der Bibliothek, keine Installation, läuft Out-of-the-Box, …

            Also VanillaJs = ein Witz, faszinierend. Ich bin voll drauf reingefallen, habe schon mehrfach im Netz Vjs-Scripte gesehen und dachte nur "nicht noch ein Framework", wäre nie drauf gekommen, dass es gar keins ist. Nochmals danke. 😉

            Das ist kein Witz. Ob eine Laufzeitumgebung ein Framework ist, überlasse ich anderen zur Diskussion.

            Viele Grüße
            Robert

            1. Hallo Robert,

              Das ist kein Witz.

              Humor ist, wenn man trotzdem lacht.

              Gruß
              Jürgen

      2. hallo

        Das ist genau das Problem. Die "Webentwickler" werden immer mehr zum "Anwender" anstelle "Entwicklers".

        Du solltest halt mal deinen Wortschatz überprüfen. Webentwickler war noch nie eine zutreffende Bezeichnung für Menschen, die Sprachen nutzen, um Inhalte zu managen.

        -- Neu im Forum! Signaturen kann man ausblenden!
        1. Hallo beatovich,

          Du solltest halt mal deinen Wortschatz überprüfen.

          könnte jetzt was dazu sagen, aber weil heute Sonntag ist und das Wetter schön…

          Webentwickler war noch nie eine zutreffende Bezeichnung für Menschen, die Sprachen nutzen, um Inhalte zu managen.

          Du hast vergessen zu schreiben "meiner Meinung nach".

          Webentwickler

          Webentwickler

          usw…

          Gruss
          Henry

          -- Meine Meinung zu DSGVO & Co:
          „Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“
        2. Moin,

          eine Spinne ist doch ein Webentwickler 😉

          Viele Grüße
          Robert

    3. hi,

      Ein echtes Problem ist, daß es mittlerweile eine halbe Generation von "Programmierern" gibt, die von Javascript nur so viel verstehen als sie wissen müssen, um jQuery bedienen zu können.

      Das ist kein Problem sondern der Sinn einer jeden Library.

      Das ist schon alleine deshalb bedauerlich, weil dadurch das oftmals das Verständnis der Zusammenhänge fehlt.

      Das liegt aber nicht an der Library sondern an jedem selbst.

      MfG

      1. Hi there,

        Ein echtes Problem ist, daß es mittlerweile eine halbe Generation von "Programmierern" gibt, die von Javascript nur so viel verstehen als sie wissen müssen, um jQuery bedienen zu können.

        Das ist kein Problem sondern der Sinn einer jeden Library.

        Was ist der Sinn einer Library? Daß der Entwickler blöd bleiben darf?

        Das ist schon alleine deshalb bedauerlich, weil dadurch das oftmals das Verständnis der Zusammenhänge fehlt.

        Das liegt aber nicht an der Library sondern an jedem selbst.

        Wenn man nur mit jQuery "arbeitet" entwickelt man gar nicht die nötige Reife, um das zu erkennen…

        1. Hi there,

          Ein echtes Problem ist, daß es mittlerweile eine halbe Generation von "Programmierern" gibt, die von Javascript nur so viel verstehen als sie wissen müssen, um jQuery bedienen zu können.

          Das ist kein Problem sondern der Sinn einer jeden Library.

          Was ist der Sinn einer Library? Daß der Entwickler blöd bleiben darf?

          Das ist zwar nicht der Sinn einer Library aber es ist oftmals so.

          Wenn man nur mit jQuery "arbeitet" entwickelt man gar nicht die nötige Reife, um das zu erkennen…

          Ich kenne genügend Perlentwickler die können OOP nur dann wenn sie Moose einsetzen.

          MfG

        2. Hej klawischnigg,

          Ein echtes Problem ist, daß es mittlerweile eine halbe Generation von "Programmierern" gibt, die von Javascript nur so viel verstehen als sie wissen müssen, um jQuery bedienen zu können.

          Das ist kein Problem sondern der Sinn einer jeden Library.

          Was ist der Sinn einer Library? Daß der Entwickler blöd bleiben darf?

          Nein, dass man sie bedienen kann und sich auf etwas konzentrieren kann, das eben nciht JavaScript heißt (zum Beispiel den Inhalt der Website, wenn nicht nur Entwickler ist, sondern eigentlich jemand, der irgendetwas sagen möchte).

          jQuery ist halt ein Werkzeug, das in der Vergangenheit seine Berechtigung vor allem aus der Tatsache gezogen hat, dass pures JS unnötig asufwändig zu schreiben war aufgrund diverser Browser-Inkompatibilitäten.

          Hätte es sich noch weiter in die Richtung entwickelt, Menschen das Skripten von Webseiten zu erleichtern, ohne JaVaScript lernen zu müssen, Menschen die eben keine Programmierer sind (vielleicht unter Verzicht auf ganz viele Möglichkeiten, die ein echter Programmierer hat), wäre es IMHO immer noch interessant. Aber so hat es für mich seinen Sinn weitgehend verloren. Ja, wenn man bereits dran gewöhnt ist, will man nicht JS lernen, kann ich verstehen. Ich habe auch einen inneren Schweinhund 😉

          Aber das ist kein Argument, sondern einfach eine menschliche Eigenschaft, die etwas mit Dir und mir, nicht aber mit jQuery und JS zu tun hat.

          Marc

  4. Hallo Robert,

    all die, die von sich sagen: „Von Javascript habe ich keine Ahnung, ich programmiere in jQuery“.

    MMn kann jQuery bei großen Projekten sinnvoll sein, bestimmt aber nicht, um nur einen Eventhandler zu setzen.

    Gruß
    Jürgen

  5. Wir sollten uns ein wenig dankbarer geben, jQuery hat seinerzeit große Probleme gelöst und offene Standards und die OpenSource-JavaScript-Landschaft voran getrieben. Ohne jQuery gäbe es heute wahrscheinlich kein document.querySelectorAll. Das DOM, bevor es jQuery gab, war ein Kuriositäten-Kabinett, teils weil es unterspezifiziert war, teils weil Browser sich nicht an Standards halten wollten und teils, weil kein Konsens darüber herrschte, in welche Richtung sich das DOM weiterentwickeln sollte. jQuery hat unzählige Inkompatibilitäten zwischen Browsern aufgedeckt und ausgebügelt. Das hat uns Web-Entwicklern geholfen, weil wir nicht mehr selber jeden Browser-Quirk kennen und umschiffen mussten, es hat den Browser-Herstellern den Wind aus den Segeln genommen, sich eine Vormachtsstellung durch propritäre, unfreie Technologien zu erarbeiten und es hat den Standard-Konsortien geholfen unterspezifiziertes Verhalten zu finden und nachzubessern. Und jQuery hatte genügend Einfluss, um einen Konsens bei der Weiterentwicklung des DOM zu erzielen. Natürlich hat jQuery nur ein oder zwei Puzzelteile zur Gesamtentwicklung des Webs beigetragen, aber das sollten wir zu schätzen wissen. Außerdem hat jQuery die OpenSource-Kultur im Web befördert, ich glaube die Plugin-Datenbank von jQuery war eine der größten JavaScript-OpenSource-Sammlungen bevor sich require.js, common.js, npm und letztlich native ECMAScript-Module etabliert haben.

    Um auf die Gegenwart zu kommen: unsere Probleme heute sind andere als vor 10 Jahren, und zu deren Lösungen kann jQuery nicht viel beitragen. jQuery-Code war und ist schon immer Spaghetti-Code, jQuery hat nichts anzubieten, um Code besser zu strukturieren, es bevorzugt und benachteiligt keine individuelle Architektur. Viele Probleme, für die jQuery seiner Zeit Lösungen anbieten konnte, sind heute besser gelöst. Heute sind JavaScript-Engines deutlich näher am Standard orientiert, wir haben bessere Paket-Datenbanken und Web Standards sind nicht mehr so orientierungslos wie damals. Dafür haben wir neue Probleme, wir leben im responsiven Zeitalter, Performance spielt eine immer elementarere Rolle, unsere Anwendungen werden komplexer und es wächst das Bedürfnis nach expressiveren, besser wartbaren Architekturen. Die nativen Bausteine, die uns modernes JavaScript und das DOM bieten, sind besser geworden, aber wir stehen heute vor neuen Problmem. Das DOM ist immernoch häufig ein Quell für Performance-Bottelnecks und Korrektheits-Bugs. Neue Frameworks, Architekturen und Programmiersprachen sind erschienen, die diese Probleme lösen wollen. WebComponents, Virtual DOM Libraries, predictable State-Manager, serverseitige Rendering-Engines, Task-Runner, Transpiler, Precompiler, Typechecker… kurz: Software-Engineering-Methoden haben das Feld übernommen und dominieren den gegenwärtigen JavaScript-Kosmos. Wir sollten aber würdigen, dass das auf den Schultern von Giganten getragen wird, wie jQuery mal einer war.

    1. Hallo 1unitedpower,

      jQuery-Code war und ist schon immer Spaghetti-Code

      jQuery-Code ist genauso Spaghetti wie anderer Code, das hängt vom Programmierer ab. Ein erfahrener Spaghetti-Programmierer produziert in jeder Sprache und mit jedem Toolset Spaghetti-Code. Und ein ordentlicher Programmierer produziert in jeder Sprache1, die das nicht aktiv verhindert, ordentliche Programme.

      Es sei denn, du vergleichst ein auf jQuery aufbauendes Programm mit deklarativen Konzepten wie Angular, Knockout oder React und empfindest einen Ansatz ohne solche Frameworks als Spaghetti.

      jQuery hat nichts anzubieten, um Code besser zu strukturieren, es bevorzugt und benachteiligt keine individuelle Architektur

      Nein, das war ja auch nie die Idee. jQuery ist eine Shell um das DOM, mit ein paar Goodies. Und hat da, wie Du dargelegt hast, einen tollen, aber so gut wie obsoleten, Job gemacht.

      Rolf

      1. APL, Brainfuck, VATICAL

      -- sumpsi - posui - clusi
      1. jQuery-Code ist genauso Spaghetti wie anderer Code, das hängt vom Programmierer ab. Ein erfahrener Spaghetti-Programmierer produziert in jeder Sprache und mit jedem Toolset Spaghetti-Code. Und ein ordentlicher Programmierer produziert in jeder Sprache, die das nicht aktiv verhindert, ordentliche Programme.

        Das glaube ich nicht, stehe ich vor einem Programmierproblem, entwickle ich ein mentales Modell dafür, das ich schrittweise in Code übersetze. Wenn die Programmierumgebung meinem mentalen Modell ähnelt, dann bringe ich recht expressiven Code zustande, wenn sie zu sehr davon abweicht, kommt da Spaghetti-Code raus. Eine kleine Analogie: Wenn mein Auftrag lautet ein Raumschiff zu zeichnen, kommt da auch meistens etwas raus, das dem Raumschiff, das ich vor meinem inneren Auge visualisiert habe, zumindest grob ähnelt, auch wenn meine Zeichentechnik unausgereift ist. Wenn mir jemand vorschreibt, ich solle das Bild wie ein Tintenstrahldrucker Linie für Linie zeichnen, dann kommt da höchstens Krikel Krakel bei rum.

        John De Goes hat das eben bei Twitter sehr gut auf den Punkt gebracht:

        Programming pain is caused by the irreversible loss of information that occurs as we translate high-level concepts into low-level language constructs.

        The ultimate programming language would allow you to program losslessly at the higher level your brain wants to work at.

        Interessanterweise funktioniert das auch in die Umkehrrichtung: Das Design einer Programmierumgebung kann durch wiederholte Anwendung Auswirkungen auf unsere Visualisierungsfähigkeit und unser abstraktes Denkvermögen nehmen. Das kann Schaden anrichten, als Programmieranfänger habe ich zu spüren bekommen, wie sehr das prozedurale Paradigma meine Lernfähigkeit und -bereitschaft für neue Denkmuster gemindert hat. Seitdem versuche ich regelmäßig andersgeartete Programmiersprachen zu lernen, um offen für alternative Lösungensverfahren zu bleiben (und natürlich weil ich Freude daran habe und meine Brötchen damit verdiene). Die Rückkopplung hat aber auch ein paar gute Seiten, zum Beispiel schöpfe ich heute aus einem großen Topf abstrakter Lösungsmuster, die ich mir selber hätte niemals ausdenken können, und die mir wohl ewig verborgen geblieben wären, hätte ich mich nicht intensiv mit funktionaler Programmierung beschäftigt.

  6. Moin,

    gibt es denn mittlerweile eine Builtin-Funktion zum Serialisieren von Formularfeldern? Also eine Alternative zu jQuery(form).serialize() ?

    Enctype application/x-www-form-urlencoded

    MfG

    Folgende Nachrichten verweisen auf diesen Beitrag:

    1. Tach!

      gibt es denn mittlerweile eine Builtin-Funktion zum Serialisieren von Formularfeldern?

      jQuery ist auch nicht built-in, also muss eine Vanilla-Lösung auch nicht direkt built-in sein.

      Also eine Alternative zu jQuery(form).serialize() ?

      Enctype application/x-www-form-urlencoded

      Geht als Einzeiler:

      const form = new FormData(); form.append('foo', 'bar'); form.append('qux', 'baz'); const serialized = Array.from(form) .map(field => `${encodeURIComponent(field[0])}=${encodeURIComponent(field[1])}`) .join('&');

      dedlfix.

      Folgende Nachrichten verweisen auf diesen Beitrag:

      1. Hallo dedlfix,

        const form = new FormData(); form.append('foo', 'bar'); form.append('qux', 'baz'); const serialized = Array.from(form) .map(field => `${encodeURIComponent(field[0])}=${encodeURIComponent(field[1])}`) .join('&');

        Das schöne an FormData ist aber halt auch, dass die Serialisierung so gar nicht nötig ist.

        fetch('https://example.com/foo', { method: 'POST', body: form });

        Das tut genau das, was man erwarten würde: es schickt die Daten application/x-www-form-urlencoded an die angegebene URL. 😀

        LG,
        CK

        -- https://wwwtech.de/about
        1. Tach!

          Das schöne an FormData ist aber halt auch, dass die Serialisierung so gar nicht nötig ist.

          Das hab ich für die gegebene Aufgabenstellung nicht gefunden.

          fetch('https://example.com/foo', { method: 'POST', body: form });

          Das tut genau das, was man erwarten würde: es schickt die Daten application/x-www-form-urlencoded an die angegebene URL. 😀

          Nein, es sendet multipart/form-data im Body und erzeugt damit keine Serialisierung für die URL, so wie es die jQuery-Funktion macht.

          dedlfix.

          1. Hallo dedlfix,

            fetch('https://example.com/foo', { method: 'POST', body: form });

            Das tut genau das, was man erwarten würde: es schickt die Daten application/x-www-form-urlencoded an die angegebene URL. 😀

            Nein, es sendet multipart/form-data im Body und erzeugt damit keine Serialisierung für die URL, so wie es die jQuery-Funktion macht.

            Ja, stimmt. Ich hatte es mit URLSearchParams verwechselt.

            LG,
            CK

            -- https://wwwtech.de/about
            1. Tach!

              Nein, es sendet multipart/form-data im Body und erzeugt damit keine Serialisierung für die URL, so wie es die jQuery-Funktion macht.

              Ja, stimmt. Ich hatte es mit URLSearchParams verwechselt.

              Ach, das gibts auch ... Zumindest kann man es mit dieser im MDN als experimentell gekennzeichneten API vereinfachen: new URLSearchParams(form).toString();

              dedlfix.

              Folgende Nachrichten verweisen auf diesen Beitrag:

              1. Tach!

                Nein, es sendet multipart/form-data im Body und erzeugt damit keine Serialisierung für die URL, so wie es die jQuery-Funktion macht.

                Ja, stimmt. Ich hatte es mit URLSearchParams verwechselt.

                Ach, das gibts auch ... Zumindest kann man es mit dieser im MDN als experimentell gekennzeichneten API vereinfachen: new URLSearchParams(form).toString();

                Ok wir testen das:

                <form id="ff"> <input name="foo" value="fooval"> <input name="bar" value="barval"> </form> <script> var ff = document.getElementById("ff"); console.log( new URLSearchParams(ff).toString() ); </script>

                liefert %5Bobject+HTMLFormElement%5D= also nicht das gewünschte Ergebnis.

                MfG

                PS: Kann ja auch gar nicht weil

                The URLSearchParams interface defines utility methods to work with the query string of a URL.

                Folgende Nachrichten verweisen auf diesen Beitrag:

                1. Tach!

                  Zumindest kann man es mit dieser im MDN als experimentell gekennzeichneten API vereinfachen: new URLSearchParams(form).toString();

                  Ok wir testen das:

                  <form id="ff"> <input name="foo" value="fooval"> <input name="bar" value="barval"> </form> <script> var ff = document.getElementById("ff"); console.log( new URLSearchParams(ff).toString() ); </script>

                  liefert %5Bobject+HTMLFormElement%5D= also nicht das gewünschte Ergebnis.

                  Da liegt ein Missverständnis vor, das wohl aus einer nicht exakten Variablenbenennung meinerseits resultiert. Mit form meinte ich die FormData-Instanz aus meinem Eingangsbeispiel. Wenn du dein Beispiel wie folgt umschreibst, wird ein Schuh draus:

                  console.log( new URLSearchParams(new FormData(ff)).toString() );

                  dedlfix.

                  Folgende Nachrichten verweisen auf diesen Beitrag:

                  1. @dedlfix Tach!

                    Zumindest kann man es mit dieser im MDN als experimentell gekennzeichneten API vereinfachen: new URLSearchParams(form).toString();

                    Ok wir testen das:

                    <form id="ff"> <input name="foo" value="fooval"> <input name="bar" value="barval"> </form> <script> var ff = document.getElementById("ff"); console.log( new URLSearchParams(ff).toString() ); </script>

                    liefert %5Bobject+HTMLFormElement%5D= also nicht das gewünschte Ergebnis.

                    Da liegt ein Missverständnis vor, das wohl aus einer nicht exakten Variablenbenennung meinerseits resultiert. Mit form meinte ich die FormData-Instanz aus meinem Eingangsbeispiel. Wenn du dein Beispiel wie folgt umschreibst, wird ein Schuh draus:

                    console.log( new URLSearchParams(new FormData(ff)).toString() );

                    Damit ich dir hier keine Antwort schuldig bleibe: Das liefert ebenfalls ein unbrauchbares Ergebnis %5Bobject+FormData%5D=

                    MfG

                    1. Tach!

                      Damit ich dir hier keine Antwort schuldig bleibe: Das liefert ebenfalls ein unbrauchbares Ergebnis %5Bobject+FormData%5D=

                      Die erwartete Antwort wäre ein vollständig lauffähiges Beispiel, das den genannten Fehler produziert. Mir scheint, du rufst an irgendeiner Stelle das toString() von FormData auf und schickst das Ergebnis anschließend durch URLSearchParams. Wenn ich das so falsch durchführe, bekomme ich auch dieses falsche Ergebnis.

                      Da ist ein jsfiddle zum testen: https://jsfiddle.net/u0efxmya/2/

                      dedlfix.

                      Folgende Nachrichten verweisen auf diesen Beitrag:

                      1. Tach!

                        Damit ich dir hier keine Antwort schuldig bleibe: Das liefert ebenfalls ein unbrauchbares Ergebnis %5Bobject+FormData%5D=

                        Die erwartete Antwort wäre ein vollständig lauffähiges Beispiel, das den genannten Fehler produziert. Mir scheint, du rufst an irgendeiner Stelle das toString() von FormData auf und schickst das Ergebnis anschließend durch URLSearchParams. Wenn ich das so falsch durchführe, bekomme ich auch dieses falsche Ergebnis.

                        Da ist ein jsfiddle zum testen: https://jsfiddle.net/u0efxmya/2/

                        Das liefert %5Bobject+FormData%5D= aber danke für Deine Bemühungen. Und wie bereits begründet, finde ich diesen Lösungsanstz auch nicht zielführend, werde den von daher auch nicht weiter verfolgen.

                        MfG

                        Folgende Nachrichten verweisen auf diesen Beitrag:

                        1. Hallo pl,

                          Da ist ein jsfiddle zum testen: https://jsfiddle.net/u0efxmya/2/

                          Das liefert %5Bobject+FormData%5D=

                          Da lügst du jetzt aber.

                          LG,
                          CK

                          -- https://wwwtech.de/about
                        2. Hi,

                          Da ist ein jsfiddle zum testen: https://jsfiddle.net/u0efxmya/2/

                          Das liefert %5Bobject+FormData%5D=

                          nein, das liefert foo=fooval&bar=barval.

                          cu,
                          Andreas a/k/a MudGuard

                        3. Tach!

                          Da ist ein jsfiddle zum testen: https://jsfiddle.net/u0efxmya/2/

                          Das liefert %5Bobject+FormData%5D=

                          In welchem Browser, unter welchen anderen Umständen? Ich denke, du weißt, dass man zur Fehlersuche solche Angaben machen sollte, wenn es hilfreich sein soll.

                          dedlfix.

                          1. Tach!

                            Da ist ein jsfiddle zum testen: https://jsfiddle.net/u0efxmya/2/

                            Das liefert %5Bobject+FormData%5D=

                            In welchem Browser, unter welchen anderen Umständen? Ich denke, du weißt, dass man zur Fehlersuche solche Angaben machen sollte, wenn es hilfreich sein soll.

                            Ja sicher. Wenn Du da Hilfe brauchst, schick mir einfach ne Mail.

                            MfG

                          2. @dedlfix Tach!

                            Da ist ein jsfiddle zum testen: https://jsfiddle.net/u0efxmya/2/

                            Das liefert %5Bobject+FormData%5D=

                            In welchem Browser, unter welchen anderen Umständen? Ich denke, du weißt, dass man zur Fehlersuche solche Angaben machen sollte, wenn es hilfreich sein soll.

                            Du nutzt eine Software nicht so wie sie dokumentiert ist. Also so wie Du sie einsetzt, ist sie nicht dokumentiert. Ein professioneller Entwickler würde sowas schonmal gar nicht machen.

                            Und ein Hersteller würde dazu sagen: No Support.

                            MfG

                            1. Moin pl,

                              du bist derjenige, der das Fiddle nutzt und sagt „geht nicht“.

                              Viele Grüße
                              Robert

                              1. Moin pl,

                                du bist derjenige, der das Fiddle nutzt und sagt „geht nicht“.

                                Eben. Mich wunderts daß es überhaupt irgendwo anders geht angeblich. In der Doku für URLSearchParams steht jedenfalls nichts davon daß man dem Konstruktor ein FormData Objekt übergeben kann.

                                Und in der FromData Doku steht auch nichts diesbezügliches, welcher Kontext soll das denn sein?

                                Für einen poduktiven Einsatz ist solch eine undokumentierte Nutzung völlig undiskutabel.

                                MfG

                                1. Hallo pl,

                                  Mich wunderts daß es überhaupt irgendwo anders geht angeblich.

                                  In meinem Browser funktioniert das fiddle auch wie gewünscht. Aber bestimmt sage ich nicht die Wahrheit.

                                  Bis demnächst
                                  Matthias

                                  -- Rosen sind rot.
                                2. Moin pl,

                                  du bist derjenige, der das Fiddle nutzt und sagt „geht nicht“.

                                  Eben.

                                  Da du der Nutzer bist und dedlfix der Hersteller des Fiddles, wer von euch beiden ist derjenige, der mit „geht nicht“ Support anfragt und wer ist derjenige, der Support leistet? Merkste hoffentlich selbst.

                                  Mich wunderts daß es überhaupt irgendwo anders geht angeblich.

                                  Nicht nur angeblich.

                                  Viele Grüße
                                  Robert

                                  1. Moin pl,

                                    du bist derjenige, der das Fiddle nutzt und sagt „geht nicht“.

                                    Eben.

                                    Da du der Nutzer bist und dedlfix der Hersteller des Fiddles, wer von euch beiden ist derjenige, der mit „geht nicht“ Support anfragt und wer ist derjenige, der Support leistet? Merkste hoffentlich selbst.

                                    Daß der Code bei Euch funktioniert, habe ich gar nicht bestritten.

                                    Aber zeige doch mal bitte, wo eine Verwendung dieser Art

                                    `new URLSearchParams(new FormData(ff)).toString();`

                                    dokumentiert ist!

                                    MfG

                                    1. Hallo pl,

                                      Aber zeige doch mal bitte, wo eine Verwendung dieser Art

                                      `new URLSearchParams(new FormData(ff)).toString();`

                                      dokumentiert ist!

                                      Das hat dedlfix mehrfach erklärt und verlinkt. Hier im Thread. Lies es bitte nach.

                                      LG,
                                      CK

                                      -- https://wwwtech.de/about
                                    2. Moin pl,

                                      Da du der Nutzer bist und dedlfix der Hersteller des Fiddles, wer von euch beiden ist derjenige, der mit „geht nicht“ Support anfragt und wer ist derjenige, der Support leistet? Merkste hoffentlich selbst.

                                      Daß der Code bei Euch funktioniert, habe ich gar nicht bestritten.

                                      Du behauptest, dass der Code bei dir nicht funktioniert.

                                      Aber zeige doch mal bitte, wo eine Verwendung dieser Art

                                      `new URLSearchParams(new FormData(ff)).toString();`

                                      dokumentiert ist!

                                      Das tut in diesem Strang des Themas aber gar nichts zur Sache. Bleib bitte beim Thema oder unterhalte dich alleine.

                                      Viele Grüße
                                      Robert

                                      1. hi,

                                        Da du der Nutzer bist und dedlfix der Hersteller des Fiddles, wer von euch beiden ist derjenige, der mit „geht nicht“ Support anfragt und wer ist derjenige, der Support leistet? Merkste hoffentlich selbst.

                                        Daß der Code bei Euch funktioniert, habe ich gar nicht bestritten.

                                        Du behauptest, dass der Code bei dir nicht funktioniert.

                                        Ja, so ist nunmal der Fakt. Aber selbst wenn es bei mir funktionieren würde, ich würde es nicht so machen weil diese Art von Verwendung nirgendwo so dokumentiert ist. Anders ausgedrückt ist es für mich nicht nachvollziehbar warum das funktionieren soll.

                                        MfG

                                        1. Hallo pl,

                                          Ja, so ist nunmal der Fakt. Aber selbst wenn es bei mir funktionieren würde, ich würde es nicht so machen weil diese Art von Verwendung nirgendwo so dokumentiert ist. Anders ausgedrückt ist es für mich nicht nachvollziehbar warum das funktionieren soll.

                                          Was denn?

                                          • FormData()
                                          • URLSearchParams()
                                          • toString()

                                          ?

                                          Bis demnächst
                                          Matthias

                                          -- Rosen sind rot.
                                        2. Moin pl,

                                          Daß der Code bei Euch funktioniert, habe ich gar nicht bestritten.

                                          Du behauptest, dass der Code bei dir nicht funktioniert.

                                          Ja, so ist nunmal der Fakt.

                                          Fakt ist auch, dass du uns technische Informationen vorenthältst um dein „geht nicht“ nachvollziehen zu können.

                                          Viele Grüße
                                          Robert

                                          1. Hallo Robert B.,

                                            Fakt ist auch, dass du uns technische Informationen vorenthältst um dein „geht nicht“ nachvollziehen zu können.

                                            Wahrscheinlich ein simpler Klammerfehler beim Abschreiben.

                                            Bis demnächst
                                            Matthias

                                            -- Rosen sind rot.
                                          2. Hi,

                                            Fakt ist auch, dass du uns technische Informationen vorenthältst um dein „geht nicht“ nachvollziehen zu können.

                                            Allein schon der CODE ist nicht nachvollziehbar!

                                            MfG

                                            1. Hallo pl,

                                              Allein schon der CODE ist nicht nachvollziehbar!

                                              const queryString = new URLSearchParams(new FormData(ff)).toString(); — dieser?

                                              Bis demnächst
                                              Matthias

                                              -- Rosen sind rot.
                                            2. Moin pl,

                                              du weichst aus anstatt zu antworten.

                                              Damit bin ich an dieser Stelle 'raus.

                                              Viele Grüße
                                              Robert

                                              1. Hi Robert,

                                                was erwartest Du denn bei einer zweckentfemdeten Nutzung von Code? Doch nicht etwa daß es funktioniert!

                                                MfG

                                            3. Tach!

                                              Fakt ist auch, dass du uns technische Informationen vorenthältst um dein „geht nicht“ nachvollziehen zu können.

                                              Allein schon der CODE ist nicht nachvollziehbar!

                                              Du bist doch nach eigenen Worten bewandert in OOP und kennst dich mit Overloading aus.

                                              "Das [...] Verhalten bezüglich Funktionsargument ist übrigens ganz typisch für OOP/Overload."

                                              Du musst nur das richtige Overload vom URLSearchParams-Konstruktor nehmen, dann sollte sich das erklären.

                                              Ich hab das anhand der MDN-Dokumentation verstanden, und das obwohl mir "eine gehörige Portion Grundwissen und vor Allem Erfahrungen" fehlt. Also so schwer kann das mit dem Nachvollziehen ja nicht sein.

                                              Hier nochmal der Link zu meinem Posting, in dem ich das zum Nachvollziehen notwendige beschrieben haben: https://forum.selfhtml.org/self/2018/jul/20/braucht-noch-wer-jquery/1727377#m1727377.

                                              dedlfix.

                                              1. Tach!

                                                Du musst nur das richtige Overload vom URLSearchParams-Konstruktor nehmen, dann sollte sich das erklären.

                                                URLSearchParams funktioniert bei mir nicht so wie beschrieben. Und selbst wenn, ich würde es gar nicht brauchen. Die KV-Paare über encodeURIComponent() auf ein Array zu pushen und den Enctype infolge eines join zu erzeugen, das braucht kein URLSearchParams, das sind Basics.

                                                MfG

                                                1. Tach!

                                                  Du musst nur das richtige Overload vom URLSearchParams-Konstruktor nehmen, dann sollte sich das erklären.

                                                  URLSearchParams funktioniert bei mir nicht so wie beschrieben.

                                                  Zum Lesen der Dokumentation muss es nicht funktionieren.

                                                  Und selbst wenn, ich würde es gar nicht brauchen. Die KV-Paare über encodeURIComponent() auf ein Array zu pushen und den Enctype infolge eines join zu erzeugen, das braucht kein URLSearchParams, das sind Basics.

                                                  Warum nochmal hast du dann nach einer Alternative zu jQuery(form).serialize() gefragt?

                                                  dedlfix.

                                                  1. Tach!

                                                    Warum nochmal hast du dann nach einer Alternative zu jQuery(form).serialize() gefragt?

                                                    Weil ich wissen wollte was es so an Alternativen gibt, wenn man nur einen Funktionsaufruf haben möchte. Die Antwort kenne ich mittlerweile: Es gibt keine Alternativen.

                                                    MfG

                                                    1. Hallo pl,

                                                      Weil ich wissen wollte was es so an Alternativen gibt, wenn man nur einen Funktionsaufruf haben möchte.

                                                      Die Einschränkung hast du im fraglichen Beitrag nicht gemacht. Zudem kannst du dir eine entsprechende Funktion schreiben. Nichts anderes hat jquery auch gemacht.

                                                      Die Antwort kenne ich mittlerweile: Es gibt keine Alternativen.

                                                      PL — alle anderen -31 : 71

                                                      Bis demnächst
                                                      Matthias

                                                      -- Rosen sind rot.
                                                      1. Guten Morgen,

                                                        Die Einschränkung hast du im fraglichen Beitrag nicht gemacht. Zudem kannst du dir eine entsprechende Funktion schreiben. Nichts anderes hat jquery auch gemacht.

                                                        Genau! jQuery(form).serialize() ist ein Funktionsaufruf.

                                                        Die Antwort kenne ich mittlerweile: Es gibt keine Alternativen.

                                                        PL — alle anderen -31 : 71

                                                        Höchstens ersichtlich aber nicht praktikabel. FormData ist veralteter Schrott nur neu verpackt und URLSearchParams ist überflüssig.

                                                        Ergo bleibt da sowieso nur eine Eigenentwicklung und das hierzu benötigte Wissen habe ich sehr ausführlich vermittelt, einschließlich Empfehlungen hinsichtlich Integrität, Performance, Wartungsfreundlichkeit und Skalierbarkeit mit Blick auf weitere Enctypes (Content-Type) sowie Webservices. Für die Einen sind das Buzzworte, für Andere wilder Müll, für mich jedoch alles Dinge an denen immer wieder meine Freude habe.

                                                        Schönen Tag noch.

                            2. Hallo pl,

                              Du nutzt eine Software nicht so wie sie dokumentiert ist.

                              Welche Software? Welche Dokumentation?

                              Also so wie Du sie einsetzt, ist sie nicht dokumentiert.

                              Welcher Einsatz?

                              Ein professioneller Entwickler würde sowas schonmal gar nicht machen.

                              Genau. Wir wissen ja alle, dass du der einzige professionelle Entwickler hier bist.

                              Bis demnächst
                              Matthias

                              -- Rosen sind rot.
                            3. Tach!

                              Du nutzt eine Software nicht so wie sie dokumentiert ist. Also so wie Du sie einsetzt, ist sie nicht dokumentiert. Ein professioneller Entwickler würde sowas schonmal gar nicht machen.

                              Ich habe die entsprechenden Stellen der Dokumentation in einer meiner Antworten verlinkt.

                              dedlfix.

                        4. Hallo,

                          Da ist ein jsfiddle zum testen: https://jsfiddle.net/u0efxmya/2/

                          Das liefert %5Bobject+FormData%5D= aber danke für Deine Bemühungen.

                          also bei mir im iPhone gehts.

                          Und wie bereits begründet, finde ich diesen Lösungsanstz auch nicht zielführend, werde den von daher auch nicht weiter verfolgen.

                          Offensichtlich verwendest du irgendeine System-Browserkombination, die diesen Lösungsansatz nicht unterstützt.

                          Gruß
                          Jürgen

                          1. Hallo,

                            Offensichtlich verwendest du irgendeine System-Browserkombination, die diesen Lösungsansatz nicht unterstützt.

                            Wahrscheinlich ist mein FF zu alt aber im Chrome ergibt sich dasselbe unbrauchbare Ergebnis. Außerdem beschreibt MDN selbst URLSearchParams als experimentelles Feature. Wohingegen document.forms.elements in jedem Browser funktioniert. Schon von daher erachte ich es für zielführender darauf aufzubauen.

                            Aber wo ich Dich schonmal dran habe, was ist denn Deine Lösung für jquery.serialize?

                            MfG

                            1. Hallo,

                              Aber wo ich Dich schonmal dran habe, was ist denn Deine Lösung für jquery.serialize?

                              ich habe bisher jquery nicht benötigt. auch verwende ich keine serverseitige Technik. Wenn ich URL-Parameter verwende, dann nur um Javascripte zu steuern. Das „Aufdröseln“ der Parameter mache ich (noch) zu Fuß mit split, auch, weil ich keine Formulare verwende.

                              Gruß
                              Jürgen

                              1. Hallo,

                                Aber wo ich Dich schonmal dran habe, was ist denn Deine Lösung für jquery.serialize?

                                ich habe bisher jquery nicht benötigt. auch verwende ich keine serverseitige Technik. Wenn ich URL-Parameter verwende, dann nur um Javascripte zu steuern. Das „Aufdröseln“ der Parameter mache ich (noch) zu Fuß mit split, auch, weil ich keine Formulare verwende.

                                Das Aufdröseln könntest Du mit URLSearchParams machen, dafür wurde das entwickelt. Das macht auch das Percentencoding rückgängig.

                                Aber das mit split zu machen ist völlig in Ordnung. Ich kenne einige und gehörte selbst auch zu denen, die ajax Responses als application/x-www-form-urlencoded verarbeiten. Man bekommt Schlüssel:Werte Paare wobei Werte auch Arrays sein können.

                                Je nachdem wie ein solcher Deserializer eingestellt ist, wird entweder ein Array geliefert oder alles zusammen in einem Objekt. Dieser Enctype ist also nicht nur für den Request geeignet sondern auch für die Response wenn komplexe Daten zu übertragen sind.

                                The Name-Value Pair (NVP) API provides parameter-based association between the request and response fields of a message and their values. PayPal also macht das auch so und unterstützt verschiedene PLs auf diese Art und Weise.

                                So wie es aussieht, gibt es die ganze API von PayPal in SOAP und NVP gleichermaßen. Und selbstverständlich wird ein Shopentwickler dabei auf ein bewährtes Schichtenmodell zurückgreifen, also von wegen wirrer Müll -- aber warum jemand dermaßen trollt sollte uns beiden eigentlich klar sein.

                                Eine solche Trollerei hat mit Fachwissen überhaupt nichts mehr zu tun.

                                Schöne Grüße.

                                1. Hallo,

                                  erst mal, hier trollt niemand.

                                  Die Ausgangsfrage war, kann man den jQuery Serialisierer durch einfaches Javascript ersetzen, und die Antwort war ja, mit modernem JS ist das möglich. Die Weiterverarbeitung ist zwar wichtig, ebenso die Unterstützung unmoderner Browser, aber nicht Teil dieser Frage.

                                  Gruß
                                  Jürgen

                                  1. Hallo Jürgen,

                                    erst mal, hier trollt niemand.

                                    Doch, aber sowas von. Wer das was ich hier an Grundwissen vermittle als wirren Müll bezeichnet ist ein Troll, das ist überhaupt keine Frage!

                                    Die Ausgangsfrage war, kann man den jQuery Serialisierer durch einfaches Javascript ersetzen, und die Antwort war ja, mit modernem JS ist das möglich.

                                    Es war schon immer möglich!

                                    Und falls Du mit dem Begriff modernes JS auf FormData abzielst, das ist alles Andere als modern, denn es ist alter Schrott nur neu verpackt. Der Aufwand, mit dem man aus diesem Schrott was Modernes hätte machen können, wäre sehr gering, das war sogar schon Thema hier im Forum, vielleicht kannst Du Dich ja daran erinnern.

                                    Die Weiterverarbeitung ist zwar wichtig, ebenso die Unterstützung unmoderner Browser, aber nicht Teil dieser Frage.

                                    Browserunterstützung und Weiterverarbeitung sind immer Teil der Frage. Die Verarbeitung eines mit Enctype multipart/form-data kodierten Inhalts ist nämlich alles Andere als CPU und RAM gefällig. Du bist doch selbst Programmierer und hast einen Parser für den anderern Enctype geschrieben. Dann kannst Du vielleicht den Aufwand schon ahnen, den das Parsen einer multipart/form-data Byte Sequenz erfordert.

                                    Zumal man einen Enctype nicht einfach durch einen anderen Enctype ersetzen kann, eben wegen einer Weiterverarbeitung. Auch das sollte ein Programmierer wie Du es bist wissen.

                                    Und ja, der Default Enctype kann zwar auch durch +Stringverkettungen erstellt werden, aber den Umweg über eine Datenstruktur würdest Du wahrscheinlich auch gehen: Aus den Daten ein Array erzeugen und daraus mit join den String. Jeder Serializer arbeitet über den Umweg einer Datenstruktur.

                                    Daß man an den Default Enctype application/x-www-form-urlencoded Daten anhängen kann, ist eine Besonderheit dieses speziellen Enctypes. Mit anderen Enctypes ist das nämlich gar nicht möglich, ohne diese aufzutrennen, siehe JSON, XML. Von daher ist die Frage ob einer Datenstruktur zum Serialisieren für Entwickler wie uns beide doch auch geklärt, also kein Grund daraus eine Zirkusveranstaltung zu machen.

                                    Alles Dinge die ein Entwickler wissen sollte, wenn es um einen Ersatz für jquery.serialize geht.

                                    Schönen Sonntag!

                                    1. Hallo,

                                      Doch, aber sowas von. Wer das was ich hier an Grundwissen vermittle als wirren Müll bezeichnet ist ein Troll, das ist überhaupt keine Frage!

                                      überschätzt du dich da nicht?

                                      […]

                                      Alles Dinge die ein Entwickler wissen sollte, wenn es um einen Ersatz für jquery.serialize geht.

                                      finde ich nicht. Bei meinem (De-)Serialisierer habe ich das alles nicht gebraucht.

                                      Gruß
                                      Jürgen

                                      1. Hallo,

                                        Alles Dinge die ein Entwickler wissen sollte, wenn es um einen Ersatz für jquery.serialize geht.

                                        finde ich nicht. Bei meinem (De-)Serialisierer habe ich das alles nicht gebraucht.

                                        Dann kann Dein Ergebnis ja nur ein glücklicher Zufall sein 😉

                                        MfG

                        5. Moin pl,

                          Da ist ein jsfiddle zum testen: https://jsfiddle.net/u0efxmya/2/

                          Das liefert %5Bobject+FormData%5D=

                          auf welchem Browser, in welcher Version und welchem Betriebssystem?

                          • Unter Linux Mint 18.1 erhalte ich mit:
                            • Firefox 61.0.1: foo=fooval&bar=barval
                            • Chromium 67.0: foo=fooval&bar=barval
                            • Konqueror 4.14.16: kann das Fiddle nicht anzeigen 😉
                          • Auf dem Telefon mit SailfishOS wird das Fiddle an sich schon nicht korrekt angezeigt (scheint Probleme mit der Bildschirmgröße zu haben?)
                          • Unter Windows 10 erhalte ich mit:
                            • Firefox 61.0.1: foo=fooval&bar=barval
                            • Microsoft Edge 42: „Ungültiges Argument“ beim Aufruf von FormData
                            • Microsoft Internet Explorer 11: eine „tanzende“ Wolke

                          Viele Grüße
                          Robert

                          Folgende Nachrichten verweisen auf diesen Beitrag:

                          1. hallo

                            Da ist ein jsfiddle zum testen: https://jsfiddle.net/u0efxmya/2/

                            Das liefert %5Bobject+FormData%5D=

                            auf welchem Browser, in welcher Version und welchem Betriebssystem?

                            • Unter Linux Mint 18.1 erhalte ich mit:
                              • Firefox 61.0.1: foo=fooval&bar=barval

                            Ich habe im fiddle in Zeile 5 ein

                            <p id="ff">ha</p>

                            eingefügt.

                            Rate mal, was für ein Output entsteht.

                            -- Neu im Forum! Signaturen kann man ausblenden!
                            1. Moin beatovich,

                              • Unter Linux Mint 18.1 erhalte ich mit:
                                • Firefox 61.0.1: foo=fooval&bar=barval

                              Ich habe im fiddle in Zeile 5 ein

                              <p id="ff">ha</p>

                              eingefügt.

                              Rate mal, was für ein Output entsteht.

                              Naja, ich sehe den neuen Absatz und dann den Absatz mit dem output darin. Oder worauf sollte sich das beziehen?

                              Viele Grüße
                              Robert

                              1. hallo

                                Naja, ich sehe den neuen Absatz und dann den Absatz mit dem output darin. Oder worauf sollte sich das beziehen?

                                Das hat jetzt nichts mit dem Thema zu tun.

                                Es genügt, eine id einzuschleussen, und schon hast du Gewalt über den Inhalt.

                                Da hilft nicht mal use strict.

                                -- Neu im Forum! Signaturen kann man ausblenden!
                                1. Tach!

                                  Naja, ich sehe den neuen Absatz und dann den Absatz mit dem output darin. Oder worauf sollte sich das beziehen?

                                  Das hat jetzt nichts mit dem Thema zu tun.

                                  Es genügt, eine id einzuschleussen, und schon hast du Gewalt über den Inhalt.

                                  Da hilft nicht mal use strict.

                                  In dem Fall hilft eine Zeile an den Anfang des Javascript-Teils einzufügen, die ich vergessen habe.

                                  const ff = document.querySelector('#ff');

                                  Zumindest solange das zweite id="ff" erst nachfolgend kommt. Ohne diese Zeile hat das nur geklappt, weil Browser selbständig eine Variable für die id angelegt haben. Die zweite id-Zuweisung hat die erste überschrieben. document.querySelector() hingegen sucht im DOM und endet an der ersten Fundstelle.

                                  Dass man clientseitig manipulieren kann, ist halt so in den Browsern. Damit muss man leben. Wenn die Manipulation hingegen unbeabsichtigt durch Dritte - beispielsweise durch XSS - durchgeführt werden konnte, dann hat man irgendwo einen Programierfehler, den man beseitigen muss.

                                  dedlfix.

                                  1. hallo

                                    Da hilft nicht mal use strict.

                                    In dem Fall hilft eine Zeile an den Anfang des Javascript-Teils einzufügen, die ich vergessen habe.

                                    const ff = document.querySelector('#ff');

                                    Zumindest solange das zweite id="ff" erst nachfolgend kommt. Ohne diese Zeile hat das nur geklappt, weil Browser selbständig eine Variable für die id angelegt haben. Die zweite id-Zuweisung hat die erste überschrieben. document.querySelector() hingegen sucht im DOM und endet an der ersten Fundstelle.

                                    Dass man clientseitig manipulieren kann, ist halt so in den Browsern. Damit muss man leben. Wenn die Manipulation hingegen unbeabsichtigt durch Dritte - beispielsweise durch XSS - durchgeführt werden konnte, dann hat man irgendwo einen Programierfehler, den man beseitigen muss.

                                    Es dringt nur langsam in mein Bewusstsein, wie problematisch ids eigentlich sein können. Dass man da unbewusst überall Objektreferenzen im window scope erzeugt, ist eigentlich nicht wünschenswert, und verstärkt nur mein aus der CSS Praxis stammende Erfahrung, dass IDs möglichst zu vermeiden sind.

                                    Ein 'use strict id' wäre wünschenswert, wonach ids nur über Attribut-Methoden oder via Objekt-Eigenschaften zugänglich sind.

                                    -- Neu im Forum! Signaturen kann man ausblenden!
                                    1. Tach!

                                      Es dringt nur langsam in mein Bewusstsein, wie problematisch ids eigentlich sein können.

                                      Nein, problematisch ist lediglich, dass ich die Variable ff nicht initialisiert habe. Wenn ich den Code mit einer IDE geschrieben hätte, wäre ich von dieser auch darauf aufmerksam gemacht worden, ff nicht initialisiert zu haben.

                                      dedlfix.

                      2. Hallo dedlfix,

                        Mir scheint, du rufst an irgendeiner Stelle das toString() von FormData auf und schickst das Ergebnis anschließend durch URLSearchParams. Wenn ich das so falsch durchführe, bekomme ich auch dieses falsche Ergebnis.

                        Also quasi

                        URLSearchParams(new FormData(ff).toString());

                        statt

                        URLSearchParams(new FormData(ff)).toString();

                        ?

                        Bis demnächst
                        Matthias

                        -- Rosen sind rot.
                        1. Tach!

                          Mir scheint, du rufst an irgendeiner Stelle das toString() von FormData auf und schickst das Ergebnis anschließend durch URLSearchParams. Wenn ich das so falsch durchführe, bekomme ich auch dieses falsche Ergebnis.

                          Also quasi

                          URLSearchParams(new FormData(ff).toString());

                          statt

                          URLSearchParams(new FormData(ff)).toString();

                          ?

                          Zumindest bekommt man so das gezeigte falsche Ergebnis. Also, wenn man dann noch ein zweites toString() an das URLSearchParams selbst hängt, damit man den Querystring bekommt.

                          dedlfix.

                          1. Hallo dedlfix,

                            Zumindest bekommt man so das gezeigte falsche Ergebnis. Also, wenn man dann noch ein zweites toString() an das URLSearchParams selbst hängt, damit man den Querystring bekommt.

                            Der simple Klammerfehler liefert bei mir als HTML-Ausgabe %5Bobject+FormData%5D=, also genau das, was pl immer schreibt. console.log liefert URLSearchParams { }

                            Hänge ich ein zweites toString an, erscheint das falsche Ergebnis auch in der Konsole.

                            Endergebnis: PL hat sich mit großer Sicherheit beim Abschreiben mit den Klammern vertan.

                            Bis demnächst
                            Matthias

                            -- Rosen sind rot.

                            Folgende Nachrichten verweisen auf diesen Beitrag:

                            1. Tach!

                              Endergebnis: PL hat sich mit großer Sicherheit beim Abschreiben mit den Klammern vertan.

                              Das ist auch meine Vermutung. Allerdings kann/möchte ich nicht prüfen, was tatsächlich bei alten Browsern rauskommt, die URLSearchParams nicht gemäß der aktuellen Spezifikation implementiert haben. Das kann durchaus auch zum gesehenen Verhalten geführt haben, dass URLSearchParams vom übergebenen Argument einfach toString() aufruft, was ja bei FormData abseits der von Object geerbten Version nicht vorhanden ist.

                              dedlfix.

          2. @dedlfix

            Nein, es sendet multipart/form-data im Body und erzeugt damit keine Serialisierung für die URL, so wie es die jQuery-Funktion macht.

            jQuery(form).serialize() serialisiert den Default Enctype. Da steckt zwar das Wort urlencoded drin aber daß heißt ja nicht, daß man diesen String grundsätzlich an den URL anhängt. Mit Request Method POST nämlich wird genau derselbe String im Message Body gesendet!

            Das heißt daß der Enctype application/x-www-form-urlencoded unabhängig von der beabsichtigten Requestmethode ist.

            MfG

      2. Tach!

        Enctype application/x-www-form-urlencoded

        Geht als Einzeiler:

        const form = new FormData(); form.append('foo', 'bar'); form.append('qux', 'baz'); const serialized = Array.from(form) .map(field => `${encodeURIComponent(field[0])}=${encodeURIComponent(field[1])}`) .join('&');

        Nein geht nicht als Einzeiler. FormData liefert einen ganz anderen Content-Type (Enctype siehe obenstehend).

        Array.from().. muss ich mir anschauen.

        MfG

        1. Tach!

          Enctype application/x-www-form-urlencoded

          Geht als Einzeiler:

          const form = new FormData(); form.append('foo', 'bar'); form.append('qux', 'baz'); const serialized = Array.from(form) .map(field => `${encodeURIComponent(field[0])}=${encodeURIComponent(field[1])}`) .join('&');

          Nein geht nicht als Einzeiler. FormData liefert einen ganz anderen Content-Type (Enctype siehe obenstehend).

          Doch, doch, das Ergebnis ist genau dasselbe. Und DormData liefert überhaupt keinen Content-Type. Das ist lediglich eine Verwaltungsstruktur für Formulardaten. Daten gemäß einem bestimmten Content-Type im HTTP-Sinne entsteht erst bei weiterer Verarbeitung anderenorts, beispielsweise beim Aufruf von XMLHttpRequest.send() oder oben gezeigtem Code oder new URLSearchParams(form).toString().

          Array.from().. muss ich mir anschauen.

          Array.from() ist nur ein Hilfskonstrukt, um aus einer iterierbaren Sequenz ein richtiges Array zu bekommen, auf das man dann Array-Methoden wie die hier verwendeten map() und join() anwenden zu können.

          dedlfix.

          1. Tach!

            Enctype application/x-www-form-urlencoded

            Geht als Einzeiler:

            const form = new FormData(); form.append('foo', 'bar'); form.append('qux', 'baz'); const serialized = Array.from(form) .map(field => `${encodeURIComponent(field[0])}=${encodeURIComponent(field[1])}`) .join('&');

            Nein geht nicht als Einzeiler. FormData liefert einen ganz anderen Content-Type (Enctype siehe obenstehend).

            Doch, doch, das Ergebnis ist genau dasselbe. Und DormData liefert überhaupt keinen Content-Type.

            Da bist Du völlig falsch informiert.

            Das ist lediglich eine Verwaltungsstruktur für Formulardaten.

            Das ist Unsinn. Schau Dir bitte hier an, welchen Content-Type FormData liefert und wie FormData die Daten serialisiert.

            Daten gemäß einem bestimmten Content-Type im HTTP-Sinne entsteht erst bei weiterer Verarbeitung anderenorts,

            OOP Overload ist hierzu das Zauberwort. Und genau das funktioniert auch nur weil die Daten bereits gemäß dem Enctype multipart/form-data in der FormDatainstanz vorliegen.

            beispielsweise beim Aufruf von XMLHttpRequest.send()

            Nein. Richtig wäre xhr.send(FormDatainstanz); Die Instanz wird übergeben!

            Hier wird implizit aus der Instanz ein String gemacht: Aufgrund des String-Kontext greift hier das Overload.

            MfG

            1. Tach!

              Doch, doch, das Ergebnis ist genau dasselbe. Und DormData liefert überhaupt keinen Content-Type.

              Da bist Du völlig falsch informiert.

              Das ist lediglich eine Verwaltungsstruktur für Formulardaten.

              Das ist Unsinn. Schau Dir bitte hier an, welchen Content-Type FormData liefert und wie FormData die Daten serialisiert.

              Auch da sehe ich nicht, dass FormData irgendwelche Daten in einem bestimmten Content-Type liefert. Das FormData-Objekt wird da ebenfalls komplett an XMLHttpRequest.send() übergeben, und das ist alles für FormData. FormData definiert keinerlei Methoden, um Daten in einen bestimmten Content-Type umzuwandeln.

              Daten gemäß einem bestimmten Content-Type im HTTP-Sinne entsteht erst bei weiterer Verarbeitung anderenorts,

              OOP Overload ist hierzu das Zauberwort. Und genau das funktioniert auch nur weil die Daten bereits gemäß dem Enctype multipart/form-data in der FormDatainstanz vorliegen.

              Das müsstest du beweisen. Und das wird schwer. FormData ist als Interface definiert, und da steht keine konkrete Implementation dahinter. Was da also wie im Inneren der Browser oder anderer Javascript-Implementationen vorliegt, ist nicht definiert. Lediglich das Interface und seine Methoden sind festgelegt, und darunter ist keine, die einen Content-Type liefert.

              beispielsweise beim Aufruf von XMLHttpRequest.send()

              Nein. Richtig wäre xhr.send(FormDatainstanz);

              Hier wird implizit aus der Instanz ein String gemacht: Aufgrund des String-Kontext greift hier das Overload.

              Aber ganz sicher nicht von der FormData-Instanz. Was für ein Overload soll da vorhanden sein? Es ist auch gar nicht Aufgabe von FormData, sich in alle möglichen Zielformate ausgeben zu können. Das ginge zwar, wird aber schon seit längerem als schlechter Stil angesehen und stattdessen eine Aufgabentrennung praktiziert. FormDatas Aufgabe ist, einfachen Zugriff auf Formulardaten zu gewähren. Genau dafür sind Methoden definiert und für nichts anderes. Wenn eine andere Komponente für ihre Aufgabe die Daten in einer bestimmten Form braucht, muss sie sich selbst darum kümmern, wie sie die umformt, oder welche Komponenten sie zur Umformung beauftragt.

              dedlfix.

              Folgende Nachrichten verweisen auf diesen Beitrag:

              1. Tach!

                Doch, doch, das Ergebnis ist genau dasselbe. Und DormData liefert überhaupt keinen Content-Type.

                Da bist Du völlig falsch informiert.

                Das ist lediglich eine Verwaltungsstruktur für Formulardaten.

                Das ist Unsinn. Schau Dir bitte hier an, welchen Content-Type FormData liefert und wie FormData die Daten serialisiert.

                Auch da sehe ich nicht, dass FormData irgendwelche Daten in einem bestimmten Content-Type liefert. Das FormData-Objekt wird da ebenfalls komplett an XMLHttpRequest.send() übergeben, und das ist alles für FormData. FormData definiert keinerlei Methoden, um Daten in einen bestimmten Content-Type umzuwandeln.

                Entscheidend ist der Kontextwechsel! Und bei xhr.send(formdata) heißt der Kontext String. Gesendet wird also ein String mit eben diesem Content-Type und genausogut kann man denselben String vom Server zum Browser senden und dort die Einzelnen Parts wiederherstellen.

                Hinter dieser Magie steckt Overload/OOP, damit wird bei einem Kontextwechel implizit eine Methode aufgerufen. Andere PLs reichen diese Methode mit dem Namen toString() nach draußen.

                Daten gemäß einem bestimmten Content-Type im HTTP-Sinne entsteht erst bei weiterer Verarbeitung anderenorts,

                OOP Overload ist hierzu das Zauberwort. Und genau das funktioniert auch nur weil die Daten bereits gemäß dem Enctype multipart/form-data in der FormDatainstanz vorliegen.

                Das müsstest du beweisen. Und das wird schwer.

                Meine oben verlinkte Anwendung zeigt es doch. Und hier in einer anderen Anwendung zeige ich Dir den umgekehrten Fall welchen die fetchAPI ermöglicht: Aus der Response die mit dem Enctype multipart/form-data gesendet wurde, eine FormData Instanz wiederherzustellen.

                Das ist ja auch der Sinn von OOP interne Vorgänge über genau definierte Schnittstellen nach draußen zu reichen und zwar so daß sich in Anwender nicht darum kümmern muss was intern abläuft. Nun, daß FormData eine Methode toString() nicht bereitstellt, heißt ja noch lange nicht, daß es eine Solche nicht gibt. Wer schon einmal OO entwickelt hat, wird jedoch wissen, daß es public und private Methods gibt.

                Den Overload hier im Detail zu erklären würde jedoch schon sehr am Thema vorbeigehen. Aber zum Thema Kontextechsel gibt es ja einen Artikel in Eurem Wiki.

                MfG

                1. Tach!

                  Entscheidend ist der Kontextwechsel! Und bei xhr.send(formdata) heißt der Kontext String.

                  Das kann ich nicht als richtig akzeptieren. Die MDN führt eine ganze Reihe von Dingen auf, die XHR.send() akzeptiert.

                  A body of data to be sent in the XHR request. This can be:

                  • A Document, in which case it is serialized before being sent.
                  • A BodyInit, which as per the Fetch spec can be a Blob, BufferSource, FormData, URLSearchParams, ReadableStream, or USVString object.

                  String ist nur eine der Möglichkeiten. Und selbst wenn alles nach String konvertiert werden würde, und das von den jeweils übergebenen Objekten selbst gemacht werden würde, wäre da doch deren toString() zuständig. Und das liefert bei FormData lediglich das, was FormData von Object geerbt hat, ein unbrauchbares "[object FormData]".

                  Der Rest wird dann auch nicht mehr wahrer.

                  Meine oben verlinkte Anwendung zeigt es doch.

                  Sie zeigt das überhaupt nicht. Sie zeigt lediglich eine Art Blackbox, die wie gewünscht arbeitet. Aber dass sie intern das von dir beschriebene Verhalten bezüglich FormData an den Tag legen würde, zeigt sie mitnichten.

                  Und hier in einer anderen Anwendung zeige ich Dir den umgekehrten Fall welchen die fetchAPI ermöglicht: Aus der Response die mit dem Enctype multipart/form-data gesendet wurde, eine FormData Instanz wiederherzustellen.

                  Das ist zwar irrelevant, beweist aber auch nichts. Dass Response.formData() letztlich ein FormData liefert, heißt noch lange nicht, dass FormData selbst eine Umwandlung durchführen würde. Dazu sehe ich in der FormData-Dokumentation keinerlei Hinweise, dass es ein solches Verhalten hat. Auch nimmt der Konstruktor lediglich ein HTMLFormElement entgegen und keine Response. Das FormData-Objekt wird also wohl lediglich zu Fuß über append()-Aufrufe gefüllt werden, egal wer nun die konkrete Dekodierung des Response-Strings vornimmt. append() nimmt bereits fertige Paare aus Key (Strings) und Values (String oder Blob) entgegen. Es sieht also nicht danach aus, dass FormData eine vollständige Response dekodieren würde.

                  Das ist ja auch der Sinn von OOP interne Vorgänge über genau definierte Schnittstellen nach draußen zu reichen und zwar so daß sich in Anwender nicht darum kümmern muss was intern abläuft.

                  Es ist auch nicht Sinn der OOP, über interne Dinge, die nicht außen sichtbar sind, Mutmaßungen anzustellen, die sich nicht mit dem Rest der sichtbaren Dinge decken.

                  Nun, daß FormData eine Methode toString() nicht bereitstellt, heißt ja noch lange nicht, daß es eine Solche nicht gibt. Wer schon einmal OO entwickelt hat, wird jedoch wissen, daß es public und private Methods gibt.

                  Ja natürlich. Weil man private Methoden ja auch so wunderbar von außen aufrufen kann. Nicht.

                  Den Overload hier im Detail zu erklären würde jedoch schon sehr am Thema vorbeigehen. Aber zum Thema Kontextechsel gibt es ja einen Artikel in Eurem Wiki.

                  Schade, ich dachte, da kommt noch was Fundiertes außer nicht nachvollziehbaren Mutmaßungen und fehlerhaften Aussagen. Bis zu der Stelle, was der Wiki-Artikel beschreibt, sind wir gar nicht gekommen. Deine Beweisführung brach schon vorher in sich zusammen.

                  dedlfix.

                  1. Tach!

                    Entscheidend ist der Kontextwechsel! Und bei xhr.send(formdata) heißt der Kontext String.

                    Das kann ich nicht als richtig akzeptieren. Die MDN führt eine ganze Reihe von Dingen auf, die XHR.send() akzeptiert.

                    A body of data to be sent in the XHR request. This can be:

                    • A Document, in which case it is serialized before being sent.
                    • A BodyInit, which as per the Fetch spec can be a Blob, BufferSource, FormData, URLSearchParams, ReadableStream, or USVString object.

                    String ist nur eine der Möglichkeiten.

                    Abstrakt gesehen ist das alles Stringkontext, auch der Blob. Allgemein handelt es sich um Bytesequenzen und somit kommen wir wieder zum Wirth'schen Dateibegriff ohne den es mp3 gar nicht geben würde.

                    Aber zurück zu den Sequenzen, ein xhr.send(blob) bewirkt, daß in STDIN serverseitig eine Bytesequenz zu lesen ist. Dasselbe bei xhr.send('äöü') und natürlich auch wenn ein ArrayBuffer gesendet wird.

                    Selbst in JS kann man zwischen Blob, USVString ArrayBuffer vermitteln, new Blob(['äöü']); als Beispiel.

                    Für uns als Informationstechniker ist das Entscheidende an den von Dir o.g. Datentypen, daß der Informationsgehalt derselbe ist. Und genau das zeigen die von mir verlinkten Anwendungen!

                    Und dahinter steckt eben der Fakt, daß Daten nicht als Objekte, Arrays, Blob usw, übertragen werden sondern grundsätzlich als Bytesequenzen. Wenn man serverseitig also ein äöü in STDIN bekommt, ist es unerheblich ob diese Sequenz aus der Sicht von JS als Blob, File, ArrayBuffer oder String gesendet wurde, der Inhalt ist absolut derselbe.

                    Umgekehrt ist das ganz analog: Eine serverseitige gesendete Sequenz äöü kann JS im Browser als Blob, File, ArrayBuffer oder als Text/String empfangen und, wie bereits dargelegt, die FetchAPI kann aus einem Messagebody sogar ein FormData Objekt erstellen.

                    Also ich denke schon, daß der Begriff Stringkontext hier trefflich passt. Letztendlich sind das ja auch alles grundsätzliche Dinge die sich in der IT über Jahrzehnte entwickelt haben und nicht auf meinem Desktop. Inwieweit zwischen String und Bytesequenz unterschieden wird, daß regeln die einzelnen Programmiersprachen, somit ist das überhaupt ein Streitthema.

                    Und selbst wenn hierfür einmal nicht der exakte Fachbegriff benutzt würde, so sollte doch wenigstens klar sein worum es geht.

                    MfG

                    1. Tach!

                      [...]

                      Du lenkst vom Thema ab. Der strittige Punkt war deine Behauptung, FormData würde sich selbst umkodieren. Diese Behauptung hast du damit mitnichten belegt.

                      Also ich denke schon, daß der Begriff Stringkontext hier trefflich passt.

                      Das denke ich nicht, denn "String" ist in diem Fall viel zu allgemein. Was letztlich über die Leitung geht, ist ein String. Und selbst das ist nicht richtig, denn er kann immer noch gemäß der verschiedenen Typen des Transfer-Encodings formatiert sein. Abgesehen vom Transfer-Encoding ist es auch nicht nur "Stringkontext", sondern dieser String hat ebenfalls ein bestimmtes Format. Der Kontext ist also nicht einfach nur "String", sondern beispielsweise application/x-www-form-urlencoded and multipart/form-data. Und diese Format ist erstmal das, in das die Formulardaten zu bringen sind.

                      dedlfix.

                      1. Tach!

                        [...]

                        Du lenkst vom Thema ab. Der strittige Punkt war deine Behauptung, FormData würde sich selbst umkodieren. Diese Behauptung hast du damit mitnichten belegt.

                        Also ich denke schon, daß der Begriff Stringkontext hier trefflich passt.

                        Das denke ich nicht, denn "String" ist in diem Fall viel zu allgemein.

                        Umgekehrt: String ist ein Sonderfall für ein Scalar. Skalarer Kontext wäre also richtiger.

                        Was letztlich über die Leitung geht, ist ein String. Und selbst das ist nicht richtig, denn er kann immer noch gemäß der verschiedenen Typen des Transfer-Encodings formatiert sein.

                        Über die Leitung geht eine Bytesequenz die gar keine Kodierung kennt. Letzerere wird nämlich in einem Header Content-Type: text/html; charset=utf-8 (Beispiel) übertragen.

                        Der Kontext ist also nicht einfach nur "String", sondern beispielsweise application/x-www-form-urlencoded and multipart/form-data. Und diese Format ist erstmal das, in das die Formulardaten zu bringen sind.

                        Um auch das mal wieder richtig zu stellen: application/x-www-form-urlencoded and multipart/form-data sind nicht der Kontext sondern das sind Enctypes bzw. Content-Types.

                        Beispiel: Content-Type: multipart/form-data; boundary=---__xy__----

                        Der Skalare Kontext ergibt sich über die gesamte Übertragungsstrecke, weil diese transparent ist. Transparenz heiß z.B.:

                        Sende ich einen String, bekomme ich einen String. Sende ich ein Objekt, bekomme ich ein Objekt.

                        Transparenz heißt: Dazwischen ist nichts.

                        MfG

                        1. Tach!

                          Was letztlich über die Leitung geht, ist ein String. Und selbst das ist nicht richtig, denn er kann immer noch gemäß der verschiedenen Typen des Transfer-Encodings formatiert sein.

                          Über die Leitung geht eine Bytesequenz die gar keine Kodierung kennt. Letzerere wird nämlich in einem Header Content-Type: text/html; charset=utf-8 (Beispiel) übertragen.

                          Das ist alles eine Betrachtungsfrage, in welcher Schicht wir uns befinden. Aber eigentlich waren diese unteren Schichten bisher kein Thema, eher nur ein Ablenkungsmanöver deinerseits. Und es ist auch zur Klärung der offenen Fragen nicht weiter hilfreich.

                          Der Skalare Kontext ergibt sich über die gesamte Übertragungsstrecke, weil diese transparent ist. Transparenz heiß z.B.:

                          Sende ich einen String, bekomme ich einen String. Sende ich ein Objekt, bekomme ich ein Objekt.

                          Transparenz heißt: Dazwischen ist nichts.

                          Achja, und diese Transparenz kommt einfach so aus dem Nichts beziehungsweise "ist nichts"? Mitnichten. Das was du da als Transparenz bezeichnest und wegzudiskutieren meinst, ist konkreter Code. Um Teile dieses konkreten Codes ging es, nicht um eine von außen betrachtete Wegabstrahierung.

                          Siehe die von dir gesetzte Überschrift in diesem Teilthread: "FormData toString und Kontextwechsel". FormData hat kein eigenes toString(), es erbt über die Prototype-Chain das toString() von Object. Da ist also nach wie vor nichts, was irgendwie in die von dir angeschnittene Diskussionsrichtung passt.

                          dedlfix.

                          1. @dedlfix

                            Transparenz heißt: Dazwischen ist nichts.

                            Achja, und diese Transparenz kommt einfach so aus dem Nichts beziehungsweise "ist nichts"?

                            Natürlich nicht! Dafür muss man was tun, von alleine kommt da gar nichts!

                            Mitnichten. Das was du da als Transparenz bezeichnest und wegzudiskutieren meinst, ist konkreter Code. Um Teile dieses konkreten Codes ging es, nicht um eine von außen betrachtete Wegabstrahierung.

                            Diese konkreten Dinge sind Enctype, Serializer, Content-Type, Bytesequenzen und das Protokoll selbst (HTTP) / ohne Anspruch auf Vollständigkeit, aber ich habe das alles hier mehr als nur einmal aufgeführt und zwar im richtigen Zusammenhang.

                            Und: Das kürzeste Stück Code nützt niemandem der die Grundlagen nicht versteht.

                            Siehe die von dir gesetzte Überschrift in diesem Teilthread: "FormData toString und Kontextwechsel". FormData hat kein eigenes toString(), es erbt über die Prototype-Chain das toString() von Object. Da ist also nach wie vor nichts, was irgendwie in die von dir angeschnittene Diskussionsrichtung passt.

                            Na, das passt doch ausgezeichnet!

                            MfG

                            -- niemand braucht mehr als 640kb ram in seinem pc ... Danke Bill! Heutige Programmierer brauchen 8GB und kriegen trotzdem nichts gebacken!
                    2. Tach!

                      Entscheidend ist der Kontextwechsel! Und bei xhr.send(formdata) heißt der Kontext String.

                      Das kann ich nicht als richtig akzeptieren. Die MDN führt eine ganze Reihe von Dingen auf, die XHR.send() akzeptiert.

                      A body of data to be sent in the XHR request. This can be:

                      • A Document, in which case it is serialized before being sent.
                      • A BodyInit, which as per the Fetch spec can be a Blob, BufferSource, FormData, URLSearchParams, ReadableStream, or USVString object.

                      String ist nur eine der Möglichkeiten.

                      Das von Dir sehr schön beschriebene Verhalten bezüglich Funktionsargument ist übrigens ganz typisch für OOP/Overload.

                      MfG

                      Folgende Nachrichten verweisen auf diesen Beitrag:

                      1. Tach!

                        String ist nur eine der Möglichkeiten.

                        Das von Dir sehr schön beschriebene Verhalten bezüglich Funktionsargument ist übrigens ganz typisch für OOP/Overload.

                        Overload ist eine praktische Angelegenheit. Weil es so gut passt, hier ein weiterer typischer Anwendungsfall (Stringkontext). Betrachte untenstehende Datenstruktur in Perl

                        $var = { 'content_length' => '17479', 'content_type' => 'image/jpeg', 'filename' => 'eichelberg.jpg', 'iohandle' => bless( \*Symbol::GEN3, 'IO::String' ), 'mtime' => '1386763302', 'mtime_gm' => 'Wed Dec 11 12:01:42 2013', 'mtime_local' => 'Wed Dec 11 13:01:42 2013', 'name' => 'upspot' };

                        So könnte man mit $var->{iohandle} auf ebendieses zugreifen um den Inhalt der Datei auszulesen. Man könnte aber auch $var zu einer Instanz einer Klasse machen und den Operator "" überladen. Somit kriegt man den Inhalt ganz einfach mit "$var" as string so daß eine getMethode $var->getContent() entfallen kann.

                        MfG

                2. Hallo pl

                  Wer schon einmal OO entwickelt hat, wird jedoch wissen, daß es public und private Methods gibt.

                  Wer schon in mehr als einer Sprache OO entwickelt hat, wird wahrscheinlich wissen, dass nicht jede objektorientierte Programmiersprache auch Mechanismen für die Kapselung von Daten bereitstellt. In ECMAScript gibt es bis dato keine Möglichkeit, den Zugriff auf Eigenschaften und Methoden durch entsprechende Syntax zu beschränken.

                  Gleiches gilt im Übrigen für Python. Auch hier gilt, dass Eigenschaften und Methoden prinzipiell von außerhalb angesprochen, beziehungsweise aufgerufen werden können. Eine Abgrenzung zwischen öffentlicher Schnittstelle und interner Implementierung erfolgt hier im Wesentlichen über Namenskonventionen. Soll eine Eigenschaft oder Methode privat sein, wird ihrem Namen ein Unterstrich vorangestellt.

                  class Container: def __init__(self): self.__data = [] def _internal_method(self): pass Container().__data.append('value') # AttributeError

                  Python besitzt allerdings einen Mechanismus namens Name Mangling. Wird ein Eigenschafts- oder Methodenname wie in dem Beispiel oben mit zwei Unterstrichen geprefixt, statt bloß mit einem, dann kann die Eigenschaft oder Methode von außerhalb des Objektes nur durch explizite Angabe des Klassennamens referenziert werden.

                  Container()._Container__data.append('value')

                  Darüber hinaus gibt es in vielen Programmiersprachen Möglichkeiten, Funktionen die nicht Teil der öffentlichen Schnittstelle sind, in Namensräumen zu kapseln. Das kann ein Modul sein, das standardmäßig nur die Klasse selbst exportiert, nicht jedoch die im globalen Gültigkeitsbereich definierten internen Funktionen, oder ein Funktionsabschluss, wie im folgenden ECMAScript-Beispiel.

                  const Stack = function() { const data = []; // push and pop can access data via closure return class Stack { push(value) { return data.push(value), this; } pop() { return data.pop(); } }; }(); new Stack().push('value').pop(); // 'value'

                  Hier wird ein unmittelbar aufgerufener Funktionsausdruck dazu genutzt, das in der Konstante hinterlegte Array vor unbefugten Zugriffen zu schützen. Die Methoden push und pop können auch nach der Abarbeitung der äußeren anonymen Funktion über die Scope Chain auf das Array zugreifen, Code von außerhalb jedoch nicht.

                  Gruß,

                  Orlok

                  -- „Dance like it hurts.
                  Make love like you need money.
                  Work when people are watching.“ — Dogbert
                  1. hi,

                    Gleiches gilt im Übrigen für Python. Auch hier gilt, dass Eigenschaften und Methoden prinzipiell von außerhalb angesprochen, beziehungsweise aufgerufen werden können. Eine Abgrenzung zwischen öffentlicher Schnittstelle und interner Implementierung erfolgt hier im Wesentlichen über Namenskonventionen. Soll eine Eigenschaft oder Methode privat sein, wird ihrem Namen ein Unterstrich vorangestellt.

                    Das ist in Perl genauso. Und was Overload betrifft: toString() und das kann man übrigens auch mit FileHandles machen. Beispielsweise so, daß ein print $fh den Inhalt der Datei ausgibt auf welcher das Handle erstellt wurde. Und in Perl ist es seit Jahren Best Practice daß Funktionen sowohl mit Dateinamen als auch mit Handles gleichermaßen operieren, siehe auch <> (Diamond OP).

                    Aber schön daß Du es ansprichst, gerade den Stringkontext kann man mit OOP/Overload nämlich sehr zweckmäßig implementieren.

                    Das wäre auch ein Thema für den SELF Wiki, Vorschlag ist hier

                    MfG

                    1. Hallo pl,

                      Das wäre auch ein Thema für den SELF Wiki, Vorschlag ist hier

                      Antwort auch

                      Bis demnächst
                      Matthias

                      -- Rosen sind rot.
                  2. Moin Orlok,

                    zwei Fragen:

                    class Container: def __init__(self): self.__data = [] def _internal_method(self): pass Container().__data.append('value') # AttributeError

                    Python besitzt allerdings einen Mechanismus namens Name Mangling. Wird ein Eigenschafts- oder Methodenname wie in dem Beispiel oben mit zwei Unterstrichen geprefixt, statt bloß mit einem, dann kann die Eigenschaft oder Methode von außerhalb des Objektes nur durch explizite Angabe des Klassennamens referenziert werden.

                    Container()._Container__data.append('value')

                    Fehlt hier nicht irgendwo ein Punkt, z.B. Container().Container.__data.append('value')?

                    const Stack = function() { const data = []; // push and pop can access data via closure return class Stack { push(value) { return data.push(value), this; } pop() { return data.pop(); } }; }(); new Stack().push('value').pop(); // 'value'

                    Man kann das innere data-Array verändern, obwohl es const ist?

                    Viele Grüße
                    Robert

                    1. Tach!

                      Fehlt hier nicht irgendwo ein Punkt, z.B. Container().Container.__data.append('value')?

                      Nein, das hat gemäß den nachlesbaren Regel so gestimmt.

                      Man kann das innere data-Array verändern, obwohl es const ist?

                      data bleibt konstant und wurde nicht verändert. Diese Variable verweist immer nur auf dieselbe Instanz von Array. Dass sich die Eigenschaften des Arrays ändern, ist dabei nicht von Belang.

                      dedlfix.

                      1. Moin dedlfix,

                        Fehlt hier nicht irgendwo ein Punkt, z.B. Container().Container.__data.append('value')?

                        Nein, das hat gemäß den nachlesbaren Regel so gestimmt.

                        Wo sind die denn nachzulesen?

                        Man kann das innere data-Array verändern, obwohl es const ist?

                        data bleibt konstant und wurde nicht verändert. Diese Variable verweist immer nur auf dieselbe Instanz von Array. Dass sich die Eigenschaften des Arrays ändern, ist dabei nicht von Belang.

                        Die Referenz ist konstant. OK, das ist ein Unterschied zu

                        #include <vector> int main() { const std::vector<int> v; v.push_back(1); return 0; }

                        g++ -Wall -pedantic -std=c++11 constvec.cpp -o constvec

                        constvec.cpp: In function ‘int main()’:
                        constvec.cpp:6:15: error: passing ‘const std::vector<int>’ as ‘this’ argument discards qualifiers [-fpermissive]
                        v.push_back(1);

                        Viele Grüße
                        Robert

                        1. Hallo Robert,

                          Die Referenz ist konstant. OK, das ist ein Unterschied zu

                          #include <vector> int main() { const std::vector<int> v; v.push_back(1); return 0; }

                          Ja, das fand ich anfangs auch schwer zu akzeptieren, dass die dynamischen Sprachen const einfach umdefiniert haben.

                          LG,
                          CK

                          -- https://wwwtech.de/about
                        2. Tach!

                          Fehlt hier nicht irgendwo ein Punkt, z.B. Container().Container.__data.append('value')?

                          Nein, das hat gemäß den nachlesbaren Regel so gestimmt.

                          Wo sind die denn nachzulesen?

                          Im Handbuch, und der Wikipedia. Ich hab nach dem gegebenen Stichwort name mangling gesucht.

                          Die Referenz ist konstant. OK, das ist ein Unterschied zu

                          Ich kann C und C++ nicht lesen. Dazu kann ich also nichts weiter sagen. Deswegen hier ein anderer Erklärungsversuch.

                          Bei Variablen muss man generell zwei Dinge trennen, die Verwaltungsstruktur und der eigentliche Inhalt. Das ist vielleicht nicht ganz korrekt für alle Programmiersprachen, aber als Modell vorgestellt, sollte die Erklärung passen. Variablen sind im Grunde genommen Verwaltungsstrukturen. Skalare/einfache Variablen haben ihren Inhalt mit an Bord in einem Feld dieser Verwaltungsstruktur. Das betrifft zum Beispiel Integer oder Boolean. Die haben eine übersichtlich kleine und feststehende Größe von wenigen Bytes. Bei komplexen Dingen hingegen wird der Inhalt anderenorts abgelegt und die Verwaltungsstruktur enthält lediglich einen Verweis auf diesen Inhalt. Die Verwaltungsstruktur bleibt in sich konstant, wenn sich dieser Verweis nicht ändert, also immer auf dieselbe Speicherstelle zeigt. Die Verwaltungsstruktur überwacht aber nicht den Inhalt am Ziel. Der kann sich beliebig ändern.

                          In diesem Modell zählen auch Strings zu den skalaren Typen, obwohl der Inhalt der Strings eigentlich aufgrund seiner unterschiedlichen Länge ebenfalls anderenorts abgelegt wird und die Verwaltungsstruktur nicht den Inhalt sondern eine Referenz verwaltet. Stringinhalte können sich trotzdem nicht einfach so ändern, denn Stringoperationen arbeiten üblicherweise nicht im für den String zugewiesenen Speicher, sondern das Ergebnis der Operation wird anderenorts neu angelegt und die Verwaltungsstruktur bekommt einen neuen Verweis zum Speichern. Das darf aber bei const nicht sein, und deshalb ändert sich auch bei konstanten Stringvariablen nie der Inhalt.

                          Wie ist das aber bei Objekten zu sehen? Bei streng typisierten Sprachen ändert sich zur Laufzeit nichts am Umfang der Eigenschaften, die ein Objekt hat. Die Eigenschaften sind ihrerseits wieder Verwaltungsstrukturen wie bei den Variablen. Diese liegen an festen Positionen im Speicherbereich des Objekts. Ob sie ihrerseits skalar sind oder referenzieren, ist egal, die Verwaltungsstruktur verbleibt immer am selben Ort. Ihr Inhalt kann sich ändern, das ist völlig unabhängig vom const oder nicht der Verwaltungsstruktur des Objekts. Die Eigenschaften können aber ihrerseits als readonly oder const gekennzeichnet sein (bei Javascript nicht, aber in anderen Sprachen) und unterliegen dann denselben Nicht-Änderungs-Regeln wie eigenständige Variablen.

                          Bei Sprachen wie Javascript, wenn zur Laufzeit Eigenschaften hinzukommen oder entfernt werden können, verändert sich auch nicht direkt das Objekt. Es muss also auch nicht neuer Speicherplatz angefordert werden, der größer als der bisherige ist, und dann die Referenz in der Variable umgeschrieben werden. Stattdessen verwaltet man da eine Referenz auf eine Liste, in der die Eigenschaften verwaltet werden. Der Inhalt der Liste kann sich beliebig ändern. Somit bleibt also auch die Objekt-Variable an sich konstant, sie selbst hat keinen Bedarf, sich gegebenenfalls zu vergrößern, und kann deshalb immer am selben Speicherort liegen.

                          dedlfix.

                          1. Moin dedlfix,

                            Wo sind die denn nachzulesen?

                            Im Handbuch, und der Wikipedia. Ich hab nach dem gegebenen Stichwort name mangling gesucht.

                            Schade, dass du uns an den Funden nicht teilhaben lässt.

                            Viele Grüße
                            Robert

                            1. Tach!

                              Wo sind die denn nachzulesen?

                              Im Handbuch, und der Wikipedia. Ich hab nach dem gegebenen Stichwort name mangling gesucht.

                              Schade, dass du uns an den Funden nicht teilhaben lässt.

                              Es ist wirklich nicht schwer, mit dem genannten Stichwort etwas zu finden. Der Wikipedia-Artikel heißt genauso, und wenn man noch python ergänzt, bekommt man auch die Handbuchseite in den Top 5 der Suchergebnisse.

                              dedlfix.

                              1. Moin,

                                Es ist wirklich nicht schwer, mit dem genannten Stichwort etwas zu finden. Der Wikipedia-Artikel heißt genauso, und wenn man noch python ergänzt, bekommt man auch die Handbuchseite in den Top 5 der Suchergebnisse.

                                Es soll ja Suchmaschinen geben, bei denen die Ergebnisse nutzerabhängig sind … Wenn es jetzt noch so etwas wie Verweise oder Hyperlinks … 😉

                                Mit den genannten Stichworten findet man den Artikel tatsächlich total einfach. Jetzt muss die Nachwelt wenigstens nicht mehr suchen.

                                Hyperlinke Grüße
                                Robert

                                1. Tach!

                                  Es soll ja Suchmaschinen geben, bei denen die Ergebnisse nutzerabhängig sind …

                                  Ja, wenn den Nutzer wirklich unterschiedliche Dinge hilfreich sind, zumindest aus Sicht der Suchmaschine. Die Tankstellenpreise aus Region X interessieren in Region Y üblicherweise weniger, weswegen diese Art Suchergebnisse bei allgemeinen Anfragen üblicherweise lokalisiert sind. Bei "name mangling" sehe ich die Gefahr nicht, das ist ein recht eindeutiger Begriff. Lediglich Übersetzungen in andere Sprachen, aber mit vergleichbarem Inhalt werden da als Unterschiede in den Suchergebnissen zu finden sein.

                                  Wenn es jetzt noch so etwas wie Verweise oder Hyperlinks … 😉

                                  Ja, ich weiß um deren Existenz und habe sie auch bei der Antwort zur Nachfrage bewusst weggelassen und stattdessen erklärt, wie man zur Antwort auf die Frage kommt. Links anklicken trainiert die Fähigkeit zur Suchanfragenformulierung nicht so richtig. Das war sozusagen ein Schritt zum Angeln lernen statt nur Fisch hinzuwerfen.

                                  dedlfix.

                          2. Moin noch einmal,

                            der Unterschied zwischen C++ und JavaScript in Bezug auf const ist hier, dass in C++ das gesamte Objekt als konstant angesehen wird, während es in JavaScript anscheinend nur die Verwaltungsinformationen des Objekts sind, wobei Attribute (wie die Länge) offensichtlich nicht zu diesen Informationen gehören.

                            Viele Grüße
                            Robert

                            1. Hallo Robert

                              Der Unterschied zwischen C++ und JavaScript in Bezug auf const ist hier, dass in C++ das gesamte Objekt als konstant angesehen wird, während es in JavaScript anscheinend nur die Verwaltungsinformationen des Objekts sind, wobei Attribute (wie die Länge) offensichtlich nicht zu diesen Informationen gehören.

                              Das ist größtenteils richtig. Konstant ist in JavaScript tatsächlich nur die Bindung zwischen Bezeichner und Wert, wobei der Wert bei Objekten intern – wie dedlfix bereits sagte – bloß ein Verweis auf eine Speicherstelle ist. Solange auf dieselbe Speicherstelle verwiesen wird, ist der Vertrag nicht verletzt. Du musst aber unterscheiden zwischen den Verwaltungsinformationen der Konstanten und denen des Objekts. Das sind zwei voneinander unabhängige Entitäten.

                              Eine Konstante ist aus Implementierungssicht nicht viel Mehr als ein Eintrag in einer Liste, die mit der lexikalischen Umgebung verknüpft ist, in der die Konstante deklariert wurde. Dabei handelt es sich selbst wieder um eine Verwaltungsstruktur, die relevant ist für die Namensauflösung innerhalb des Programms. Die Verwaltungsinformationen für ein Objekt, wie zum Beispiel das Verzeichnis der eigenen Eigenschaften oder der Verweis auf den Prototypen des Objekts, haben damit abgesehen von ein oder zwei Querverweisen nicht viel zu tun. Das wird vielleicht klarer, wenn wir uns ein kleines Beispiel ansehen.

                              // Global scope const a = {}; { // Local scope of block statement const b = a; }

                              Was passiert hier? Zunächst mal wird im globalen Scope eine Konstante deklariert. Dabei wird ein leeres Objekt erzeugt und ein Verweis auf das Objekt wird an den Bezeichner der Konstante gebunden. In JavaScript beschrieben haben wir nun stark vereinfacht folgende Struktur für die globale lexikalische Umgebung:

                              const OuterEnvironment = Symbol(); // Information about lexical environment let GlobalEnvironmentRecord = { // This is the outermost lexical environment [OuterEnvironment]: null, // Binding for constant a: { value: '[[object reference]]', immutable: true } };

                              Es wird an entsprechender Stelle ein Eintrag hinterlegt, der den Namen der Konstanten mit dem Wert verknüpft und ein paar Metainformationen bereitstellt. Nach der Deklaration der Konstanten ist im Quelltext ein Anweisungsblock notiert, der für Konstanten einen eignen Scope repräsentiert. Es wird also für den Block eine neue lexikalische Umgebung erzeugt, wo die Bindung des zuvor erzeugten Objekts an einen lokalen Bezeichner vermerkt wird:

                              let EnvironmentRecord = { // Reference outer lexical environment [OuterEnvironment]: GlobalEnvironmentRecord, // Binding for constant b: { value: '[[object reference]]', immutable: true } };

                              Da innerhalb des Block Statements keine weiteren Anweisungen notiert sind, können die dazugehörigen Verwaltungsinformationen direkt danach wieder entsorgt oder auf die Seite gelegt werden. Sprich, die in dem Block erzeugte Konstante hört auf zu existieren. Die Konstante, die im globalen Scope deklariert wurde, lebt nach Verlassen des Blocks aber weiter und damit auch alle Verwaltungsinformationen, die mit dem referenzierten Objekt verknüpft sind.

                              Eine Konstante in JavaScript zeichnet sich im Wesentlichen dadurch aus, dass in der Verwaltungsstruktur für die Konstante ein Flag gesetzt wird, das signalisiert, dass kein anderer Wert an den Namen der Konstante gebunden werden darf. Es wird aber kein Flag auf dem Objekt gesetzt, das Änderungen an dem Objekt verhindert. Letzteres ist in JavaScript aber auch möglich, wobei verschiedene Varianten zu unterscheiden sind:

                              const object = Object.preventExtensions({}); Object.isExtensible(object); // False // Raises type error in strict mode object.property = 'value';

                              Mit der Methode preventExtensions kann auf dem Objekt ein Flag gesetzt werden das verhindert, dass neue Eigenschaften auf dem Objekt definiert werden. Je nach dem ob das Programm im strikten oder im schlampigen Modus ausgeführt wird, scheitert die Definition einer Eigenschaft entweder still und leise oder es wird ein Typfehler geworfen. Das Flag verhindert aber nicht, dass bereits existierenden Objekteigenschaften neue Werte zugewiesen werden oder das Eigenschaften gelöscht werden.

                              const object = Object.seal({ property: 'value' }); Object.isSealed(object); // true // Raises type error in strict mode delete object.property;

                              Mit der Methode seal kann dafür gesorgt werden, dass die Eigenschaften eines Objekts nicht mehr konfiguriert werden können. Das heißt, es können keine Eigenschaften gelöscht werden und es können nur solchen Eigenschaften neue Werte zugewiesen werden, deren Attribut writable vor der Versiegelung auf true gesetzt war. Auch hier gilt, dass je nach Ausführungsmodus eine unerlaubte Aktion entweder wirkungslos bleibt oder zu einem Typfehler führt.

                              const object = Object.freeze({ property: 'value' }); Object.isFrozen(object); // true // Raises type error in strict mode object.property = 'other value';

                              Schließlich können mit der Methode freeze alle Eigenschaften eines Objekts auf read only gesetzt werden. Zudem können keine Eigenschaften gelöscht oder neu hinzugefügt werden und es kann auch kein neuer Prototyp für das Objekt bestimmt werden. Das Setzen dieses Flags führt aber nicht dazu, dass rekursiv alle Eigenschaften des Objekts abgeklappert werden und das Flag auch auf allen Objekten gesetzt wird, auf die eine Eigenschaft verweist. Objekte als Eigenschaftswert können weiterhin verändert werden. So wie bei den anderen oben beschriebenen Methoden sind die Wirkungen immer auf das Objekt begrenzt, für das die jeweilige Methode aufgerufen wurde.

                              Viele Grüße,

                              Orlok

                              -- „Dance like it hurts.
                              Make love like you need money.
                              Work when people are watching.“ — Dogbert
                          3. Hallo,

                            Skalare/einfache Variablen haben ihren Inhalt mit an Bord in einem Feld dieser Verwaltungsstruktur. Das betrifft zum Beispiel Integer oder Boolean. Die haben eine übersichtlich kleine und feststehende Größe von wenigen Bytes. Bei komplexen Dingen hingegen wird der Inhalt anderenorts abgelegt und die Verwaltungsstruktur enthält lediglich einen Verweis auf diesen Inhalt. Die Verwaltungsstruktur bleibt in sich konstant, wenn sich dieser Verweis nicht ändert, also immer auf dieselbe Speicherstelle zeigt. Die Verwaltungsstruktur überwacht aber nicht den Inhalt am Ziel. Der kann sich beliebig ändern.

                            In Python sind auch Skalare "nur" Referenzen auf den Inhalt. In Python ist alles ein Objekt. So habe ich das zumindest mal gelernt. Orlok weiss das sicher besser.

                            grüße

                            1. Tach!

                              In Python sind auch Skalare "nur" Referenzen auf den Inhalt. In Python ist alles ein Objekt.

                              Das kann durchaus in bestimmten Sprachen anders gelöst sein als meine allgemeiner Erklärungsversuch es beschreibt. Es ist nur für sich genommen etwas sinnlos, wenn der Speicherbedarf für den Verweis in gleicher Größenordnung ist wie der Wert selbst. Da hat man eine Indirektion drin, die keinen Nutzen bringt, aber Zeit kostet, sie aufzulösen. Allerdings kann da auch eine andere Philosophie oder ein technischer Grund dahinterstecken, die/den ich nicht kenne und die/der das System vorteilhaft werden lässt.

                              dedlfix.

                              1. Tach!

                                Achja, den zweiten Teil hatte ich ganz übersehen.

                                In Python ist alles ein Objekt.

                                Das muss aber keine Auswirkungen auf die interne Verarbeitung haben. Alles als Objekt zu sehen, ist vorwiegend eine Philosophie-Frage. Was der Compiler oder das Laufzeitsystem draus macht, steht auf einem anderen Blatt. Neben dem bereits erwähnten Javascript kann ich da auch C# ins Felde führen. Simple Typen lassen sich da genauso objektorientiert verarbeiten wie viele der anderen Typen (einige Spezialtypen mal unbeachted gelassen). Besonders zu erwähnen sind da die Struct-Typen. Das sind objektähnliche komplexe Gebilde inklusive der Möglichkeit, Methoden haben zu können, werden aber genauso wie simple Typen als Value-Typ angesehen und dann auch so verarbeitet, sprich: beispielsweise als Kopie übergeben statt als Referenz.

                                dedlfix.

                            2. Hallo Klaus,

                              In Python sind auch Skalare "nur" Referenzen auf den Inhalt. In Python ist alles ein Objekt. So habe ich das zumindest mal gelernt.

                              Das stimmt:

                              print('Hallo'.upper()) # → 'HALLO'

                              Viele Grüße
                              Robert

                              1. Hallo Robert,

                                das stimmt aber auch in JavaScript:

                                console.log('world'.toUpperCase()); // ⇒ WORLD

                                Rolf

                                -- sumpsi - posui - clusi

                                Folgende Nachrichten verweisen auf diesen Beitrag:

    2. Weitere Infos:

      Enctype application/x-www-form-urlencoded

      Das ist der Default. D.h., er muss nicht angegben werden. Was in einem <form>-Element der Enctype ist, das ist bei einem POST auch gleichzeitig der Content-Type.

      Wenn also notiert wurde <form method="POST" Enctype="application/x-www-form-urlencoded"> wird bei einem Submit aus dem Enctype-Attribute der Request-Header Content-Type. Wurde dieses <form>-Attribute nicht angegeben, wird ein Content-Type-Request-Header gar nicht gesendet. Genau das ist ja der Sinn eines Default.

      Von daher werden wohl die Wenigsten diesen Enctype jemals in Formularen notiert haben. Des Weiteren ist ein Request-Header Content-Type nicht einmal dann notwendig, wenn es einen Message-Body gibt. Jedoch ist in diesem Fall ein Request-Header Content-Lenght erforderlich welcher die Länge des gesendeten Messagebody angibt (Anzahl der Bytes).

      Ob serverseitig ein body in STDIN zu erwarten ist, macht der Server am Requestheader Content-Length fest und nicht etwa an der Requestmethode. Letztere kann ein Client ja auch ZITRONE genannt haben, und ja, mit fetch() ist das auch möglich.

      Der Content-Type schließlich teilt dem Serverprozess mit, wie die Daten wiederherzustellen sind.

      Was jQuery(form).serialize() betrifft: Da gibt es mit native JS derzeit keine Alternative. Wer sich da selbst was zusammenbauen möchte, sollte zumindest wissen wie der Default Enctype aufgebaut ist und dass man diesen nicht nur an einen URL anhängen sondern auch als MessageBody senden kann.

      MfG

      Folgende Nachrichten verweisen auf diesen Beitrag:

      1. Tach!

        [irgendwas über Forms und Enctype]

        Das mag zwar alles sein, aber welche Relevanz hat das für das vorliegende Thema jQuery und im Konkreten mit jQuery.serialize() und verwandten Konstrukten? Das Formular soll doch nicht per Submit-Button nebst unabgefangenem submit-Event abgesendet werden.

        Was jQuery(form).serialize() betrifft: Da gibt es mit native JS derzeit keine Alternative. Wer sich da selbst was zusammenbauen möchte, sollte zumindest wissen wie der Default Enctype aufgebaut ist und dass man diesen nicht nur an einen URL anhängen sondern auch als MessageBody senden kann.

        Wozu muss man wissen, was der Default-Enctype von Formularen ist? Man muss nur wissen, was der richtige Type für die jeweilige Situation ist. Besonders wenn das Thema Javascript/jQuery ist, interessiert mich der Default-Enctype des Formulars nicht, wenn ich nur dessen Daten verwenden möchte. Das Senden findet schließlich abseits des Formulars statt (von .submit() ohne abgefangenes onsubmit abgesehen), beispielsweise mit der Fetch API oder XMLHttpRequest.

        Und dann ist es zwar nett, wenn man weiß, wie die Daten aufzubauen sind, aber - und dazu braucht man heutzutage keine externe Library mehr, denn - VanillaJS nimmt einem hier auch viel Arbeit nebst der Notwendigkeit des Grundlagenwissens ab.

        fetch(url, { method: 'POST', body: formdata }).then(...);

        Fertig. Content-Type-Setzen und Payload-Generierung macht der Browser.

        Oder wenn es unbedingt mit GET sein muss:

        const queryString = new URLSearchParams(formdata).toString(); fetch(`${url}?${queryString}`, { method: 'GET' }).then(...);

        dedlfix.

        1. Tach!

          [irgendwas über Forms und Enctype]

          Was Du als irgendwas bezeichnet ist Grundwissen!

          Gerade für diejnigen die auf jQuery(form).serialize() verzichten wollen. Denn es gibt keine Alternative, da bleibt nämlich nur der Eigenbau!

          Punkt.

          1. Tach!

            [irgendwas über Forms und Enctype]

            Was Du als irgendwas bezeichnet ist Grundwissen!

            Ja, Grundwissen, das man selbst bei VanillaJS nicht unbedingt braucht. Was ja auch einer der Kritikpunkte an Librarys war, dass diese (einiges an) Grundlagenwissen obsolet machen. Das schaffen auch die mittlerweile in VanillaJS eingezogenen Komfortfunktionen. Die Welt dreht sich weiter. Was wir heute als Grundlagenwissen bezeichnen, wird morgen durch Vanilla-Irgendwas überflüssig gemacht.

            Man kann auch Elektronik als die Basis der Rechentechnik als Grundlagenwissen bezeichnen. Braucht man aber auch nicht wirklich, um programmieren zu können. Genausowenig wie wie Physik, die die Grundlage für Elektronik ist. Das ist alles interessant zu wissen, aber eben nicht notwendig.

            dedlfix.

            1. Tach!

              [irgendwas über Forms und Enctype]

              Was Du als irgendwas bezeichnet ist Grundwissen!

              Ja, Grundwissen, das man selbst bei VanillaJS nicht unbedingt braucht. Was ja auch einer der Kritikpunkte an Librarys war, dass diese (einiges an) Grundlagenwissen obsolet machen.

              Grundwissen war noch nie obsolet! Gerade wenn es um einen jQuery(form).serialize() Ersatz geht, ist das von mir dargelegte (minimale) Grundwissen unerlässlich!

              Das schaffen auch die mittlerweile in VanillaJS eingezogenen Komfortfunktionen.

              Es gibt keine Solche die jQuery(form).serialize() einfach so ersetzt!

              MfG

              1. Tach!

                Das schaffen auch die mittlerweile in VanillaJS eingezogenen Komfortfunktionen.

                Es gibt keine Solche die jQuery(form).serialize() einfach so ersetzt!

                Diese Aussage wird auch durch mehrfache Wiederholung nicht besser. Es gibt eine einfache Kombination aus Vanilla-JS-Elementen, die die gewünschte Funktionalität bietet.

                dedlfix.

                1. Tach!

                  Das schaffen auch die mittlerweile in VanillaJS eingezogenen Komfortfunktionen.

                  Es gibt keine Solche die jQuery(form).serialize() einfach so ersetzt!

                  Diese Aussage wird auch durch mehrfache Wiederholung nicht besser. Es gibt eine einfache Kombination aus Vanilla-JS-Elementen, die die gewünschte Funktionalität bietet.

                  Dir ist der Unterschied zwischen den Enctypes nicht klar. Einen anderen Enctype zu erzeugen ist kein Ersatz! jQuery(form).serialize() erzeugt enctype="application/x-www-form-urlencoded" den kann man nicht so ohne Weiters durch multipart/form-data ersetzen.

                  Das kann man vielleicht für konkrete Anwendungsfälle aber nicht im Allgemeinen!

                  MfG

                  1. Tach!

                    Diese Aussage wird auch durch mehrfache Wiederholung nicht besser. Es gibt eine einfache Kombination aus Vanilla-JS-Elementen, die die gewünschte Funktionalität bietet.

                    Dir ist der Unterschied zwischen den Enctypes nicht klar. Einen anderen Enctype zu erzeugen ist kein Ersatz! jQuery(form).serialize() erzeugt enctype="application/x-www-form-urlencoded" den kann man nicht so ohne Weiters durch multipart/form-data ersetzen.

                    Bist du sicher, dass ich eine Ersatzlösung vorgeschlagen habe, die multipart/form-data statt application/x-www-form-urlencoded liefert?

                    Das kann man vielleicht für konkrete Anwendungsfälle aber nicht im Allgemeinen!

                    Jeder Content-Type ist nur für konkrete Anwendungsfälle nutzbar und nicht im Allgemeinen.

                    dedlfix.

                    1. hi,

                      Bist du sicher, dass ich eine Ersatzlösung vorgeschlagen habe, die multipart/form-data statt application/x-www-form-urlencoded liefert?

                      Deine Ersatzlösung liefert undefined=undefined&undefined=undefined&undefined=undefined dass sieht zwar aus wie application/x-www-form-urlencoded ist aber Müll.

                      MfG

                      Folgende Nachrichten verweisen auf diesen Beitrag:

                      1. Tach!

                        Bist du sicher, dass ich eine Ersatzlösung vorgeschlagen habe, die multipart/form-data statt application/x-www-form-urlencoded liefert?

                        Deine Ersatzlösung liefert undefined=undefined&undefined=undefined&undefined=undefined dass sieht zwar aus wie application/x-www-form-urlencoded ist aber Müll.

                        Dann machst du irgendwas falsch. Dein Beispiel mit meiner Korrektur liefert mir im FF: foo=fooval&bar=barval. Zudem sind in deiner Ausgabe drei Key-Value-Pärchen zu sehen und in allen hier gegebenen Beispielen waren es nur zwei. Da passt was nicht zusammen.

                        dedlfix.

                        1. Tach!

                          Bist du sicher, dass ich eine Ersatzlösung vorgeschlagen habe, die multipart/form-data statt application/x-www-form-urlencoded liefert?

                          Deine Ersatzlösung liefert undefined=undefined&undefined=undefined&undefined=undefined dass sieht zwar aus wie application/x-www-form-urlencoded ist aber Müll.

                          Dann machst du irgendwas falsch.

                          Meine Empfehlung: Wenn Du selbst da was bauen willst: Erzeuge als Zwischenschritt nicht gleich einen bestimmten Enctype sondern eine Datenstruktur -- aus welcher Du dann in einem weiteren Schritt beliebige Content-Types erzeugen kannst!

                          application/x-www-form-urlencoded ist ja schließlich nicht alles und wenn Dein Auftraggeber zum Beispiel einen Content-Type application/json oder xml verlangt, kannst Du einen Solchen aus einer vorliegenden Datenstruktur erzeugen, musst also nicht von ganz vorne beim Formular anfangen.

                          Überlege Dir also wie diesbezügliche Datenstrukturen aussehen könnten.

                          MfG

                          1. Hallo pl,

                            Meine Empfehlung: Wenn Du selbst da was bauen willst: Erzeuge als Zwischenschritt nicht gleich einen bestimmten Enctype sondern eine Datenstruktur -- aus welcher Du dann in einem weiteren Schritt beliebige Content-Types erzeugen kannst!

                            z.B. FormData?

                            Manchmal kann ich nur den Kopf schütteln. Lies doch mal die Dokumentation und denke ein wenig darüber nach.

                            LG,
                            CK

                            -- https://wwwtech.de/about
                          2. Tach!

                            Meine Empfehlung: Wenn Du selbst da was bauen willst: Erzeuge als Zwischenschritt nicht gleich einen bestimmten Enctype sondern eine Datenstruktur -- aus welcher Du dann in einem weiteren Schritt beliebige Content-Types erzeugen kannst!

                            Gut, dann in Einzelschritten. Gegeben sei dies wunderschöne Formular.

                            <form id="ff"> <input name="foo" value="fooval"> <input name="bar" value="barval"> </form>

                            Davon holen wir uns erstmal eine Referenz in modernem Javascript. Das heißt, dass diese in eine Konstante kommt und nicht nur ein schnödes var, denn am Inhalt der Variable wird sich nichts mehr ändern.

                            const ff = document.querySelector("#ff");

                            Als nächstes kommt die geforderte Datenstruktur, die von allen weiteren Verarbeitungswünschen unabhängig ist, ein FormData-Objekt.

                            const formData = new FormData(ff);

                            Und dann verzweigt es sich. Möchte ich einen POST-Request absetzen, bei dem der Payload in den Body kommt, als multipart/form-data, muss ich nichts weiter machen, als das FormData-Objekt dem fetch() oder XHR.send() zu übergeben. Nur wenn die Formulardaten in die URL sollen, braucht es einen Querystring in application/x-www-form-urlencoded.

                            const queryString = new URLSearchParams(formData).toString();

                            Der Rest ist die Verheiratung mit dem anderen Teil der URL, eine einfache String-Operation.

                            application/x-www-form-urlencoded ist ja schließlich nicht alles und wenn Dein Auftraggeber zum Beispiel einen Content-Type application/json oder xml verlangt,

                            Dazu muss er erstmal genau definieren, wie die Datenstruktur in JSON oder XML aussehen soll. Aber auch das ist mit Umwandlung aus FormData kein unlösbares Problem.

                            Überlege Dir also wie diesbezügliche Datenstrukturen aussehen könnten.

                            Es wäre sehr nett, wenn du nicht vom Thema ablenken würdest. Da steht immer noch deine für mich nicht nachvollziehbare Behauptung im Raum, meine Ersatzlösung würde Müll liefern.

                            dedlfix.

                            1. Hi,

                              Als nächstes kommt die geforderte Datenstruktur, die von allen weiteren Verarbeitungswünschen unabhängig ist, ein FormData-Objekt.

                              Oh das hatten wir doch geklärt, daß dieser Enctype eben nicht von allen weiteren Verarbeitungsünschen unabhängig ist. Datenstrukturen sind für den wahlfreien Zugriff, FormData hingegen für den Transport. Wie der String für den Enctype multipart/form-data aussieht kannst Du Dir hier anschauen.

                              Und dann verzweigt es sich. Möchte ich einen POST-Request absetzen, bei dem der Payload in den Body kommt, als multipart/form-data, muss ich nichts weiter machen, als das FormData-Objekt dem fetch() oder XHR.send() zu übergeben. Nur wenn die Formulardaten in die URL sollen, braucht es einen Querystring in application/x-www-form-urlencoded.

                              Das mag Deine ganz persönliche Logik sein geht aber am Thema völlig vorbei! Hier die Grundlagen.

                              Und Überhaupt: Was willst Du denn mit einem FormData-Objekt wenn die Daten per application/x-www-form-urlencoded im MessageBody gesendet werden sollen!?

                              Btw. XML, JSON sind auch keine Datenstrukturen sondern nur unterschiedliche Verpackungen für Datenstrukturen. Genauso wie der Enctype multipart/form-data auch nur ein Verpackung ist. Geläufig ist auch der Begriff der Serialisierung, Datenstrukturen wie JS-Arrays, JS-Objekte werden serialisiert und damit zu Strings gemacht.

                              Genau das tut jQuery(form).serialize() wobei diese Funktion genau wie new FormData(form) die Daten nicht aus einer Datenstruktur bezieht sondern direkt aus dem Formular.

                              Meine Serializer sind übrigens schon lange fertig, D.h., Deine Serializer-Lösung steht für mich gar nicht zur Debatte. Ich hatte hier lediglich dargestellt, daß es für jQuery(form).serialize() keinen Ersatz gibt (beachte den Enctype) und eben nur die Eigenlösung bleibt.

                              MfG

                              PS: Ich erachte es als nicht sinnvoll, daß Du immer wieder das Thema FormData hervorwürgst, also immer wieder damit von vorn anfängst!

                              1. Tach!

                                Als nächstes kommt die geforderte Datenstruktur, die von allen weiteren Verarbeitungswünschen unabhängig ist, ein FormData-Objekt.

                                Oh das hatten wir doch geklärt, daß dieser Enctype eben nicht von allen weiteren Verarbeitungsünschen unabhängig ist.

                                Wie bitte? Was konkret hat denn ein FormData mit irgendeinem Enctype zu tun? Und erzählt mir bitte nicht wieder ohne Beweis, dass FormData die Daten in irgendeiner Enctype-Form liefere.

                                Datenstrukturen sind für den wahlfreien Zugriff, FormData hingegen für den Transport.

                                Vielleicht sprichst du auch von einem ganz anderen FormData und nicht von FormData aus den Web APIs.

                                Wie der String für den Enctype multipart/form-data aussieht kannst Du Dir hier anschauen.

                                Gerade der interessiert mich überhaupt nicht (mehr). Das korrekte Umwandeln erledigt der Browser von selbst aus dem übergebenem FormData-Objekt.

                                Und dann verzweigt es sich. Möchte ich einen POST-Request absetzen, bei dem der Payload in den Body kommt, als multipart/form-data, muss ich nichts weiter machen, als das FormData-Objekt dem fetch() oder XHR.send() zu übergeben. Nur wenn die Formulardaten in die URL sollen, braucht es einen Querystring in application/x-www-form-urlencoded.

                                Das mag Deine ganz persönliche Logik sein geht aber am Thema völlig vorbei! Hier die Grundlagen.

                                Für mich ging eher jener Beitrag über die Grundlagen am Thema völlig vorbei. Nicht dass ich inhaltlich etwas dagegen zu sagen hätte, nur war das Thema Formular abschicken vorher kein Gegenstand der Diskussion und von meiner Seite ist es das immer noch nicht. Es ging darum, die Daten mit Javascript entgegenzunehmen und selbst einen Request auf die Reise zu senden, abseits eines Forms.

                                Und Überhaupt: Was willst Du denn mit einem FormData-Objekt wenn die Daten per application/x-www-form-urlencoded im MessageBody gesendet werden sollen!?

                                Sollen sie das? Falls ich das jemals wollen würde, dann gibts immer noch das bereits erwähnte URLSearchParams zum einfachen Umformen eines FormData-Objekts. Oder den Einzeiler, den ich zu Anfang ohne Kenntnis der Existenz von URLSearchParams vorgestellt hatte.

                                Meine Serializer sind übrigens schon lange fertig, D.h., Deine Serializer-Lösung steht für mich gar nicht zur Debatte. Ich hatte hier lediglich dargestellt, daß es für jQuery(form).serialize() keinen Ersatz gibt (beachte den Enctype) und eben nur die Eigenlösung bleibt.

                                Und wieder dieselbe Behauptung ohne Beweis, dass deren Widerlegung nicht richtig gewesen wäre.

                                Ich erachte es als nicht sinnvoll, daß Du immer wieder das Thema FormData hervorwürgst, also immer wieder damit von vorn anfängst!

                                Und warum nicht? FormData ist ein essentieller Bestandteil meiner Lösungsvorschläge und der Browser. Wenn du Gründe hast, die dagegensprechen, solltest du sie konkret nennen.

                                dedlfix.

                                1. hi,

                                  Und warum nicht? FormData ist ein essentieller Bestandteil meiner Lösungsvorschläge und der Browser. Wenn du Gründe hast, die dagegensprechen, solltest du sie konkret nennen.

                                  Der Grund ist ein anderer Content-Type der anders geparst werden muss. Von daher ist new FormData(form) kein Ersatz für jQuery(form).serialize();

                                  Als Ersatz funktioniert es nur dann wenn ein Parser die Daten aus einem nach multipart/form-data kodiertem String genauso wiederherstellt wie er das mit denselben Daten machen würde die mit dem Default Enctype serialisiert wurden.

                                  Eine solche Transparenz ist nicht allgemein gültig.

                                  MfG

                                  1. Tach!

                                    Und warum nicht? FormData ist ein essentieller Bestandteil meiner Lösungsvorschläge und der Browser. Wenn du Gründe hast, die dagegensprechen, solltest du sie konkret nennen.

                                    Der Grund ist ein anderer Content-Type der anders geparst werden muss. Von daher ist new FormData(form) kein Ersatz für jQuery(form).serialize();

                                    Nicht FormData allein, sondern in Kombination mit URLSearchParams (und document.querySelector(), um genau zu sein).

                                    Als Ersatz funktioniert es nur dann wenn ein Parser die Daten aus einem nach multipart/form-data kodiertem String genauso wiederherstellt wie er das mit denselben Daten machen würde die mit dem Default Enctype serialisiert wurden.

                                    Niemand hat die Absicht multipart/form-data zu verwenden, wenn application/x-www-form-urlencoded benötigt wird.

                                    dedlfix.

                                    1. Tach!

                                      Und warum nicht? FormData ist ein essentieller Bestandteil meiner Lösungsvorschläge und der Browser. Wenn du Gründe hast, die dagegensprechen, solltest du sie konkret nennen.

                                      Der Grund ist ein anderer Content-Type der anders geparst werden muss. Von daher ist new FormData(form) kein Ersatz für jQuery(form).serialize();

                                      Nicht FormData allein, sondern in Kombination mit URLSearchParams (und document.querySelector(), um genau zu sein).

                                      Du hast es immer noch nicht verstanden: HTTP spielt beim Parsen eines bestimmten Enctype gar keine Rolle!

                                      MfG

                                      1. Tach!

                                        Nicht FormData allein, sondern in Kombination mit URLSearchParams (und document.querySelector(), um genau zu sein).

                                        Du hast es immer noch nicht verstanden: HTTP spielt beim Parsen eines bestimmten Enctype gar keine Rolle!

                                        Inwiefern spielt denn HTTP überhaupt eine Rolle bei dem, was ich gesagt habe? Weder FormData noch URLSearchParams haben irgendetwas mit HTTP am Hut. Und um irgendein Parsen ging es auch zu keiner Zeit. Aufgabenstellung war lediglich Formulardaten zu serialisieren. Wenn ich was nicht versteht, dann warum du HTTP und Parsen ins Spiel bringst.

                                        dedlfix.

                                        1. Tach!

                                          Nicht FormData allein, sondern in Kombination mit URLSearchParams (und document.querySelector(), um genau zu sein).

                                          Du hast es immer noch nicht verstanden: HTTP spielt beim Parsen eines bestimmten Enctype gar keine Rolle!

                                          Inwiefern spielt denn HTTP überhaupt eine Rolle bei dem, was ich gesagt habe? Weder FormData noch URLSearchParams haben irgendetwas mit HTTP am Hut. Und um irgendein Parsen ging es auch zu keiner Zeit. Aufgabenstellung war lediglich Formulardaten zu serialisieren. Wenn ich was nicht versteht, dann warum du HTTP und Parsen ins Spiel bringst.

                                          Der Parser ist das Entscheidende! Denn wer Daten serialisiert will sie ja auch wiederherstellen. HTTP ist transparent. Wenn man den Parser auch noch transparent haben will, kommt der Enctype ins Spiel: Er muss bei der Übertragung mitgesendet werden heißt das konkret. Also zusätzlich und hier kommt wieder HTTP zum Tragen insofern als daß der Enctype zu einem Request-Header Content-Type gemacht wird. Diese Seite zeigt es anschaulich.

                                          Und noch etwas: Die FormData Instanz kennt eine Methode getAll(); damit ist es möglich. sämtliche Daten wiederherzustellen.

                                          URLSearchParams jedoch benötigt einen Query-String (enctype="application/x-www-form-urlencoded"), kann also mit einem FormData Objekt gar nichts anfangen. document.querySelector() kann einen Query-String auch nur dann finden wenn der im DOM abgelegt ist.

                                          MfG

                                          1. Moin,

                                            Der Parser ist das Entscheidende! Denn wer Daten serialisiert will sie ja auch wiederherstellen.

                                            Aber nicht in dieser Diskussion.

                                            Viele Grüße
                                            Robert

                                            1. Moin,

                                              Der Parser ist das Entscheidende! Denn wer Daten serialisiert will sie ja auch wiederherstellen.

                                              Aber nicht in dieser Diskussion.

                                              Doch ist er. Weil er unmittelbar mit dem Begriff Enctype verbunden ist. Und jQuery(form).serialize() liefert Formulardaten mit einen ganz bestimmten Enctype.

                                              MfG

                                              PS: Das ist hier ja auch gar keine Diskussion im Übrigen.

                                          2. Tach!

                                            Und noch etwas: Die FormData Instanz kennt eine Methode getAll(); damit ist es möglich. sämtliche Daten wiederherzustellen.

                                            Ja, ist aber nicht weiter relevant im vorliegenden Fall.

                                            URLSearchParams jedoch benötigt einen Query-String (enctype="application/x-www-form-urlencoded"), kann also mit einem FormData Objekt gar nichts anfangen. document.querySelector() kann einen Query-String auch nur dann finden wenn der im DOM abgelegt ist.

                                            Ach, das ist dein Verständnisproblem. Der Konstruktor von URLSearchParams() kann nicht nur einen Querystring entgegennehmen, sondern auch eine Sequenz entgegennehmen, deren Elemente jeweils eine Sequenz von zwei Strings ist, also ein "Array of Arrays of two Strings". In Code ausgedrückt beispielsweise:

                                            [['foo', 'bar'], ['qux', 'baz'], ...]

                                            Ein FormData-Objekt ist genau eine solche Sequenz. Das heißt, wenn man über ein FormData iteriert, bekommt man mit jedem Schritt eines der inneren Arrays.

                                            Und aus diesen auf diese Weise eingelesenen Daten erzeugt URLSearchParams() dann beim toString() einen Querystring. Womit man den Serialisierungsteil der Funktionalität von jQuery.serialize() hat.

                                            dedlfix.

                                            Folgende Nachrichten verweisen auf diesen Beitrag:

                                            1. Tach!

                                              Und noch etwas: Die FormData Instanz kennt eine Methode getAll(); damit ist es möglich. sämtliche Daten wiederherzustellen.

                                              Ja, ist aber nicht weiter relevant im vorliegenden Fall.

                                              URLSearchParams jedoch benötigt einen Query-String (enctype="application/x-www-form-urlencoded"), kann also mit einem FormData Objekt gar nichts anfangen. document.querySelector() kann einen Query-String auch nur dann finden wenn der im DOM abgelegt ist.

                                              Ach, das ist dein Verständnisproblem. Der Konstruktor von URLSearchParams() kann nicht nur einen Querystring entgegennehmen, sondern auch eine Sequenz entgegennehmen, deren Elemente jeweils eine Sequenz von zwei Strings ist, also ein "Array of Arrays of two Strings". In Code ausgedrückt beispielsweise:

                                              [['foo', 'bar'], ['qux', 'baz'], ...]

                                              Ein FormData-Objekt ist genau eine solche Sequenz. Das heißt, wenn man über ein FormData iteriert, bekommt man mit jedem Schritt eines der inneren Arrays.

                                              Und aus diesen auf diese Weise eingelesenen Daten erzeugt URLSearchParams() dann beim toString() einen Querystring. Womit man den Serialisierungsteil der Funktionalität von jQuery.serialize() hat.

                                              Natürlich kann man das so machen. Also über FromData die Daten aus dem Formular holen, wiederherstellen als temporäre Datenstruktur und dann mit URLSearchParams einen anderen Enctype erzeugen.

                                              Das kann man aber auch gleich mit den Daten machen die man aus dem Formular bekommt.

                                              Oder man hat eine Universalmethode die eine universelle Datenstruktur erzeugt (z.B. ein JSArray mit JSObjekten) aus der man beliebige Enctypes machen kann. Das war meine Empfehlung und genauso hab ich die auch selbst vor Jahren umgesetzt. Vor Allem in Hinblick auf mögliche Erweiterungen um weitere Enctypes von denen es unzählige gibt, heutige Browser jedoch nur ganze 2 davon kennen und implementiert haben.

                                              Transparenz kommt ja nicht von allein, man muss sich schon ein paar Gedanken machen. Mit meinen Libs kann ich z.B. $(form).serialize() komplett ersetzen und die Daten per application/json senden ohne den Umweg über einen anderen Enctype gehen zu müssen. Und dafür muss ich serverseitig nicht eine einzige Zeile Code ändern. Genausogut könnte ich die Daten über proprietäre Enctypes senden wobei auch hier der serverseitige Code unverändert bleibt, sofern mein Parser den Enctype kennt -- D.h., daß ich meinen Parser um beliebige Content-Types erweitern kann.

                                              Das ist eine Sache die ich nicht von heute auf morgen entwickelt habe sondern über mehrere Jahre. Das Einzige an dem ich dabei festgehalten habe ist der Default Enctype.

                                              Ansonsten zeigt sich auch hier daß Schichtenmodelle (Layer) durchaus einen Sinn haben der hauptsächlich darin besteht, ebendiese Schichten transparent zu machen so als gäbe es sie gar nicht.

                                              MfG

                                              1. Tach!

                                                Natürlich kann man das so machen. Also über FromData die Daten aus dem Formular holen, wiederherstellen als temporäre Datenstruktur und dann mit URLSearchParams einen anderen Enctype erzeugen.

                                                Da wird keine temporäre Datenstruktur erstellt. Man übergibt das FormData-Objekt an den Konstruktor von URLSearchParams. Das war's und alles andere findet browserintern statt.

                                                Das kann man aber auch gleich mit den Daten machen die man aus dem Formular bekommt.

                                                Aber warum? Es ist doch viel umständlicher, auf FormData zu verzichten und sich die Daten selbst zusammenzutragen.

                                                Oder man hat eine Universalmethode die eine universelle Datenstruktur erzeugt (z.B. ein JSArray mit JSObjekten) aus der man beliebige Enctypes machen kann.

                                                Ja, FormData. Ist universell genug, um damit alles machen zu können.

                                                Das war meine Empfehlung und genauso hab ich die auch selbst vor Jahren umgesetzt.

                                                Nun, dann kanst du ja deine Lösung etwas verschlanken, wenn du darin FormData als einen Teil verwendest. Für multipart/form-data brauchst du keinen Serialisierer, das machen XHR.send() und fetch() von selbst, wenn sie ein FormData-Objekt bekommen. Für application/www-x-form-urlencoded kannst du URLSearchParams nehmen, und für alles was du sonst noch so zu brauchen gedenkst, kann ebenfalls das iterierbare FormData wunderschön als Datenquelle dienen.

                                                Vor Allem in Hinblick auf mögliche Erweiterungen um weitere Enctypes von denen es unzählige gibt, heutige Browser jedoch nur ganze 2 davon kennen und implementiert haben.

                                                Über Erweiterungen mach ich mir keine großen Gedanken. Wenn die kommen, werden auch entsprechende Lösungen entwickelt werden.

                                                Mit meinen Libs kann ich z.B. $(form).serialize() komplett ersetzen und die Daten per application/json senden ohne den Umweg über einen anderen Enctype gehen zu müssen.

                                                Schön, aber diesen Umweg gibt es auch bei den vorgestellten Alternativen nicht.

                                                Das ist eine Sache die ich nicht von heute auf morgen entwickelt habe sondern über mehrere Jahre. Das Einzige an dem ich dabei festgehalten habe ist der Default Enctype.

                                                Nun, FormData und URLSearchParams kann man in deutlich kürzerer Zeit kennenlernen. Vielleicht bist du stolz darauf, damals alles von der Pike auf entwickelt zu haben. Ja klar, warum auch nicht? Aber wenn du dafür heute nur noch ein müdes Lächeln erntest, solltest du dich fragen, ob du dich nicht im Damals verfangen hast. Die aktuellen Möglichkeiten nicht zu verstehen, als Unsinn oder "gar nicht zur Debatte stehend" zu bezeichnen, macht die Sache jedenfalls nicht besser.

                                                Ansonsten zeigt sich auch hier daß Schichtenmodelle (Layer) durchaus einen Sinn haben der hauptsächlich darin besteht, ebendiese Schichten transparent zu machen so als gäbe es sie gar nicht.

                                                Das ist eine andere Baustelle. Es ging hier nicht um Anwendungsarchitektur, sondern nur um einen Ersatz für ein simples jQuery(form).serialize() zu finden. Wenn du nun mit Schichtenmodell um die Ecke kommst, dann kann ich dir erwidern, dass bei einer solchen Vorgehensweise - von einem String als Selector für das DOM direkt zu URL-Daten zu gehen - Schichten zusammengwürfelt werden, die man in aktuellen Anwendungen aus gutem Grund lieber trennt.

                                                dedlfix.

                                                1. Tach!

                                                  Natürlich kann man das so machen. Also über FromData die Daten aus dem Formular holen, wiederherstellen als temporäre Datenstruktur und dann mit URLSearchParams einen anderen Enctype erzeugen.

                                                  Da wird keine temporäre Datenstruktur erstellt. Man übergibt das FormData-Objekt an den Konstruktor von URLSearchParams. Das war's und alles andere findet browserintern statt.

                                                  Nein, so funktioniert das nicht. URLSearchParams ist ein URL Utility das kann mit einem FormData Objekt überhaupt gar nichts anfangen! Hab ich aber auch schon geschrieben hier.

                                                  Das kann man aber auch gleich mit den Daten machen die man aus dem Formular bekommt.

                                                  Aber warum? Es ist doch viel umständlicher, auf FormData zu verzichten und sich die Daten selbst zusammenzutragen.

                                                  Das mag auf den ersten Blick so aussehen. Betrachte jedoch das Schichtenmodell was ich beschrieben habe, das macht die Sache am Ende einfacher, transparent, wartungsfreundlich und skalierbar -- Das sind durchaus Punkte über die ein Programmierer nachdenken sollte.

                                                  Ja, FormData. Ist universell genug, um damit alles machen zu können.

                                                  Was soll denn an FormData universell sein!? Es hat in einem jeden Schichtenmodell einen festen Platz der mit dem Enctype multipart/form-data verbunden ist. Mitnichten ist eine solche Position universell sondern das Gegenteil.

                                                  MfG

                                                  1. Tach!

                                                    Da wird keine temporäre Datenstruktur erstellt. Man übergibt das FormData-Objekt an den Konstruktor von URLSearchParams. Das war's und alles andere findet browserintern statt.

                                                    Nein, so funktioniert das nicht. URLSearchParams ist ein URL Utility das kann mit einem FormData Objekt überhaupt gar nichts anfangen! Hab ich aber auch schon geschrieben hier.

                                                    Ich würde Dir nur zu gerne zustimmen, aber dann hätten wir beide Unrecht, denn das kann es ganz ausgezeichnet.

                                                    Ansonsten gehe ich auf den Rest nicht weiter ein. Auf konkret gestellte Fragen mit unkonkrete Antworten und mit Verweisen auf ein nicht öffentliches "mein Framework" bringen mich bei der Lösung aktueller Aufgabenstellungen nicht weiter.

                                                    dedlfix.

                                                    1. Hallo dedlfix,

                                                      na endlich. Mein Zettel ist fertig.

                                                      BULLSHIT!

                                                      Rolf

                                                      -- sumpsi - posui - clusi
                                                      1. Hallo Rolf B,

                                                        Hallo dedlfix,

                                                        na endlich. Mein Zettel ist fertig.

                                                        BULLSHIT!

                                                        Rolf

                                                        ??

                                                        Bis demnächst
                                                        Matthias

                                                        -- Rosen sind rot.
                                                        1. Hallo Matthias,

                                                          na endlich. Mein Zettel ist fertig.

                                                          BULLSHIT!

                                                          ??

                                                          Du kennst Bullshit Bingo nicht? 😉

                                                          LG,
                                                          CK

                                                          -- https://wwwtech.de/about
                                                          1. Hallo Christian Kruse,

                                                            Du kennst Bullshit Bingo nicht? 😉

                                                            Doch. Jetzt wieder. "mein Framework" hat also noch gefehlt.

                                                            Bis demnächst
                                                            Matthias

                                                            -- Rosen sind rot.
                                                      2. @Rolf B

                                                        den SELF WIKI Artikel Kontextwechsel bez. Overload überarbeiten ist eine sehr gute Idee!!

                                                        MfG

                                                        Folgende Nachrichten verweisen auf diesen Beitrag:

                                                        1. Tach!

                                                          den SELF WIKI Artikel Kontextwechsel bez. Overload überarbeiten ist eine sehr gute Idee!!

                                                          Finde ich nicht. Wie konkret bestimmte Datentypen in andere umgewandelt werden und welche Methoden dafür in konkreten Programmiersprachen aufzurufen sind, liegt nicht im Rahmen des Artikels. Um das Prinzip zu beschreiben, was beim Einfügen von Daten in andere Daten zu beachten ist, braucht man kein Overload oder bestimmte Programmierparadigmen.

                                                          dedlfix.

                                                          Folgende Nachrichten verweisen auf diesen Beitrag:

                                                    2. Tach!

                                                      Da wird keine temporäre Datenstruktur erstellt. Man übergibt das FormData-Objekt an den Konstruktor von URLSearchParams. Das war's und alles andere findet browserintern statt.

                                                      Nein, so funktioniert das nicht. URLSearchParams ist ein URL Utility das kann mit einem FormData Objekt überhaupt gar nichts anfangen! Hab ich aber auch schon geschrieben hier.

                                                      Ich würde Dir nur zu gerne zustimmen, aber dann hätten wir beide Unrecht, denn das kann es ganz ausgezeichnet.

                                                      Dann Zeige Du doch mal in Stück CODE der funktioniert! Dein URLSearchParams(formData).to String() liefert Müll! Alternativ kannst Du auch die Doku zeigen wo geschrieben steht daß man URLSearchParams ein FormData Objekt übergeben kann!

                                                      Hier steht jedenfalls nichts dergleichen.

                                                      Vielmehr steht da: Das URLSearchParams Interface definiert Hilfsmethoden um mit dem Query-String einer URL zu arbeiten.

                                                      Mitnichten also steht da was von FormData!

                                                      Ansonsten gehe ich auf den Rest nicht weiter ein. Auf konkret gestellte Fragen mit unkonkrete Antworten und mit Verweisen auf ein nicht öffentliches "mein Framework" bringen mich bei der Lösung aktueller Aufgabenstellungen nicht weiter.

                                                      Welches Framework denn!? Hier geht es um Ersatz für jQuery(form).serialize() -- also bitte beim Thema bleiben!

                                                      Hier geht es darum, wie man einen Query-String, also den Default Enctype erzeugt mit Daten die in einem Formular vorliegen! Warum fängst Du da immer wieder von meinem Framework an!?

                                                      MfG

                                                      Folgende Nachrichten verweisen auf diesen Beitrag:

                                                      1. Tach!

                                                        Dann Zeige Du doch mal in Stück CODE der funktioniert!

                                                        Habe ich, mehrfach.

                                                        Dein URLSearchParams(formData).to String() liefert Müll!

                                                        Das ist deine Behauptung, die du nicht mit entsprechendem Code unterlegt hast. Und deine Ausgabe hat auch nicht zu den bisherigen Code-Beispielen gepasst.

                                                        Alternativ kannst Du auch die Doku zeigen wo geschrieben steht daß man URLSearchParams ein FormData Objekt übergeben kann!

                                                        Das steht nicht explizit drin, aber das ergibt sich aus den zulässigen Parameteren für den Konstruktor von URLSearchParams und dem Verhalten von FormData. Hab ich aber auch schon dargelegt, warum das zusammenarbeitet.

                                                        In der MDN ist es leider ungenau beschrieben, da steht "a sequence of USVStrings". (USVString kann man gedanklich mit String übersetzen, der Unterschied ist hier nicht weiter relevant.) Aber im dritten Teil des Beispiels sieht man, dass es eigentlich "a sequence of a sequence of two USVStrings" ist. Wenn man dem Link zur Spezifikation folgt, der auf der Seite zum URLSearchParams-Objekt zu finden ist, sieht man ebenfalls, dass der Konstruktor ein <sequence<sequence<USVString>> akzeptiert. Im Fließtext ist dann auch noch spezifiziert, dass die Paare in den inneren Arrays genau zwei Items enthalten müssen, sonst wird eine Exception geworfen.

                                                        Seitens FormData sind die entscheidenden Teile zum einen der Satz: „An object implementing FormData can directly be used in a for...of structure, instead of entries()“. Iterieren über ein FormData-Objekt verhält sich also gleich wie das Ergebnis der Methode entries(). Bei entries() liest man dann gleich in der Einleitung: "The FormData.entries() method returns an iterator allowing to go through all key/value pairs contained in this object. The key of each pair is a USVString object; the value either a USVString, or a Blob." Abgesehen vom Blob, das man wohl kaum an eine URL hängen möchte, ist diese Iterator-Funktionalität also genau das, was <sequence<sequence<USVString>> entspricht. Damit akzeptiert URLSearchParams also auch etwas, das sich wie FormData verhält, mithin kann man also abgekürzt sagen, dass man URLSearchParams ein FormData übergeben kann. JavaScript funktioniert üblicherweise nach dem Duck-Typing-Prinzip, die Dinge müssen nicht exakt von einem bestimmten Typ sein, sondern sich lediglich nach einem bestimmten Muster verhalten. Und das ist in dem Fall gegeben.

                                                        dedlfix.

                                                        Folgende Nachrichten verweisen auf diesen Beitrag:

                                                        1. Ach übrigens:

                                                          Deine Worte -- Schlechter Stil.

                                                          Dieses Thema weiter zu verfolgen ist nicht sinnvoll!

                                                          Dein Ansatz mit Array.from.. hingegen ist da schon zielführender wenn es um einen Ersatz von jQuery(form).serialize() geht.

                                                          MfG

                                                  2. Hallo pl,

                                                    Nein, so funktioniert das nicht. URLSearchParams ist ein URL Utility das kann mit einem FormData Objekt überhaupt gar nichts anfangen! Hab ich aber auch schon geschrieben hier.

                                                    Durch rituelle Beschwörungen kann man vielleicht Götter oder Geister anlocken, aber in der Informatik verlassen wir uns eigentlich immer noch auf Fakten. 😝

                                                    LG,
                                                    CK

                                                    -- https://wwwtech.de/about
                                            2. Tach! @dedlfix

                                              Ach, das ist dein Verständnisproblem. Der Konstruktor von URLSearchParams() kann nicht nur einen Querystring entgegennehmen, sondern auch eine Sequenz entgegennehmen, deren Elemente jeweils eine Sequenz von zwei Strings ist, also ein "Array of Arrays of two Strings". In Code ausgedrückt beispielsweise:

                                              [['foo', 'bar'], ['qux', 'baz'], ...]

                                              Ich frage mich wer auf solche Datenstrukturen kommt, zumal es sich ja um assoziierte Daten handelt {Schlüssel: Wert}. Das führt doch fast zwangsläufig eher hierzu:

                                              [ { name: 'foo', value: 'bar' }, { name: 'foo', value: 'foo' }, { name: 'qux', value: 'baz' }, ]

                                              Wobei man hinsichtlich Default-Enctype die sich aus mehreren Werten ergebenden Arrays zusammenfassen kann:

                                              { foo: ['foo','bar'], qux: ['baz'] }

                                              So daß sich obenstehende schmale Datenstruktur ergibt ohne Redundanzen.

                                              Wie auch immer, URLSearchParams ist ja nicht das Problem und auch nicht die Lösung dafür, die Daten eines Formulars zu erfassen. Betrachtet man das <form>-Element selbst als Schnittstelle, so bietet das DOM schon eine Reihe an Möglichkeiten an die eingegebenen Daten zu kommen ohne daß man jedes Eingabefeld mit einer ID spicken muss.

                                              MfG

                                              1. Tach!

                                                [['foo', 'bar'], ['qux', 'baz'], ...]

                                                Ich frage mich wer auf solche Datenstrukturen kommt, zumal es sich ja um assoziierte Daten handelt {Schlüssel: Wert}. Das führt doch fast zwangsläufig eher hierzu:

                                                [ { name: 'foo', value: 'bar' }, { name: 'foo', value: 'foo' }, { name: 'qux', value: 'baz' }, ]

                                                Diese Struktur ist auch nicht viel besser. Ob man nun statt numerischen Schlüsseln benannte hat, macht das Kraut am Ende nicht fett. Wenn schon weniger komplex, dann eher so:

                                                { 'foo': 'bar', 'foo': 'foo', 'qux': 'baz' }

                                                Das Problem in diesem Fall ist aber Möglichkeit, dass Schlüsselwerte mehrfach auftreten können und sich damit überschreiben. Ein Record mit einfachen Schlüssel-Wert-Paaren kann also nicht alle Situationen abbilden. Das eben gezeigte Beispiel hat dieses Problem beim foo. Diese Struktur ist also auf diese Weise nicht zielführend.

                                                Tatsächlich kann man aber eine solche Struktur (dann aber ohne Dopplungen) ebenfalls dem URLSearchParams-Konstruktor übergeben. Die nützt uns aber in der bisherigen Diskussion nichts, weil sie auf diese Weise nicht von FormData kommt und zudem den genannten Nachteil hat. Werden die Daten aber auf anderem Wege als über FormData ermittelt/erzeugt, und es können im Anwendungsfall keine Dopplungen auftreten, dann ist das durchaus eine geeignetere Struktur.

                                                Wobei man hinsichtlich Default-Enctype die sich aus mehreren Werten ergebenden Arrays zusammenfassen kann:

                                                Der Enctype hat an dieser Stelle nichts in der Diskussion verloren, es geht erstmal nur um eine sinnvolle Datenstruktur. Ich wüsste auch nicht, wie genau der Enctype hier eine Hilfestellung sein soll, um dann zu dieser folgenden Struktur zu kommen, denn schließlich müssen die Werte auf dem Transportweg einzeln und mit jeweils eigenem Key aufgeführt werden und nicht pro Key zusammengefasst.

                                                { foo: ['foo','bar'], qux: ['baz'] }

                                                Eine solche Zusammenfassung kann auch problematisch sein, weil damit die bisherige Ordnung durcheinandergebracht wird, beispielsweise wenn das Element für das zweite foo im DOM nach dem qux steht. Das mag für einige Anwendungen kein Problem sein. Die HTML-Spec, so wie ich sie verstehe, definiert jedoch, dass Paare in tree order aufgeführt werden sollen. Constructing the form data set: „Let controls be a list of all the submittable elements whose form owner is form, in tree order.“ Eine Definition von tree order habe ich nicht gefunden, gehe aber davon aus, dass es das ist, was ich meine, also die Reihenfolge im Baum, wenn Kinder eines Zweiges in geordneter Reihenfolge vorliegen. Jedenfalls kann es dem Browser egal sein, ob irgendwelche Anwendungen die Daten in anderer Anordnung weiterverarbeiten. Eine Umsortierung wäre nämlich ebenfalls problematisch für einige Fälle.

                                                Der nächste Nachteil an dieser zusammenfassenden Struktur ist, dass sie nun nicht mehr einfach umgeformt werden kann. Man muss zusätzlich beachten, ob die Werte skalar sind oder eine Sequenz und dann jeweils unterschiedlichen Code ausführen.

                                                Allein diese beiden Punkte betrachtend, kann man zu dem Schluss kommen, dass die erste Struktur doch nicht ganz so dumm ist, wie sie auf den ersten Blick erscheinen mag. Sie hat keine Probleme mit doppelten Schlüsseln, behält die Reihenfolge bei und lässt sich einfach ohne Verzweigung durchlaufen und umformen.

                                                So daß sich obenstehende schmale Datenstruktur ergibt ohne Redundanzen.

                                                Ja, schlank ist sie, erkauft sich das aber über die genannten anderen Eigenschaften/Nachteile.

                                                Wie auch immer, URLSearchParams ist ja nicht das Problem und auch nicht die Lösung dafür, die Daten eines Formulars zu erfassen.

                                                Das stand sowieso nicht zur Debatte, dafür gibts ja FormData. Und dass URLSearchParams nicht nur die FormData-Struktur verarbeiten kann, geht aus der Dokumentation hervor.

                                                Betrachtet man das <form>-Element selbst als Schnittstelle, so bietet das DOM schon eine Reihe an Möglichkeiten an die eingegebenen Daten zu kommen ohne daß man jedes Eingabefeld mit einer ID spicken muss.

                                                Also dafür hätte ich eine ganz einfache Möglichkeit anzubieten: ein FormData-Objekt. Hab ich, glaube ich, auch schon ein oder zweimal erwähnt. 😉

                                                dedlfix.

                                                1. Tach!

                                                  [['foo', 'bar'], ['qux', 'baz'], ...]

                                                  Ich frage mich wer auf solche Datenstrukturen kommt, zumal es sich ja um assoziierte Daten handelt {Schlüssel: Wert}. Das führt doch fast zwangsläufig eher hierzu:

                                                  [ { name: 'foo', value: 'bar' }, { name: 'foo', value: 'foo' }, { name: 'qux', value: 'baz' }, ]

                                                  Diese Struktur ist auch nicht viel besser. Ob man nun statt numerischen Schlüsseln benannte hat, macht das Kraut am Ende nicht fett.

                                                  Doch. Das Entscheidende bezüglich abstrakter Datentype nämlich ist der wahlfreie Zugriff! Während ein Array stets komplett durchlaufen werden muss, hat man mit {key:value} den value sofort im Griff!

                                                  Das Problem in diesem Fall ist aber Möglichkeit, dass Schlüsselwerte mehrfach auftreten können und sich damit überschreiben.

                                                  Mit einer dem entsprechenden Datenstruktur ist das überhaupt kein Problem. Und wie eine solche Datenstruktur aussehen könnte hab ich doch beschrieben: {key:value} wobei value auch ein array referenziert sofern es zu einem key mehrere Werte gibt.

                                                  Ein Record mit einfachen Schlüssel-Wert-Paaren kann also nicht alle Situationen abbilden. Das eben gezeigte Beispiel hat dieses Problem beim foo. Diese Struktur ist also auf diese Weise nicht zielführend.

                                                  Doch ist sie: {key:[]} hat sich über Jahrzehnte bewährt!

                                                  Der Enctype hat an dieser Stelle nichts in der Diskussion verloren, es geht erstmal nur um eine sinnvolle Datenstruktur.

                                                  Genau. Nun, multipart/form-data könnte so aussehen;

                                                  [ { name:.., value: .., type: 'application/pdf', length: 12324, charset: 'utf-8' }, {},{},, ]

                                                  Das sind freilich ein paar Informationen mehr als im Default Enctype. Dem gerecht wird ja auch der Parser in PHP indem er sämtliche Daten in $_POST und $_FILES also in 2 verschiedenen Arrays vorhält. Beim Default Enctype hingegen gibt es in $_FILES bekanntlich keine Daten.

                                                  MfG

                                                  1. Tach!

                                                    Diese Struktur ist auch nicht viel besser. Ob man nun statt numerischen Schlüsseln benannte hat, macht das Kraut am Ende nicht fett.

                                                    Doch. Das Entscheidende bezüglich abstrakter Datentype nämlich ist der wahlfreie Zugriff! Während ein Array stets komplett durchlaufen werden muss, hat man mit {key:value} den value sofort im Griff!

                                                    Das sehe ich in dem Fall nicht als das entscheidende Kriterium an. Der Kontext ist immer noch FormData und URLSearchParams. Beide haben entsprechende Methoden, um über den Namen auf die Werte zugreifen zu können. Man muss sich also nicht die anderen Nachteile einhandeln, nur um die angebliche einfache Zugreifbarkeit zu gewährleisten, wenn diese auf anderem Wege mit vergleichbarem Komfort verfügbar ist.

                                                    Das Problem in diesem Fall ist aber Möglichkeit, dass Schlüsselwerte mehrfach auftreten können und sich damit überschreiben.

                                                    Mit einer dem entsprechenden Datenstruktur ist das überhaupt kein Problem.

                                                    Natürlich ist das kein generelles Problem. Es geht hier aber nicht darum eine angeblich universelle Datenstruktur zu erstellen, sondern eine für einen bestimmten Einsatzzweck. Und da sollte man die Eigenschaften diesbezüglich betrachten, anstatt eine universelle Struktur schaffen zu wollen, die sich anderweitig als nachteilig erweisen kann.

                                                    Deine Vorschläge lösen alle nicht die Vorgabe, die ursprüngliche Reihenfolge beizubehalten. Wenn du die in deinem Fall nicht brauchst, gibt es immer noch die Methoden get und getAll, um über den Key zuzugreifen.

                                                    Der Enctype hat an dieser Stelle nichts in der Diskussion verloren, es geht erstmal nur um eine sinnvolle Datenstruktur.

                                                    Nun, multipart/form-data könnte so aussehen;

                                                    Ach, ich dachte, du wolltest eine universelle und keine für einen konkreten Einsatzzweck? Jetzt kommst du mit einer noch spezifischeren Struktur um die Ecke.

                                                    dedlfix.

                                                    1. Tach!

                                                      Diese Struktur ist auch nicht viel besser. Ob man nun statt numerischen Schlüsseln benannte hat, macht das Kraut am Ende nicht fett.

                                                      Doch. Das Entscheidende bezüglich abstrakter Datentype nämlich ist der wahlfreie Zugriff! Während ein Array stets komplett durchlaufen werden muss, hat man mit {key:value} den value sofort im Griff!

                                                      Das sehe ich in dem Fall nicht als das entscheidende Kriterium an.

                                                      Ist es aber. Weil: Übertragen wird ja nicht der Index eines Array sonder übertragen wird der Schlüssel und zwar namentlich! Selbst URLSearchParams Methoden werden dieser Tatsache gerecht!

                                                      Natürlich ist das kein generelles Problem. Es geht hier aber nicht darum eine angeblich universelle Datenstruktur zu erstellen, sondern eine für einen bestimmten Einsatzzweck.

                                                      Es geht um einen Ersatz von jQuery.serialize. Und da ist FormData völlig fehl am Platze weil es weder

                                                      1. eine Datenstruktur für den Default Enctype lliefert 2. noch den Enctype selbst serialisiert

                                                      ..anstatt eine universelle Struktur schaffen zu wollen, die sich anderweitig als nachteilig erweisen kann.

                                                      In Hinblick möglicher Erweiterungen auf Enctypes wie application/json oder application/xml ist ein Zwischenschritt über eine universelle Datenstruktur auf jeden Fall sinnvoll.

                                                      Deine Vorschläge lösen alle nicht die Vorgabe, die ursprüngliche Reihenfolge beizubehalten. Wenn du die in deinem Fall nicht brauchst, gibt es immer noch die Methoden get und getAll, um über den Key zuzugreifen.

                                                      Das kann man auch mit Methoden die das DOM bietet.

                                                      Nun, multipart/form-data könnte so aussehen;

                                                      Ach, ich dachte, du wolltest eine universelle und keine für einen konkreten Einsatzzweck? Jetzt kommst du mit einer noch spezifischeren Struktur um die Ecke.

                                                      Die von mir gezeigte Datenstruktur passt ebenso auch auf den Enctype application/x-www-form-urlencoded !

                                                      also dieda:

                                                      [ { name:.., value: .., }, {},{},, ]

                                                      MfG

                                                      1. Tach!

                                                        Diese Struktur ist auch nicht viel besser. Ob man nun statt numerischen Schlüsseln benannte hat, macht das Kraut am Ende nicht fett.

                                                        Doch. Das Entscheidende bezüglich abstrakter Datentype nämlich ist der wahlfreie Zugriff! Während ein Array stets komplett durchlaufen werden muss, hat man mit {key:value} den value sofort im Griff!

                                                        Das sehe ich in dem Fall nicht als das entscheidende Kriterium an.

                                                        Ist es aber. Weil: Übertragen wird ja nicht der Index eines Array sonder übertragen wird der Schlüssel und zwar namentlich!

                                                        Es ging nicht darum, dass der Schlüssel weg wäre, was er in der ursprünglichen Struktur ja nicht ist, sondern um einen von dir geforderten wahlfreien Zugriff. Für diesen wahlfreien Zugriff ist es nicht erforderlich, dass die Struktur ihn selbst begünstigt. Über Methoden zugreifen, reicht auch.

                                                        Natürlich ist das kein generelles Problem. Es geht hier aber nicht darum eine angeblich universelle Datenstruktur zu erstellen, sondern eine für einen bestimmten Einsatzzweck.

                                                        Es geht um einen Ersatz von jQuery.serialize. Und da ist FormData völlig fehl am Platze weil es weder

                                                        1. eine Datenstruktur für den Default Enctype lliefert 2. noch den Enctype selbst serialisiert

                                                        Du springst im Thema beliebig hin und her. Erst gefällt dir die Struktur nicht, nun springst du wieder zurück zum Anfang, und bringst Argumente, die schon längst geklärt sind.

                                                        ..anstatt eine universelle Struktur schaffen zu wollen, die sich anderweitig als nachteilig erweisen kann.

                                                        In Hinblick möglicher Erweiterungen auf Enctypes wie application/json oder application/xml ist ein Zwischenschritt über eine universelle Datenstruktur auf jeden Fall sinnvoll.

                                                        Bei einer Struktur, die die Aufgabenstellung nicht erfüllt (Reihenfolge beibehalten), braucht man nicht weiter über den Sinn nachzudenken. (Es sei denn, sie kann andere Aufgabenstellungen untserstützen, nur nützt das ja nichts für die vorliegende.)

                                                        Deine Vorschläge lösen alle nicht die Vorgabe, die ursprüngliche Reihenfolge beizubehalten. Wenn du die in deinem Fall nicht brauchst, gibt es immer noch die Methoden get und getAll, um über den Key zuzugreifen.

                                                        Das kann man auch mit Methoden die das DOM bietet.

                                                        Dann brauchst du gleich gar keine Datenstruktur, wenn alles übers DOM geht.

                                                        dedlfix.

                                                        1. hi @dedlfix

                                                          Das kann man auch mit Methoden die das DOM bietet.

                                                          Dann brauchst du gleich gar keine Datenstruktur, wenn alles übers DOM geht.

                                                          Eine Datenstruktur wird immer gebraucht! Denn es ist ein schlechter Stil, aus den Daten direkt den String zu erzeugen. Nicht umsonst gibt es ja diese wunderschönen Schichtenmodelle die man eben nicht nur als Gemälde an der Wand bestaunt sondern praktisch anwendet!

                                                          Dein Ansatz mit Array.from(form) liefert ein Array. Deswegen finde ich diesen Ansatz genau richtig. Und darauf bauend kann man recht einfach eine Struktur wie [{},{},{},,,] erzeugen indem man über die Formularelemente iteriert und so die Daten wie {name:..,value:..} und im Falle type=file weitere Informationen bekommt.

                                                          Und wenn nicht gerade ein type=file im Spiel ist, kann man genau diese Datenstruktur ohne Umschweife als JSON auf die Reise schicken. Oder als Query_String, oder XML draus machen. Oder einen proprietären Enctype der auch die Dateien rüberbringt.

                                                          Du ich will Dir nicht zu nahe treten, aber über diesen Thread hier solltest Du mal ernsthaft nachdenken. So wie es aussieht fehlen Dir eine gehörige Portion Grundwissen und vor Allem Erfahrungen.

                                                          MfG

                                                          Folgende Nachrichten verweisen auf diesen Beitrag:

                                                          1. hallo

                                                            Dein Ansatz mit Array.from(form) liefert ein Array. Deswegen finde ich diesen Ansatz genau richtig. Und darauf bauend kann man recht einfach eine Struktur wie [{},{},{},,,] erzeugen indem man über die Formularelemente iteriert und so die Daten wie {name:..,value:..} und im Falle type=file weitere Informationen bekommt.

                                                            Nur mal so, wenn du denkst, eine JSON-ähnliche Struktur zu erzeugen, dann mündet das in Datenverlust, denn generell gehen alle JSON-Konvertierer davon aus, dass object-keys unique sind.

                                                            sowohl multipart/formdata wie www-urlencoded sind aber weder Arrays noch Hashes noch JSON data, sondern einfach flache Listen mit Label und assoziiertem Inhalt.

                                                            -- Neu im Forum! Signaturen kann man ausblenden!
                                                            1. hallo

                                                              Dein Ansatz mit Array.from(form) liefert ein Array. Deswegen finde ich diesen Ansatz genau richtig. Und darauf bauend kann man recht einfach eine Struktur wie [{},{},{},,,] erzeugen indem man über die Formularelemente iteriert und so die Daten wie {name:..,value:..} und im Falle type=file weitere Informationen bekommt.

                                                              Nur mal so, wenn du denkst, eine JSON-ähnliche Struktur zu erzeugen, dann mündet das in Datenverlust, denn generell gehen alle JSON-Konvertierer davon aus, dass object-keys unique sind.

                                                              Unsinn. Der Weg über das Array funktioniert ausgezeichnet, da gibt es überhaupt keinen Datenverlust!

                                                              sowohl multipart/formdata wie www-urlencoded sind aber weder Arrays noch Hashes noch JSON data, sondern einfach flache Listen mit Label und assoziiertem Inhalt.

                                                              Was Du nicht sagst, Guten Morgen! Darüber reden wir doch die ganze Zeit, meine Güte 😉

                                                              Meine Datenstruktur sieht bspw. so aus:

                                                              $VAR1 = [ '0' => { 'name' => 'foo', 'value' => 'bar' }, '1' => { 'name' => 'foo', 'value' => 'boo' }, '2' => { 'name' => 'red.gif', 'size' => '522', 'type' => 'image/gif', 'value' => 'GIF89a } ]

                                                              Wie die serialisiert wird (was den Enctype betrifft) ist völlig egal! Stichwort Transparenz: JS-Array rein, Perl-Array raus.

                                                              Daß JSON oder XML nicht binary safe sind müssen wir hier nicht diskutieren oder?

                                                              MfG

                                                          2. Du ich will Dir nicht zu nahe treten, aber über diesen Thread hier solltest Du mal ernsthaft nachdenken. So wie es aussieht fehlen Dir eine gehörige Portion Grundwissen und vor Allem Erfahrungen.

                                                            Der einzige Grund, warum ich mir um dedlfix Gedanken mache, ist, warum er sich mit Deinem wirren Müll überhaupt so beharrlich und besonnen beschäftigt. Masochismus wäre eine Erklärung.

                                                            Folgende Nachrichten verweisen auf diesen Beitrag:

                                                            1. Hallo,

                                                              Der einzige Grund, warum ich mir um dedlfix Gedanken mache, ist, warum er sich mit Deinem wirren Müll überhaupt so beharrlich und besonnen beschäftigt. Masochismus wäre eine Erklärung.

                                                              ich kann dedlfix's Geduld auch nur noch bewundern.

                                                              Gruß
                                                              Jürgen

                                                              1. Hallo,

                                                                Der einzige Grund, warum ich mir um dedlfix Gedanken mache, ist, warum er sich mit Deinem wirren Müll überhaupt so beharrlich und besonnen beschäftigt. Masochismus wäre eine Erklärung.

                                                                ich kann dedlfix's Geduld auch nur noch bewundern.

                                                                Vor Allem die Resistenz gegenüber Begriffen wie Serializer, Schichtenmodell (Layer) und Transparenz.

                                                                Wenigstens hat er ja toString() verstanden insofern als daß da OOP/Overload dahintersteckt.

                                                                MfG

                                                            2. Du ich will Dir nicht zu nahe treten, aber über diesen Thread hier solltest Du mal ernsthaft nachdenken. So wie es aussieht fehlen Dir eine gehörige Portion Grundwissen und vor Allem Erfahrungen.

                                                              Der einzige Grund, warum ich mir um dedlfix Gedanken mache, ist, warum er sich mit Deinem wirren Müll überhaupt so beharrlich und besonnen beschäftigt.

                                                              Den seine Beitrage haben wenigstens noch einen Bezug zum Fachthema. Im Gegensatz zu dem was da Andere so von sich geben da ist der Begriff Unsachlichkeit schon Schmeichlei. Arroganz ist der richtige Begriff!

                                                              Masochismus wäre eine Erklärung.

                                                              Genau das meine ich mit Unsachlichkeit!

                                                              MfG

                                                              1. Hallo pl,

                                                                Den seine Beitrage haben wenigstens noch einen Bezug zum Fachthema. Im Gegensatz zu dem was da Andere so von sich geben da ist der Begriff Unsachlichkeit schon Schmeichlei. Arroganz ist der richtige Begriff!

                                                                Deine ersten beiden Sätze sind arrogant. Eine Person ist arrogant, wenn sie ihre Fähigkeiten oder Kenntnisse (berechtigt oder unberechtigt) hoch einschätzt und das abwertend anderen gegenüber zum Ausdruck bringt. Das eigentlich Peinliche ist aber, dass du offenbar wirklich keine Ahnung zu haben scheinst und auch nicht den Arsch in der Hose, das zuzugeben. Möglicherweise warst du wirklich mal ein guter Programmierer, anhand deiner Beiträge hier spreche ich dir jedoch jegliche Teamfähigkeit ab. Du erinnerst mich an Maradonna; einstmals ein Großer, ist sein öffentliches Auftreten heute nur noch daneben.

                                                                Bis demnächst
                                                                Matthias

                                                                -- Rosen sind rot.

                                                                Folgende Nachrichten verweisen auf diesen Beitrag:

                                                                1. Hi,

                                                                  Den seine Beitrage haben wenigstens noch einen Bezug zum Fachthema. Im Gegensatz zu dem was da Andere so von sich geben da ist der Begriff Unsachlichkeit schon Schmeichlei. Arroganz ist der richtige Begriff!

                                                                  Deine ersten beiden Sätze sind arrogant.

                                                                  Nein. Schau mal: Schichtenmodelle als Müll zu bezeichnen kann man noch akzepieren. Aber sauber verlinkte Anwendungen welche die Fakten anschaulich machen, vehement zu ignorieren und Fakten zu verleugnen daß ist schon Arroganz!

                                                                  MfG

                                                                  1. Hallo pl,

                                                                    Den seine Beitrage haben wenigstens noch einen Bezug zum Fachthema. Im Gegensatz zu dem was da Andere so von sich geben da ist der Begriff Unsachlichkeit schon Schmeichlei. Arroganz ist der richtige Begriff!

                                                                    Deine ersten beiden Sätze sind arrogant.

                                                                    Nein.

                                                                    Doch. "Den seine" ist abwertend, weil du weißt, über wen du redest. "wenigstens noch einen Bezug zum Fachthema" ist ebenfalls abwertend, denn du unterstellst dedlfix und allen anderen, fachlich völlig falsch zu liegen.

                                                                    Schau mal: Schichtenmodelle als Müll zu bezeichnen kann man noch akzepieren.

                                                                    Hab ich nicht gelesen. In diesem Thread kommt außerhalb von Zitaten das Wort Müll viermal vor, dreimal verwendest du es:

                                                                    • "Deine Ersatzlösung liefert undefined=undefined&undefined=undefined&undefined=undefined dass sieht zwar aus wie application/x-www-form-urlencoded ist aber Müll." (https://forum.selfhtml.org/m1727319) Bedeutet im Sachzusammenhang "Dedlfix' Ersatzlösung ist Müll."
                                                                    • "Dein URLSearchParams(formData).to String() liefert Müll!" (https://forum.selfhtml.org/m1727375) ist zwar schon etwas netter, aber immer noch abwertend.

                                                                    Was du anderen unterstellst, tust du selbst.

                                                                    Aber sauber verlinkte Anwendungen welche die Fakten anschaulich machen, vehement zu ignorieren und Fakten zu verleugnen daß ist schon Arroganz!

                                                                    Deine Anwendung macht nichts anschaulich. Sie ist eine Blackbox, das das gewünschte Ergebnis liefert. Was wirklich passiert, weißt nur du.

                                                                    Bis demnächst
                                                                    Matthias

                                                                    -- Rosen sind rot.
                                                                    1. hi,

                                                                      Was du anderen unterstellst, tust du selbst.

                                                                      Ja. Der Unterschied ist der, daß ich auch begründen kann wenn ich was als Müll bezeichne!

                                                                      Aber sauber verlinkte Anwendungen welche die Fakten anschaulich machen, vehement zu ignorieren und Fakten zu verleugnen daß ist schon Arroganz!

                                                                      Deine Anwendung macht nichts anschaulich. Sie ist eine Blackbox, das das gewünschte Ergebnis liefert. Was wirklich passiert, weißt nur du.

                                                                      Welch arrogante Ignoranz!

                                                                      Was da wirklich passiert ist ausführlich beschrieben, darüber hinaus kann jeder in den Quelltext schauen und in die Entwicklerkonsole!

                                                                      Jeder normale Mensch stellt Fragen wenn er was nicht verstanden hat! Da bin ich der Letzte der da Antworten verweigern würde!

                                                                      Ich biete Dir sogar an, den mailto zu verwenden, auf jeder Seite ist der Link dazu!

                                                                      MfG

                                                                    2. hi

                                                                      Deine Anwendung macht nichts anschaulich. Sie ist eine Blackbox, das das gewünschte Ergebnis liefert. Was wirklich passiert, weißt nur du.

                                                                      Meine Demo~Anwendung als Blackbox zu bezeichnen ist schon ziemlich dreist, findest Du nicht auch!?

                                                                      MfG

                                                                      1. Hallo pl,

                                                                        Meine Demo~Anwendung als Blackbox zu bezeichnen ist schon ziemlich dreist, findest Du nicht auch!?

                                                                        Nein, das finde ich nicht.

                                                                        Bis demnächst
                                                                        Matthias

                                                                        -- Rosen sind rot.
                                                                        1. @Matthias Apsel

                                                                          Meine Demo~Anwendung als Blackbox zu bezeichnen ist schon ziemlich dreist, findest Du nicht auch!?

                                                                          Nein, das finde ich nicht.

                                                                          Also doch arrogant. Da lag ich schon richtig.

                                                                          Punkt.

                                                                          1. Hallo pl,

                                                                            Meine Demo~Anwendung als Blackbox zu bezeichnen ist schon ziemlich dreist, findest Du nicht auch!?

                                                                            Nein, das finde ich nicht.

                                                                            Also doch arrogant. Da lag ich schon richtig.

                                                                            Wenn du meintest, dass du dich arrogant verhältst, dann lagst du richtig, ja.

                                                                            LG,
                                                                            CK

                                                                            -- https://wwwtech.de/about
                                                          3. Tach!

                                                            Das kann man auch mit Methoden die das DOM bietet.

                                                            Dann brauchst du gleich gar keine Datenstruktur, wenn alles übers DOM geht.

                                                            Eine Datenstruktur wird immer gebraucht! Denn es ist ein schlechter Stil, aus den Daten direkt den String zu erzeugen. Nicht umsonst gibt es ja diese wunderschönen Schichtenmodelle die man eben nicht nur als Gemälde an der Wand bestaunt sondern praktisch anwendet!

                                                            Was willst du überhaupt? Erst hast du einen Ersatz für jQuery.serialize() gesucht. Ein Einzeiler, der genau das macht, was du nun anprangerst: "schlechter Stil, aus den Daten direkt den String zu erzeugen". Ich schlage zwei Ersatzlösungen vor, die genau das eingangs Gewünschte realisieren. Die eine geht die Hälfte zu Fuß, die andere nutzt ein weiteres Element aus VanillaJS stattdessen. Dazu benötigt sie Zwischenschritte mit temporären Daten, mit denen du aber ebensowenig wie mit den internen Zwischenschritten von jQuery.serialize() in Berührung kommst. Du suchst daraufhin jede Menge Argumente bis hin zu unbelegten Vorwürfen, dass die Lösung nicht funktioniere. So gut wie nichts passt dir an ihr. Was also willst du überhaupt?

                                                            Dein Ansatz mit Array.from(form) liefert ein Array. Deswegen finde ich diesen Ansatz genau richtig. Und darauf bauend kann man recht einfach eine Struktur wie [{},{},{},,,] erzeugen indem man über die Formularelemente iteriert und so die Daten wie {name:..,value:..} und im Falle type=file weitere Informationen bekommt.

                                                            Das war nicht die Aufgabenstellung. Zudem ist diese Zwischenstruktur bereits vorhanden. FormData existiert. Und sehr einfach anwendbare Vorgehensweisen, diese Daten über URL oder Body zu versenden. Ich sehe keine Notwendigkeit, eine weitere Struktur entwickeln zu müssen. FormData mit seinen Methoden ist soweit universell, dass daraus auch eine Menge andere Strukturen recht einfach erstellt werden können - falls dazu überhaupt Bedarf abseits der bereits in VanillaJS eingebauten Funktionalität besteht.

                                                            Du ich will Dir nicht zu nahe treten, aber über diesen Thread hier solltest Du mal ernsthaft nachdenken. So wie es aussieht fehlen Dir eine gehörige Portion Grundwissen und vor Allem Erfahrungen.

                                                            Ich bedanke mich recht herzlich für diese Einschätzung. Aber ich denke, damit liegst du genauso daneben, wie mit einigen anderen Punkten, die du im Verlaufe des Threads beigetragen hast. Ansonsten bringt mich eine solche Einschätzung nicht weiter. Ich fände es sinnvoller konkrete Rückfragen zu beantwortet zu bekommen, am besten in nachvollziehbarer Weise.

                                                            dedlfix.

                                                            1. @dedlfix

                                                              Hast Du überhaupt mitbekommen daß ich Deinen Ansatz Array.from(form) gelobt habe!?

                                                              Wobei ich perönlich ein

                                                              for( var i = 0; i < document.forms[fi].elements.length; i++ ){}

                                                              bevorzuge. Das kann man beliebig erweitern:

                                                              var params = []; for( var i = 0; i < document.forms[fi].elements.length; i++ ){ var formel = document.forms[fi].elements[i] ; if( ! formel.name ) continue; if(formel.type == 'text'){ params.push({name: formel.name, value: formel.value}); } else if(formel.type == 'file'){ for(var ii = 0; ii < formel.files.length; ii++){ var file = formel.files[ii]; params.push({ value: file, name: file.name, type: file.type, size: file.size }); } } }

                                                              Also um weitere type=checkbox, radio <select> und <textrea>. Das liefert eine Datenstruktur die

                                                              1. Universell ist 2. in beliebige Content-Types serialisiert werden kann.

                                                              Und im Übrigen FormData überflüssig macht.

                                                              MfG

                                                              1. Tach!

                                                                Das liefert eine Datenstruktur die

                                                                ... fehlerhaft ist. Es gibt Ausnahmen, die beim Zusammenstellen der Formulardaten zu berücksichtigen sind.

                                                                1. Universell ist 2. in beliebige Content-Types serialisiert werden kann.

                                                                Und im Übrigen FormData überflüssig macht.

                                                                Aus welchem Grunde sollte man das wollen? Und wo ist da jetzt der gravierende Unterschied zu FormData? Was macht die Eigenlösung besser, was man mit FormData nicht hinbekomt?

                                                                dedlfix.

                                                                1. Tach!

                                                                  Das liefert eine Datenstruktur die

                                                                  ... fehlerhaft ist. Es gibt Ausnahmen, die beim Zusammenstellen der Formulardaten zu berücksichtigen sind.

                                                                  Du der Code ist ja nicht komplett, er zeigt nur meine Vorgehensweise.

                                                                  1. Universell ist 2. in beliebige Content-Types serialisiert werden kann.

                                                                  Und im Übrigen FormData überflüssig macht.

                                                                  Aus welchem Grunde sollte man das wollen? Und wo ist da jetzt der gravierende Unterschied zu FormData? Was macht die Eigenlösung besser, was man mit FormData nicht hinbekomt?

                                                                  Meine Methode liefert eine universelle und komplette Datenstruktur, FormData hat keine solche Methode. Aus meiner Datenstruktur kann ich beliebige Enctypes erzeugen, z.B. application/json oder application/x-www-form-urlencoded oder custom.

                                                                  Vielleicht möchten wir ja nocheinmal über den Sinn von Schichtenmodellen reden!?

                                                                  MfG

                                                                  1. Tach!

                                                                    Meine Methode liefert eine universelle und komplette Datenstruktur, FormData hat keine solche Methode.

                                                                    for (let pair of formData) { console.log(pair[0], pair[1]); }

                                                                    Liefert die Daten vollständig und komplett. Du kannst auch den Iterator nehmen, der von entries() geliefert wird, ist derselbe.

                                                                    Es muss kein Array sein, ein Iterator reicht völlig. Über das Array würdest du auch nur iterieren, um es weiterzuverarbeiten. Also ist der Iterator ausreichend, den FormData bietet.

                                                                    Aus meiner Datenstruktur kann ich beliebige Enctypes erzeugen, z.B. application/json oder application/x-www-form-urlencoded oder custom.

                                                                    Ist das eine Besonderheit, die mit anderen Datenstrukturen nicht zu erreichen ist?

                                                                    Vielleicht möchten wir ja nocheinmal über den Sinn von Schichtenmodellen reden!?

                                                                    Wozu? Hat mit dem Thema nichts zu tun, wir verbleiben doch die ganze Zeit in derselben Schicht, wenn du nicht grad wieder unnötige Abschweifungen hinlegst.

                                                                    dedlfix.

                                                                    1. Tach!

                                                                      Meine Methode liefert eine universelle und komplette Datenstruktur, FormData hat keine solche Methode.

                                                                      for (let pair of formData) { console.log(pair[0], pair[1]); }

                                                                      Liefert die Daten vollständig und komplett.

                                                                      Das mag sein, aber das ist ja noch keine Datenstruktur! Und auf die Daten zugreifen geht, wie mein CODE zeigt, auch mit Methoden des DOM, das braucht FormData nicht.

                                                                      Aus meiner Datenstruktur kann ich beliebige Enctypes erzeugen, z.B. application/json oder application/x-www-form-urlencoded oder custom.

                                                                      Ist das eine Besonderheit, die mit anderen Datenstrukturen nicht zu erreichen ist?

                                                                      Keine Besonderheit. Es ist eine Frage der Zweckmäßigkeit, welche Struktur man aufsetzt. Also auch, wie man eine bestimmte Datensruktur möglichst zweckmäßig serialisiert für den Transport oder die Speicherung.

                                                                      Vielleicht möchten wir ja nocheinmal über den Sinn von Schichtenmodellen reden!?

                                                                      Wozu? Hat mit dem Thema nichts zu tun, wir verbleiben doch die ganze Zeit in derselben Schicht, wenn du nicht grad wieder unnötige Abschweifungen hinlegst.

                                                                      Doch hat es. Zu Frage der Zeckmäßigkeit kommen Fragen der Wartungsfreundlichkeit, Erweiterbarkeit, Transparenz, Performance und Skalierbarkeit -- auf die eben nur ein Schichtenmodell die besten Antworten geben kann.

                                                                      Genau deswegen reden wir vom Transport~, DataAcccess~ und anderen Layers. du hast doch einmal selbst den Begriff Monolith für Bytesequenz verwendet der im Transportlayer anzusiedeln ist. Andererseits beschreibt ein abstrakter Datentyp Methoden für den wahlfreien Zugriff (Random Access) und ein Serializer vermittelt zwischen diesen Schichten.

                                                                      Wenn man unmittelbar aus dem <form> einen bestimmten Enctype erstellt, geht das freilich auch fernab jeglicher Schichtenmodelle.

                                                                      Aber spätestens dann, wenn aus derselben Quelle ein anderer Enctype gefordert wird, freut man sich doch daß man die ganzen Daten für den wahlfreien Zugriff schon hat und nur einen anderen Serializer braucht.

                                                                      Du siehst also, <form>-Serialize kommt an einem Schichtenmodell gar nicht vorbei. Also wenn wir schon einen Ersatz für jquery.serialize bauen, dann sicher doch auf einem soliden Fundament!

                                                                      Dafür sind wir Programmierer.

                                                          4. Moin pl,

                                                            Du ich will Dir nicht zu nahe treten, aber über diesen Thread hier solltest Du mal ernsthaft nachdenken. So wie es aussieht fehlen Dir eine gehörige Portion Grundwissen und vor Allem Erfahrungen.

                                                            du hast vollkommen Recht.

                                                            Hier ist dein Fisch.

                                                            Viele Grüße
                                                            Robert

                                                        2. Hallo dedlfix,

                                                          Du springst im Thema beliebig hin und her. Erst gefällt dir die Struktur nicht, nun springst du wieder zurück zum Anfang, und bringst Argumente, die schon längst geklärt sind.

                                                          Ja, man bräuchte eine sich automatisch aktualisierende Mindmap (und nein, ein Bullshit-Bingo-Zettel ist keine Mindmap 😉)

                                                          Bis demnächst
                                                          Matthias

                                                          -- Rosen sind rot.
                                              2. PS:

                                                die beschriebene Datenstruktur kann mit dieser Demo getestet werden.

                                                MfG

                                              3. problematische Seite

                                                Moin,

                                                Ach, das ist dein Verständnisproblem. Der Konstruktor von URLSearchParams() kann nicht nur einen Querystring entgegennehmen, sondern auch eine Sequenz entgegennehmen, deren Elemente jeweils eine Sequenz von zwei Strings ist, also ein "Array of Arrays of two Strings". In Code ausgedrückt beispielsweise:

                                                [['foo', 'bar'], ['qux', 'baz'], ...]

                                                Ich frage mich wer auf solche Datenstrukturen kommt, zumal es sich ja um assoziierte Daten handelt {Schlüssel: Wert}. Das führt doch fast zwangsläufig eher hierzu:

                                                [ { name: 'foo', value: 'bar' }, { name: 'foo', value: 'foo' }, { name: 'qux', value: 'baz' }, ]

                                                Unabhängig von meinen diesbezüglichen Überlegungen, Ergebnis siehe obenstehend, erzeugt jQuery(form).serializeArray() ganz genau dieselbe Datenstruktur. Leider ist dabei die FileAPI nicht berücksichtigt, also Uploadfelder werden mit dieser jQuery Funktion nicht erfasst.

                                                Trotzdem ist diese Funktion interessant, nämlich dann, wenn aus den Formulardaten ein anderer Enctype zb. application/json erzeugt werden soll.

                                                Wobei man hinsichtlich Default-Enctype die sich aus mehreren Werten ergebenden Arrays zusammenfassen kann:

                                                { foo: ['foo','bar'], qux: ['baz'] }

                                                So daß sich obenstehende schmale Datenstruktur ergibt ohne Redundanzen.

                                                Diese Zusammenfassung ist deswegen so wichtig, weil sie die direkte Adressierung nach dem Feldnamen ermöglicht. Und ist natürlich auch unabhängig vom Enctype. D.h., man kann die Datenstruktur auch serverseitig, also nach der Übertragung so umbauen.

                                                Wie auch immer, URLSearchParams ist ja nicht das Problem und auch nicht die Lösung dafür, die Daten eines Formulars zu erfassen. Betrachtet man das <form>-Element selbst als Schnittstelle, so bietet das DOM schon eine Reihe an Möglichkeiten an die eingegebenen Daten zu kommen ohne daß man jedes Eingabefeld mit einer ID spicken muss.

                                                So isses. Und die FileAPI da mit reinzunehmen ist auch kein Problem.

                                                MfG

  7. Hi there,

    grad zufällig gefunden und weil's zum Thema passt: https://snipcart.com/blog/learn-vanilla-javascript-before-using-js-frameworks

    1. Moin klawischnigg,

      Danke für diesen Link!

      Pretending To Know JavaScript – The Definitive Guide
      O RLY?

      Schönen Montag,
      Robert

  8. Hej Robert,

    Neben CSS als neuem JavaScript wird das wohl das nächste große Ding.

    CSS ist auch das neue SASS 😉

    Marc