Zeigt her Eure Formulare

[1UnitedPower]

Meine Herren!

Horst Formlos

Schon die Prämisse ist falsch. Wieso glaubst du Webserver können nur eine derartig flache API (1) zum Weiterverarbeiten von Formular-Daten bereit stellen? Den Zusammenhang zwischen Formular-Kodierungen und Server-APIs habe ich ja bereits an anderer Stelle beleuchtet.

Das Szenario, das du beschreibst, sehe ich nicht als gegeben. Und noch schlimmer, verursacht du durch deinen Ansatz erst Probleme, wo vorher keine waren. Wieso benutzt du nicht das name-Attribut, um die Zusammengehörigkeit von Elementen zu kodieren? Wieso benutzt du da Klassen? Und wie würdest du tiefer verschachtelte Hierarchien mit Klassen kodieren? Webentwickler sind seit Jahren dazu in der Lage, diese Assoziationen im name-Attribut auf eine intuitive Art zu illustrieren. Es haben sich bestimmte syntaktische Konventionen herausgebildet, insbesondere die Notation über eckige Klammern:

Benannte Eigenschaften werden einfach so kodiert:

<input name="person[familienname]">  
<input name="person[rufname]">

Mit der selben Syntax, können wir auch tiefer verschachtelte Zusammenhänge ausdrücken:

<input name="person[adresse][plz]">  
<input name="person[adresse][stadt]">  
<input name="person[adresse][straße]">

Listen stellt man da, indem man ein Klammernpaar hinten anstellt.

<input name="geschwister[]">  
<input name="geschwister[]">

Diese Art der Notation ist inzwischen zu einem "de-facto"-Standard herangewachsen. Und das, weil sie einfach sehr gut funktioniert.

1. Du nennst das immer nur Stuktur, ich habe den Begriff mal etwas abstrakter gewählt. Die API kann beliebig komplex sein, es muss sich nicht um ein planes Parameter-Objekt handeln, wie etwa das $_POST-Array in PHP. Vergleiche das zum Beispiel mal mit der Komplexität von express' bodyParser.