Providing a way to obtain parsed form data in an ordered and unalterated representation. #355

Closed
tizoc opened this Issue Mar 5, 2012 · 5 comments

3 participants

@tizoc

http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4

application/x-www-form-urlencoded

The control names/values are listed in the order they appear in the document.
The name is separated from the value by `=' and name/value pairs are separated from each other by `&'.

multipart/form-data

A "multipart/form-data" message contains a series of parts, each representing a successful control.
The parts are sent to the processing agent in the same order the corresponding controls appear in
the document stream. Part boundaries should not occur in any of the data; how this is done lies
outside the scope of this specification.

When parsing such data, Rack returns a Hash, with values of the same name merged (unless they end with '[]', in such case an array is constructed).

I propose an alternative method that returns an array of [{name => value}, ...] instead of a Hash.

Thoughts?

@tizoc

For reference, the way WebOb provides this:

http://docs.webob.org/en/latest/reference.html#query-post-variables

(the .items() part)

@tizoc

Werkzeug provides a similar solution: http://werkzeug.pocoo.org/docs/datastructures/#werkzeug.datastructures.OrderedMultiDict

>>> from werkzeug import OrderedMultiDict
>>> d = OrderedMultiDict([('a', 'b'), ('b', 'a'), ('a', 'c')])
>>> d.items(True)
[('a', 'b'), ('b', 'a'), ('a', 'c')]

This is just one of the possible approaches (having a special dictionary object instead of a plain Hash object). Alternatively, Rack could just enumerate the key:value pairs in order and leave it up to the user to decide how to construct the mapping.

@omab

+1

@tizoc

Other than being "the correct thing", there are practical implications:

http://www.plope.com/peppercorn

I was working on something similar, thats when I noticed that Rack::Request doesn't provided the functionality required.

@raggi
Official Rack repositories member

parse_query rather than parse_nested query is close to what you want. You may also just want to look at rack.input directly.

If you wanted to produce a patch that adds a new method to return an array of tuples, that sounds fine. returning an array of single element hashes seems very inefficient.

@raggi raggi closed this Nov 2, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment