[Web-SIG] Re: Form field dictionaries

[Ian Bicking]

On Friday, October 24, 2003, at 10:25 AM, Simon Willison wrote:
> David Fraser wrote:
>> Fine. So we need a clever way of providing them in either form. I 
>> think using dictionaries for this is essential - even if it means 
>> defining a single dictionary that remembers which fields are get and 
>> which are post, and provides different wrappers to see the different 
>> elements.
>
> I am convinced that the neatest way of handling this is to replicate 
> PHP's form field dictionaries, in particular these three:
>
> GET - the form data that came in via GET
> POST - the form data that came in via POST
> REQUEST - the above two dictionaries combined (POST over-riding GET)
>
> However, there is one special case that needs considering: multiple 
> form fields of the same name. For example, the following URL:
>
> script.py?a=1&a=2
>
> What should GET['a'] return? There are three possibilities: return a 
> list (or tuple) containing 1 and 2, or return 1 (the first value) or 
> return 2 (the second value). The first has a huge disadvantage in that 
> all of a sudden accessing the GET dictionary could return a list or a 
> string - code will then have to start checking the type of the 
> returned data before doing anything with it. The second and third have 
> the disadvantage that some form data gets "lost" by the dictionary.

I think this is already really decided -- if (and only if) there are 
multiple values, then a list should appear in the output.  I.e., {'a': 
['1', '2']}.  This is how cgi works, and how almost all Python request 
objects work.  When there's near-consensus in previous implementations, 
I think we should keep the conventional behavior.  Plus, it means less 
things to decide, which should make the design faster to create.

There are more elegant ways to deal with this, but they are also more 
complex, and there's no One Right Way.  The conventional way throws 
nothing away, can be adapted to any previously existing URL scheme, and 
does not require any trust in the user agent to submit correct input.  
It's also easy to go from the conventional input to another style of 
input, but difficult to go the other way.

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org