Mailing-List: contact dev-help@click.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@click.apache.org
Received-SPF: pass (athena.apache.org: domain of
 gcwcd-click-development-2@m.gmane.org designates 80.91.229.12 as permitted
 sender)
To: dev@click.apache.org
connect(): No such file or directory
From: "Adrian A." <a.adrian.tech@gmail.com>
Subject: Re: AbstractLink request parameter leak
Date: Fri, 04 Jun 2010 15:09:46 +0200
Lines: 44
Message-ID: <huatv0$eom$1@dough.gmane.org>
References: <4C08EBCF.7050803@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: 85.121.188.246
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
In-Reply-To: <4C08EBCF.7050803@gmail.com>

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