One example off the top of my head: Adobe Search&Promote relies on the order of query string parameters to persist the ordering of breadcrumbs across requests.
Mark Adamcin Acquity Group Sent from a mobile device. > On Jan 15, 2014, at 3:36 AM, Carsten Ziegeler <[email protected]> wrote: > > I'm wondering if this is really a general use case? So far I've never > encountered a web application which needs the order of the request > parameters. > > As your use case even requires to get the order in the case of a POST we > would need to add the additional logic you mention which is executed for > all post requests no matter if the information is used. > > I'm wondering if its worth the effort - can't you simply register a servlet > filter (not a Sling servlet filter) which does the magic for you for those > URLs where it matters? > > Regards > Carsten > > > 2014/1/15 Alexander Klimetschek <[email protected]> > >>> 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 > > > > > -- > Carsten Ziegeler > [email protected]
