[
https://issues.apache.org/jira/browse/SLING-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776407#action_12776407
]
Alexander Klimetschek commented on SLING-1178:
----------------------------------------------
> ok. i agree that the servlet spec does not define the order of the request
> parameters. however, multipart/form-data does
The html spec does that for application/x-www-form-urlencoded as well, see
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
2. The control names/values are listed in the order they appear in the
document.
The servlet spec is to blame here. Maybe it will get fixed in a new version ;-)
so it's good that Sling does not fiddle with the ordering.
> Preserve request parameter order throughout the entire request stack
> --------------------------------------------------------------------
>
> Key: SLING-1178
> URL: https://issues.apache.org/jira/browse/SLING-1178
> Project: Sling
> Issue Type: Improvement
> Components: Engine, Servlets
> Affects Versions: Servlets Post 2.0.4, Engine 2.0.6
> Reporter: Tobias Bocanegra
> Assignee: Felix Meschberger
> Priority: Minor
> Fix For: Servlets Post 2.0.6, Engine 2.1.0
>
> Attachments: ordered_params-r834673.patch
>
>
> When posting a form to the sling post servlet i encountered that the order of
> the request parameters is not preserved,
> even the browser sends the params according to the submitted form.
> for example the following form:
> <form name="input" action="/content/testform" method="POST">
> <input type="hidden" name="./sen...@delete"/><br/>
> Address 0: <input type="text" name="./sendTo/0/address" /><br/>
> Text 0: <input type="text" name="./sendTo/0/text" /><br/>
> Address 1: <input type="text" name="./sendTo/1/address" /><br/>
> Text 1: <input type="text" name="./sendTo/1/text" /><br/>
> Address 2: <input type="text" name="./sendTo/2/address" /><br/>
> Text 2: <input type="text" name="./sendTo/2/text" /><br/>
> <input type="submit" value="Submit" />
> </form>
> results in:
> deleted("/content/testform/sendTo");
> created("/content/testform/sendTo");
> created("/content/testform/sendTo/2");
> modified("/content/testform/sendTo/2/address");
> modified("/content/testform/sendTo/2/text");
> created("/content/testform/sendTo/1");
> modified("/content/testform/sendTo/1/text");
> created("/content/testform/sendTo/0");
> modified("/content/testform/sendTo/0/text");
> modified("/content/testform/sendTo/0/address");
> modified("/content/testform/sendTo/1/address");
> i first thought it's just the ModifyOperation which uses a HashMap instead of
> a LinkedHashMap:
> Map<String, RequestProperty> reqProperties = new HashMap<String,
> RequestProperty>();
> but the params arrive out of order already from the request.getParameterMap().
> i guess the "ParameterMap" needs to extend from LinkedHashMap, too:
> class ParameterMap extends LinkedHashMap<String, RequestParameter[]> ...
> after fixing those 2 classes, the order is correct:
> deleted("/content/testform/sendTo");
> created("/content/testform/sendTo");
> created("/content/testform/sendTo/0");
> modified("/content/testform/sendTo/0/address");
> modified("/content/testform/sendTo/0/text");
> created("/content/testform/sendTo/1");
> modified("/content/testform/sendTo/1/address");
> modified("/content/testform/sendTo/1/text");
> created("/content/testform/sendTo/2");
> modified("/content/testform/sendTo/2/address");
> modified("/content/testform/sendTo/2/text");
> i'll attach the patch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
