FromData toString und Kontextwechsel

[dedlfix]

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.