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]
