Datenstrukturen aus Formulareingaben

[dedlfix]

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.