nicht angemeldet
Meine Herren!
Die Idee die dahintersteckt: class-Names sind gleichnamige Schlüssel in einem Objekt
Wieso nicht die vorhanden Kapazitäten nutzen, das name-Attribut ist für die Kodierung der Daten vorgesehen:
<form action="foo" enctype="application/x-www-form-urlencoded">
<input name="person[familienname]">
<input name="person[rufname]">
<button>Absenden</button>
</form>
<textarea name="person[anschrift]">
Diese Art der Notation ist mit den bestehenden Formular-Kodierungs-Algorithmen kompatibel. Und zukünftige Algorithmen werden mit hoher Wahrscheinlichkeit abwärtskompatibel zu dieser Notation entworfen. So wie es derzeit auch mit dem JSON-Formular-Kodierungs-Algorithmus geschieht.
das wird clientseitig so zusammengebaut, dass serverseitig die Werte direkt über den Namen adressierbar sind.
Der Server kann nicht durch Zauberhand erraten, wie Daten zu verstehen sind, die ihm gesendet werden. Diese Information steckt man dem Webserver über den MIMEType. Ein MIMEType application/json sagt dem Server da kommen JSON-Daten. Mit dem MIMEType text/plain sagen wir dem Server hier kommen perfide Text-Daten. Für die gängigen Formate bieten die Webserver den Entwicklern häufig eine integrierte Schnittstelle. Ein Beispiel:
Wenn wir das Formular dort oben an einen Apache-Webserver mit PHP schicken, kann ein PHP-Entwickler bequem über das $_POST-Array darauf zugreifen: Mit $_POST['person']['rufname'] können wir den Rufnamen intuitiv auslesen.
Der MIMEType "application/octet-stream" ist in gewisserweise ein Sonderfall, sinngemäß teilt er dem Server mit: "Hier kommt ein Haufen Binärdaten, über die du nichts weiter wissen brauchst". Es kann alles kommen: Eine Bild, ein Zip-Archiv ein JSON-Objekt oder ein stinknormaler Text, für die Weiterverarbeitung sollte das egal sein. Der Server kann dem Backend-Entwickler also auch nicht weiter unter die Arme greifen, um mit den Daten fertig zu werden. Du als Entwickler kannst natürlich erraten, wie die Daten zu interpretieren sind, weil du ja selber das Formular dazu erstellt hast. Besser ist man verlässt sich nicht auf seine Fertigkeiten zu Raten, sondern man übermittelt einen aussagekräftigen MIMEType. Es ist auch möglich eigene MIMETypes zu senden: "application/x-hotti-eav" würde sich doch anbieten.
Übliche HTML-Formulare unterstützen nur drei MIMETypes "text/plain", "application/x-www-form-urlencoded" und "multipart/form-data". Leider ist nicht mal "application/json" dabei, wir können aber natürlich die Standard-Absende-Routine des Formulars unterbinden und mit Ajax trotzdem JSON senden, wenn wir darauf angewiesen sind. Wenn wir sowas aber machen, dann sollten wir mit Rücksicht auf die bestehenden Formular-Kodierungen nur Informationen verschicken, die für eine Kodierung vorgesehen sind, das sind a) offensichtlich die Werte der Formular-Felder und b) die Namen der Formular-Felder. Alles andere, insbesondere Klassennamen, sollten in so einem Work-Around IMHO keine Anwendung finden, weil sie keine trivialen Kandidaten für die Übermittlung sind (1).
So ähnlich sieht es bei den HTTP-Verben aus: Von HTML-Formularen werden bis heute nur "GET" und "POST" unterstützt, aber wir können wieder auf AJAX ausweichen, um dieses Problem zu umschiffen. Es gibt Bestrebungen der HTML-Working-Group dieses Problem zu lösen: http://cameronjones.github.io/form-http-extensions/index.html
- Mit dieser Einschränkung, wird deine Idee zur Lösung des ursprünglichen Problems in diesem Thread, natürlich hinfällig. Aber solche Einschränkungen helfen eben dabei strukturierte Software zu entwickeln und die Veranwortlichkeiten sauber getrennt zu halten.
--
“All right, then, I'll go to hell.” – Huck Finn
MudGuard