You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Francois Armand <fa...@linagora.com> on 2009/01/05 11:54:50 UTC

Re: zone problems

Joachim Van der Auwera wrote:
> 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.
Simply use the "id" parameter. For example, you could have:

<t: zone t:id="FormZone" id="prop:uniqueIdGenerator">....

"t:id" is the id of Tapestry component, from a Tapestry point of view: 
it's the name used by the framework to reference this component.
"id" is the "clientId", the id rendered in the HTML. It's no really 
relevant for server side operation, but primordial for client sided one.

When you build massively AJAXified component, built from  several other 
simpler AJAX-ified component, you definitely want to have clearly 
defined client-id, and so impose in first render phase a value to them. 
For example, I use to assign a value to clientId in SetupRender method 
thanks to "renderSupport.allocateClientId(name);"

Hope it helps,

-- 
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
http://fanf42.blogspot.com
InterLDAP - http://interldap.org 
FederID - http://www.federid.org/
Open Source identities management and federation


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org