superslip103 wrote:
Thanks dh
actually was just about to post the solution as I figured it out literally
minutes ago..
Do you know why it needs to be id and not t:id?
"t:id" and "id" are two really diffents things.
t:id is the id for Tapestry 5 back-end, it's kind of the java identifier
of the component.
id is what is called "clientId" by Tapestry5, it's the Dom id of the
component.
Most of the time, the second one is derivated from the first one. But :
- it is done "on demand", with RenderSupport#generateClientId or
something like that ;
- it is no done for all components at the same moment in the render
pipeline ;
- this id is not persisted
All in all, this lead to some strange behavior, the one you describe
supposedly being one of them.
Personally, I believe that it is one of the more painful things in
Tapestry, somewhere where I do think to a more state-full way of
handling the things would be better.
Why not a @statefull component annotation to keep all the state of a
component that relies heavily on state, like AJAXified components do ?
--
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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
