Sure, you can register a plain http filter which runs before Sling. The code can be generic, so be used by everyone who needs it, but it can be configured to only run on specific requests (whatever the pattern is to identify those) as the majority of requests does not need this And by having a http filter doing the stuff, it's available to all java based webapps and not tied to Sling
Carsten 2014/1/15 Alexander Klimetschek <[email protected]> > In my case it is Adobe Scene7 - which uses rendering commands and layers > with URLs such as this: > > "layer=0&img=mypic.jpg&rotate=10&layer=1&img=anotherpic.jpg" > > The location of the individual "layer" or "img" parts is important. > > It comes up whenever you want to map tree hierarchies (with ordered > children) onto query parameters. > > Another use case I had was the Adobe CQ querybuilder, which I had to > design with ugly number prefixes to work around the issue (1_property & > 2_property and 3_group.1_property & 3_group.2_property). > > Regarding the filter outside Sling > - is that possible to do within a Sling setup? > - custom URL parsing to decide where to use it is bad when Sling should do > it > - discussion has shown it can be tricky (query vs. POST body, url vs. > form-data) > - custom query parsing in application code is not ideal > - general availability of this with a clear API would be great (as a fix > to the servlet API oversight here) > > Cheers, > Alex > > On 15.01.2014, at 05:46, Mark Adamcin <[email protected]> wrote: > > > 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] > > -- Carsten Ziegeler [email protected]
