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.
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
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
