On 14.01.2014, at 18:05, Felix Meschberger <[email protected]> wrote:
> Am 14.01.2014 um 18:44 schrieb Alexander Klimetschek <[email protected]>: > >> /do?move=10steps&turnLeft=45deg&move=20steps >> >> [...] >> >> This could be easily solved by extending Sling's RequestParameterMap [0], >> e.g. with a method returning an key-value iterator: >> >> Iterator<KeyValuePair> getParameters() > > Well, that is a bit esoteric IMHO and I would not go as far as this. It's not esoteric – only if java servlet apis or other web frameworks trained you to see parameters as a hash and not as an ordered key-value pair list, what they really are! My use case here is an instruction set, where it does make a difference where same-name commands (such as "move" in my above example) appear. Unfortunately I can't change this, it is an existing system that is migrated to Sling, with many clients out there, and changing the URL format is not an option (the other option then would be to ditch Sling ;(. > In the case of a multipart/form-data the input is in general not a string and > can get quite big, particularly if files are involved. Right, that keep-the-string option would only apply to the url-encoded case. I don't like it either. Another option would be to just change Sling so that I can extend the parameter handling with some special service (i.e. an alternative to wrapping the request object with a filter - what is done now in my case and works in servlet engines). I would prefer the above Iterator API though (given the querystring format in my case is compatible and I can change to request parameter api). Cheers, Alex
