[jira] [Commented] (TAP5-2063) Add support for multivalued parameters in Link

["Andera A. (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TAP5-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13785963#comment-13785963 ] 

Andera A. commented on TAP5-2063:
---------------------------------

Yep, I recently updated to version 5.3.7, and I noticed the same problem that Howard M. Lewis Ship describes in his comment from 04/Jun/13 19:26. And I find it a bit problem.

I have a page (actually, several already!) that takes an @ActivationRequestParameter-annotated parameter. If it is set, this parameter is used on that page to visually highlight the element represented by that parameter from a list of possible items, and to display further details of the selected element (i.e.: think of a master-detail page). I want the elements on the list to be clickable, so that if you click on a different element, the page will reload with that new parameter, effectively allowing you to "choose" which one you want to work with.

Before 5.3.7, I used to create the links on the list by setting the parameter on the pageLink (i.e.: <a href="#" t:type="pageLink" t:page="this/page" t:parameters="prop:parameterMapForTheLink">). In that way, if any of the parameters on the map would have the same name as the one in the @ActivationRequestParameter, the link would effectively keep the one given in the map. And everything worked fine.

Because the only way now to prevent the @ActivationRequestParameter value from appearing on the generated links is by setting the value of the field to null, I tried to do so (setting the value to null) after I had handled the parameter within onActivate(), and that way I can generate controlled links again. But this gives a problem with forms: on the same master-detail page from before I allow to edit the details of the selected element; when the @ActivationRequestParameter is set to null, the form's target URL has no parameter, so the page fails to identify which item to work with upon submitting it.

I don't think it's a mistake to allow multi-valued @ActivationRequestParameter on the link, but the implementation needs a bit of re-thinking. I would expect that, for the explicit parameters passed to the link, the Tapestry framework should consider "ah! this is what the developer explicitly wants this link's parameter's value to be". Or put a different way, Tapestry would refrain from adding values out of the page's set of properties marked with @ActivationRequestParameter, for parameters explicitly assigned in the link's parameters' map.

> Add support for multivalued parameters in Link
> ----------------------------------------------
>
>                 Key: TAP5-2063
>                 URL: https://issues.apache.org/jira/browse/TAP5-2063
>             Project: Tapestry 5
>          Issue Type: Improvement
>          Components: tapestry-core
>            Reporter: Alejandro Scandroli
>            Assignee: Kalle Korhonen
>             Fix For: 5.3.7, 5.4
>
>         Attachments: TAP5-2063_1.patch
>
>
> Request.java has support for multivalued parameters but there is no way to add more than one parameter with the same name to the Link. Instead of throwing an IllegalArgumentException when the link already has a parameter with the same name Link.addParameter should add it to the URL as a multivalued parameter.



--
This message was sent by Atlassian JIRA
(v6.1#6144)