pl: FormData in Ajax-Response

s. Thema. Also nicht im Request, sondern in der Response: Mein xhr-Objekt soll die response als FormData-Objekt akzeptieren. Wie bringe ich das dem xhr-objekt bei?

Mein Versuch: xhr.responseType = "FormData"; bringt es nicht. Meinerseits sind Content-Type: multipart/form-data gesendet und eine Datei korrekt für diesen Content-Type. Idee?

Folgende Nachrichten verweisen auf diesen Beitrag:

  1. Aloha ;)

    Mein Versuch: xhr.responseType = "FormData"; bringt es nicht. Meinerseits sind Content-Type: multipart/form-data gesendet und eine Datei korrekt für diesen Content-Type. Idee?

    Rateversuch ins Blaue: FormData ist doch gar kein gültiger Mimetype, oder?

    Grüße,

    RIDER

    -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
    Erreichbar manchmal im Self-TS (ts.selfhtml.org) oder sonst - wenn online - auf dem eigenen TeamSpeak-Server (fritz.campingrider.de) oder unter:

    # Facebook # Twitter # Steam # YouTube # Self-Wiki #

    ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
    1. Hallo Camping_RIDER,

      Mein Versuch: xhr.responseType = "FormData"; bringt es nicht. Meinerseits sind Content-Type: multipart/form-data gesendet und eine Datei korrekt für diesen Content-Type. Idee?

      Rateversuch ins Blaue: FormData ist doch gar kein gültiger Mimetype, oder?

      responseType enthält keinen MIME-Type, sondern XMLHttpRequestResponseType. Und da sind die validen Werte halt ein Leerstring, arraybuffer, blob, document, json oder text - FormData gehört nicht dazu.

      Ich verstehe aber ehrlich gesagt auch nicht die Frage aus dem OP.

      LG,
      CK

      -- https://wwwtech.de/about
      1. Aloha ;)

        Rateversuch ins Blaue: FormData ist doch gar kein gültiger Mimetype, oder?

        responseType enthält keinen MIME-Type, sondern XMLHttpRequestResponseType.

        Ah, danke. Das hatte ich in dem Moment nicht auf dem Schirm.

        Grüße,

        RIDER

        -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
        Erreichbar manchmal im Self-TS (ts.selfhtml.org) oder sonst - wenn online - auf dem eigenen TeamSpeak-Server (fritz.campingrider.de) oder unter:

        # Facebook # Twitter # Steam # YouTube # Self-Wiki #

        ch:? rl:| br:> n4:? ie:% mo:| va:) js:) de:> zu:) fl:( ss:| ls:[
  2. s. Thema. Also nicht im Request, sondern in der Response: Mein xhr-Objekt soll die response als FormData-Objekt akzeptieren. Wie bringe ich das dem xhr-objekt bei?

    Ein FormData-Objekt akzeptiert ein xhr-Objekt weder "im Request" noch "in der Response", sondern in der Funktion send als Parameter um daraus einen Request zu bauen.

    Mein Versuch: xhr.responseType = "FormData"; bringt es nicht. Meinerseits sind Content-Type: multipart/form-data gesendet und eine Datei korrekt für diesen Content-Type.

    Solange responsetype "FormData" nicht unterstützt, kannst du aus der Response auch kein FormData-Objekt bauen lassen welches du am xhr-Objekt auslesen kannst.
    Wenn du das wirklich aus welchen Gründen auch immer benötigst, kannst du dir das FormData-Objekt auch selbst zusammenbasteln. Allerdings sehe ich den Sinn nicht so ganz, da das FormData-Objekt nur den Zweck hat Formulardaten einfach über ein xhr-Objekt an den Server zu senden.
    Daten vom Server sendet man dann an den Client in einer für diesen sinnvollen Form zurück. Das ist aber vermutlich kein FormData-Objekt.

    1. Daten vom Server sendet man dann an den Client in einer für diesen sinnvollen Form zurück.

      Ja, richtig. In jedem Fall wird eine Datei gesendet. Aber manche haben ja schon mit dem Dateibegriff (Niklaus Wirth um 1980) ihre Probleme ;)

      So sieht die Datei mit Enctype multipart/form-data aus

      FormData serialisiert strukturierte Daten. Das können andere Serializer auch. Wichtig ist nur, dass CLient und Server dasselbe machen. Mit FormData können sie das, aber leider scheiterts an der Übertragung bzw. an dem nicht unterstützen responseType.

      1. Daten vom Server sendet man dann an den Client in einer für diesen sinnvollen Form zurück.

        Ja, richtig. In jedem Fall wird eine Datei gesendet. Aber manche haben ja schon mit dem Dateibegriff (Niklaus Wirth um 1980) ihre Probleme ;)

        Und mit was? Mit Recht!

        Eine HTTP-Antwort ist keine Datei, das wird nicht richtiger, je häufiger du es wiederholst. Du solltest dein verstaubtes Wissen unbedingt wieder auf den aktuellen Stand der Technik bringen. 35 Jahre in der Informatik sind eine Ewigkeit. Und im übrigen glaube ich, dass auch Nikolaus Wirth nicht mit deinem Mantra "Alles ist eine Datei" einverstanden wäre, weder damals noch heute.

        1. Daten vom Server sendet man dann an den Client in einer für diesen sinnvollen Form zurück.

          Ja, richtig. In jedem Fall wird eine Datei gesendet. Aber manche haben ja schon mit dem Dateibegriff (Niklaus Wirth um 1980) ihre Probleme ;)

          Und mit was? Mit Recht!

          Eine HTTP-Antwort ist keine Datei, das wird nicht richtiger, je häufiger du es wiederholst. Du solltest dein verstaubtes Wissen unbedingt wieder auf den aktuellen Stand der Technik bringen. 35 Jahre in der Informatik sind eine Ewigkeit. Und im übrigen glaube ich, dass auch Nikolaus Wirth nicht mit deinem Mantra "Alles ist eine Datei" einverstanden wäre, weder damals noch heute.

          Wenn hier was verstaubt ist, dann isses der Enctype multipart/form-data. Aber wenn es den schon gibt, dann können solche Sequenzen (hierin liegt der Dateibegriff) per HTTP auch übertragen werden. Genau das war die Idee.

          Falls Du ein Programmierer bist, der Enctype abstrahiert untenstehende Datenstruktur:

          $VAR1 = { 'file' => [ { 'content_length' => 27226, 'content_type' => 'image/png', 'filename' => 'tabbar-solid-bg@2x.png', 'iohandle' => bless( \*Symbol::GEN1, 'IO::String' ), 'name' => 'file' }, { 'content_length' => 7168, 'content_type' => 'application/octet-stream', 'filename' => 'Thumbs.db', 'iohandle' => bless( \*Symbol::GEN2, 'IO::String' ), 'name' => 'file' } ], 'load' => [ 'Dateien Hochladen' ], 'key' => [ 'aged45jhiz8dn62' ] };

          Wobei ich mich anhand Deiner Beiträge immer wieder frage, ob du zu abstraktem Denken fähig bist. Deswegen noch der Hinweis: Dei Datenstruktur ist nur ein Beispiel.

          1. Wenn du mit deiner Antwort sowieso nicht auf mein Posting eingehst, musst du es auch nicht zitieren und darunter antworten. Dein Text hätte auch prima in dein Ausgangsposting gepasst oder als ergänzende Antwort darauf stehen können (von persönlichen Beleidigungen ein Mal abgesehen, die sparst du dir besser gleich).

            Falls Du ein Programmierer bist, der Enctype abstrahiert untenstehende Datenstruktur:

            Nein, wann lernst du endlich Mal die richtige Fachsprache zu verwenden? Ein Enctype abstrahiert nichts, er spezifiziert (De-)Kodierungsforschrifften. Enctype ist ein Kofferwort, dass sich aus Encoding (Kodierung) und Type (Typ) zusammensetzt. Es handelt sich also um einen Kodierungstyp. Die Kodierung- und Dekodierungsalgorithmen sind haarklein in der HTML5 Spezifikation beschrieben und in fünf Minuten gelesen, die Mühe solltest du dir mal machen. Ein Kodierungsalgorithmus kann so eine Datenstruktur, wie du sie hier gezeigt hast, als Eingabe verwenden. Der Formular-Kodierungsalgorithmus, um den es hier geht, hat allerdings andere Eingaben, auch das hättest du in der HTML5-Spezifikation nachlesen können, bevor du dein falsches Wissen hier verbreitet hast.

            1. Es ist keine Schande, wenn jemand nicht abstrakt denken kann und keine Beleidigung es zu konstatieren.

              Request mit FormData:

              Was beim Browser Enctype heißt, wird im HTTP Request Header Content-Type manifestiert. Außerdem sendet der Browser einen Header Content-Length. Letzteren setzt der Webserver in eine Umgebungsvariable CONTENT_LENGTH (CGI/1.1).

              Anhand dieser beiden Angaben weiß ein Script 1. wieviele bytes aus STDIN zu lesen sind und 2. wie aus der Sequenz die Einzeldaten wiederherzustellen sind. Das Ziel dieser Aktion heißt Random Access, im Script bekommen wir schließlich den wahlfreien Zugriff auf die einzelnen Komponenten einer multipart Message, verpackt in FormData.

              Nun, eine Response mit FormData gänge natürlich auch, zumindest theoretisch:

              Serverseitig werden Daten serialisiert, erzeugt wird eine Sequenz und diese Sequenz wird an den Client gesendet. In Fakt sieht diese Datei ganz genauso aus wie die Datei, welche das JS Objekt FormData als String representiert. So verfügt das FormData-Objekt Methoden, womit auf die einzelnen Komponenten zugegriffen werden kann.

              Abstrakt: ==========

              Random Access/ Datenstruktur => Serialize => Bytesequenz/ Transport

              Und das ganze umkehrbar und den Transport in beiden Richtungen, Request, Response.

              Schönen Tach noch.

              1. Nun, eine Response mit FormData gänge natürlich auch, zumindest theoretisch:

                Praktisch auch Für diese Demo wird das FormData-Objekt einfach so wies ist, zurückgesendet.

                1. Nun, eine Response mit FormData gänge natürlich auch, zumindest theoretisch:

                  Praktisch auch Für diese Demo wird das FormData-Objekt einfach so wies ist, zurückgesendet.

                  Nein, weil du kein FormData-Objekt auf der Serverseite hast. Und selbst wenn du dir ein Objekt auf Serverseite aus den übertragenen Daten erstellst und das auch FormData nennst, ist es ein anderes.

              2. pl, ich lasse mich auf deinen gehaltslosen Gibberisch nicht ein. Denn es ist unmgöglich eine fruchtbare Diskussion zu führen, wenn zwei verschiedene Tonarten und Sprachen gesprochen werden. Jeder kann Mal einem Missverständnis auflaufen oder man kann aneinander vorbei reden. Viele diese Missverständnisse können durch präzises Fachvokabular vermieden werden. Dieses Vokabular lernst du in Fachliteratur und bei besonders technischen Angelegenheiten in Spezifikationen kennen. Solange du diese normative Kraft nicht anerkennst und weiterhin in deiner eigenen kleinen Fachwelt sinnierst, ist jeder Versuch die Diskussion auf ein fachlich angemessenes Niveau zu heben vergebens. Du besitzt leider auch nicht die nötige Selbstreflektion, um zu erkennen, dass selbst deine eigens hervorgebrachten Quellenangaben, nicht im Einklang mit deiner Interpretation dazu stehen. Das ist für mich ein Ausdruck von maßloser Selbstüberschätzung, wenn Niklaus Wirth dir persönlich erklären würde, dass du ihn missverstanden hast, dann würdest du ihn noch für dumm verkaufen. Du wirst beleidigend, wenn es dafür überhaupt keinen Grund gibt und hast nicht die Empathie, es dir einzugestehen (geschweige denn dich dafür zu entschuldigen), selbst wenn du darauf hingewiesen wirst. Bezüglich der Tonart möchte ich dir folgenden Rat geben: Sei kein Arschloch, dann vergibt dir die Fachwelt auch deine fachlichen Schwierigkeiten und ist eher geneigt dich als kompetenten Kollegen zu akzeptieren.

                1. Seiten 42, 43

                  Niklaus Wirth, Algorithmen und Datenstrukturen mit Modula-2

                  B.G. Teubner Stuttgart 1986, 3. Auflage

                  ISBN 3-519-02260-5

                  ISBN 3-519-02260-5

                  Das Wort Abstrakt kommt in diesem Buch sehr sehr oft vor. Es mag sein, dass sich ein paar Begriffe im Laufe der Zeit verändern. Entscheidend jedoch sind die Grundlagen: Egal ob eine Datei in Papier gestanzt, auf ein Magnetband geschrieben oder in ein Socket geschoben wird; abstrakt gesehen ist es dasselbe (IO).

                  Auf og. Seiten macht Wirth dem Leser den Unterschied zwischen wahlfreiem und sequentiellen Zugriff klar. Im JS Objekt FormData finden wir genau das wieder: Methoden implementieren den wahlfreien Zugriff, z.B. FormData.get().

                  Wohingegen xhr.send(FormData) das Objekt als String päsentiert, ergo als Sequenz. Nämlich für den Transport.

                  Und genauso findet man das auch alles in Perl wieder. Leider sind Programmierer der alten Schule am absterben und moderne PLs verbergen essentielle Grundlagen, dessen Wissen eben wesentlich ist für eine abstrakte Denkweise.

                  1. Tach,

                    Seiten 42, 43

                    Niklaus Wirth, Algorithmen und Datenstrukturen mit Modula-2

                    B.G. Teubner Stuttgart 1986, 3. Auflage

                    ISBN 3-519-02260-5

                    so, da ich mich gerade an einem Ort befinde, wo ich Zugriff auf o.g. Buch (allerdings in der 4. Auflage; die 3. Auflage hatte allerdings auch noch einen anderen Titel) habe:

                    Wirth schreibt auf o.g. Seiten im Kapitel „1.11 DIE SEQUENZ-STRUKTUR“ das folgende „Sequentieller Zugriff erlaubt, Daten als Ströme (streams) durch Röhren fliessen zu lassen, die zwischen den Medien gelegt sind.“

                    also Daten nicht Dateien

                    Weiter unten dann „Ein solches System, das Sequenzen auf sekundärem Speicher verwaltet, wird Dateiverwaltung (File-System) genannt. […] Die logische Einheit der Daten auf diesen Medien ist die Sequenz, auch sequentielle Datei oder sequentielles File genannt. Wir verwenden die Bezeichnung File als Synonym zu Sequenz.“

                    Man könnte in den letzten Satz reininterpretieren, dass alles, was Wirth als Sequenz bezeichnet, ein File ist, aber das ist nicht gemeint; weiterhin zeigt die Formulierung an, dass dieser Sprachgebrauch nur für das vorliegende Werk und nicht allgmein gültig ist.

                    Und dann noch aus dem „Vorwort zur 4. Auflage“:
                    „Eine unmittelbare Folge dieses Wechsels war die Notwendigkeit, das Unterkapitel l.l1 über sequentielle Files neu zu schreiben, denn Modula-2 offeriert keine explizite Filestruktur. Stattdessen führen wir im revidierten Kapitel 1.11 das Konzept der Sequenz in einer allgemeineren Form ein. Die auf Modula-2 zugeschnittene Form der Behandlung von sequentiellen Daten gründet auf einigen Modulen, die ebenfalls in Kapitel 1.11 eingeführt werden und in den nachfolgenden Kapiteln Verwendung finden.“

                    Über Sequenzen wird also nur gesprochen, weil die verwendete Programmiersprache keine Möglichkeiten zur Dateibehandlung bietet. Zum Thema Netzwerke lässt er sich gar nicht aus, er unterscheidet nur random access für Daten, die im RAM liegen und sequentiellen Zugriff für Daten auf sekundären Speichern („Plattenspeicher und Magnetbänder“), und zumindest für Dateien auf Festplatten ist auch das nicht mehr korrekt; aber damit ist bei einem 30 Jahre alten Buch zum Thema Informatik ja allgemein zu rechnen.

                    Die letzte Auflage des Buches (von 2004 mit Oberon statt Modula) ist übrigens auch frei einsehbar, falls sich noch jemand interessieren sollte; auf englisch liest sich das auch flüssiger als auf deutsch.

                    mfg
                    Woodfighter

                    Folgende Nachrichten verweisen auf diesen Beitrag:

                2. Das macht keinen Sinn. Er ist der neue Kryptochef, der hat auch gedacht er ist besonders schlau und hat nichts verstanden.

      2. Daten vom Server sendet man dann an den Client in einer für diesen sinnvollen Form zurück.

        Ja, richtig. In jedem Fall wird eine Datei gesendet. Aber manche haben ja schon mit dem Dateibegriff (Niklaus Wirth um 1980) ihre Probleme ;)

        Ich habe mal recherchiert, wo du dein vermeintliches Wissen über Dateien her haben könntest. Die Programmiersprache Pascal hat einen Datentypen file1 (in anderen Programmiersprachen eher als Stream bekannt). Diesen Datentypen beschreibt Niklaus Wirth in seinem Pascal Benutzerhandbuch2. Außerhalb von Pascal hat der Begriff eine völlig andere Bedeutung, Niklaus Wirth differenziert deswegen sogar und spricht von externen Dateien, wenn es um die persistente Speicherung von Daten geht. Ich hoffe damit ist die Sache ein für alle Mal vom Tisch und du wirst Datei nie wieder falsch verwenden. Und falls du doch Mal wieder das Bedürfnis hast vom Pascal Datentypen zu sprechen, dann stell doch bitte gleich den richtigen Kontext her.