Howard Lewis Ship wrote:
Looks reasonable to me; another alternative is to assign the id
parameter of the zone to a value you know will be unique on the client
side. Sometimes having Tapestry provide a dynamic client id is not the
best approach.
How could that be done inside a component? The "t:id" does not accept
bounding prefixes.
Kind regards,
Joachim
On Mon, Dec 29, 2008 at 4:03 PM, Joachim Van der Auwera
<joac...@progs.be> wrote:
I have found there is a problem when creating a component which includes a
zone and that zone is after the actionlink which is used to update it.
In that case, the existing zone's getClientId() cannot be used to fill in
the zone id as this is initialized in the beginRender and that has not yet
accured when the id is requested.
I have cloned the Zone component to use the following :
@Parameter( name = "id", defaultPrefix = BindingConstants.LITERAL )
private String clientId;
private boolean clientIdInitialized;
public String getClientId()
{
if ( !clientIdInitialized )
{
if ( !resources.isBound( "id" ) )
{
clientId = renderSupport.allocateClientId( resources );
}
else
{
clientId = renderSupport.allocateClientId( clientId );
}
clientIdInitialized = true;
}
return clientId;
}
And to always use getClientId() instead of directly referring to the
"clientId" variable.
This seems to make a difference. Would it be sensible to modify the Zone
component to behave like this by default?
Kind regards,
Joachim
--
Joachim Van der Auwera
PROGS bvba, progs.be
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Joachim Van der Auwera
PROGS bvba, progs.be
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
