click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Schellink <>
Subject Re: AbstractLink request parameter leak
Date Fri, 04 Jun 2010 14:09:59 GMT
On 4/06/2010 23:09, Adrian A. wrote:
>> 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.

Nods, users could depend on this behavior, but it is still a leak and in stateful pages an
bigger issue (memory leaks) if the link parameters is not managed properly. I'd call this
misfeature at best and unfortunately we might be stuck with it.

An alternative which is to check if the request is Ajax and only bind the known parameters.
keeps the current behavior while Ajax requests uses the new behavior.

>> 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?

Sure, with Ajax this is quite common in order to update the link state:

Keep an eye on Firebug's "Net" panel to see the parameter leak.

>> 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.

Its not a configuration that can be switched on/off. Interestingly SubmitLink had the same
where the Form fields were added to the link parameters. The workaround was to add a prefix
to each
link parameter in order to identify parameters from field name/value pairs.

> What about:

That is a big change as it would mean apps would move to a new link hierarchy. Clean slates
great but not for existing apps. Perhaps for v3.0 we could contemplate major backwards compatibility


View raw message