When binding incoming request parameters, AbstractLink adds all incoming
parameters to its own
parameter map.
Given the url: /page.htm?id=5&customer=John
will add both "id" and "customer" to the link parameter map:
assertEquals(5, link.getParameter("id")); // true
assertEquals("John", link.getParameter("customer")); // true
A problem I'm picking up when using AbstractLink to make Ajax GET requests is
that all Ajax request
parameters are also added to the link parameters.
One solution could be to only bind parameters that was explicitly set before
onProcess:
I think this will lead to confusion. AbstractLink behaves the way users
were just too used to: to have all parameters bound.
> If the link is then sent back to the browser as a
> Partial result, the link renders the parameters sent as part of the
> Ajax request. On subsequent
> request the Ajax parameters will again be added to the link which
> grows unbounded.
Can you please give me examples when does the user need to send back the
link as part of the Partial?
This could have an impact on existing apps if they rely on this behavior.
I think they really rely on this, since it's a default configuration
that makes life easier, and also since this component is virtually in
every Click Page that users have.
Thoughts?
What about: https://issues.apache.org/jira/browse/CLK-543
A new Link Control as described in the "Update part" of the issue would
be better suited for Ajax operations and a clean start (with the
explicit parameter use as you described), thus leaving the deprecated
AbstractControl + descendants to work as before for the existing
applications.
In a few versions, after the removal(or move out of Click) of those
deprecated controls, it would lead to less fragmented controls and also
a more predictable API.
Adrian.
