tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andera A. (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAP5-2063) Add support for multivalued parameters in Link
Date Fri, 04 Oct 2013 07:18:53 GMT

    [ 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

View raw message