Selbstverständlich kann das mein Parser auch. Das Einzige was ich von CGI.pm übernommen habe ist der Name der Methode. So liefert $self->param('name') den Wert zu diesem Parameter, egal mit welchem Enctype und Requestmethode der Request erfolgte. Wobei dieser Wert natürlich auch eine Liste von Werten sein kann.

Wobei $self nicht eine Instanz des Parsers ist sondern eine Instanz meines Framework welche die Methoden der Parserinstanz lediglich delegiert, der Parser ist also nichts weiter als ein austauschbarer Layer.

Ansonsten beschreite ich beim Entwicklen von Webanwendungen einen Weg, der sich hier http://rolfrost.de/parser.html schon andeutet. D.h., ich trenne Schlüsselparameter von den anderen Parametern die der Datenübertragung dienen und nutze hierfür konsequent das eigens entwickelte Schichtenmodell was über eigene Enctypes erweiterbar ist.

So können die Schlüsselparameter über den query_string übertragen werden und Binaries am Stück oder in Arrays über den Message Body die serverseitig bytegenau wiederhergestellt werden können. Eine andere zweckmäßige Datenstruktur ist der Hash of Hashes: Schlüselparameter im {param}-Hash fein säuberlich von den Nutzdaten getrennt. Und genau diese Trennung erfolgt bereits in meinem Parser (siehe Link).


MfG

PS: PHP beschreitet einen anderen Weg, so werden Arrays nur dann gebildet wenn die Namen der Parameter der Konvention name[] oder name[0], name[1], address[person][name] folgen.

Das heißt aber auch nichts weiter als daß man eben bstimmte Vereinbarungen treffen muss um ein bestimmtes Verhalten sicherzustellen solange dies die legacy Enctypes allein nicht hergeben. Diesbezügliche Unzulänglichkeiten liegen also nicht etwa an CGI.pm sondern an den genannten Content-Types.

Die Unzulänglichkeiten von CGI.pm liegen ganz woanders. Und daß der Enctype multipart/form-data auf den Müllhaufen der IT-Geschichte gehört ist seit Jahrzehnten meine Rede und ja ich kann das auch begründen.


.
Last edited: 2018-03-13 10:10:26 +0100 (CET)