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 even bigger issue (memory leaks) if the link parameters is not managed properly. I'd call this a 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. This 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: http://clickclick-jquery.appspot.com/ajax/action-link-demo.htm 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 issue 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: https://issues.apache.org/jira/browse/CLK-543 That is a big change as it would mean apps would move to a new link hierarchy. Clean slates are great but not for existing apps. Perhaps for v3.0 we could contemplate major backwards compatibility changes. Bob
