click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian A." <>
Subject Re: AbstractLink request parameter leak
Date Fri, 04 Jun 2010 13:09:46 GMT
> 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:

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 

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.


View raw message