Jesse Kuhnert wrote:
-) If your component is not going to be in a loop, and is also not
nested within a form (Ie is a IFormComponent), then you can safely use
the jwcid="<my unique id>@<component type" method for specifying an id.
your updateComponents would then look like updateComponetns="{'<my
unique id>'}".
This is not an option for reusable components. And if we follow the "0,
1 or infinity" rule, it's not an option at all, hehehe ;) Not trying to
be rude... just to make my point :P
In the demo it *is* a safe option. But demos should be "best-practices"
showcases anyway, so it needs proper ID management, too. Lazy developers
are a plague and a blessing, but in any case a good framework should
take them into account.
-) If your component IS in a loop, or is an IFormComponent, it's not
safe to use the jwcid="<id>@<type>" method because tapestry then takes
these id's and makes them different on render..The Looping makes them
id_N where N is the iteration number. Form components do the same
thing....
The safest thing to do for these is use
jwcid="@<comp type" id="ognl:my own unique id assignment/generation"
Well that's interesting. Maybe a helper bean would work too for Tapestry
4.0 apps. Too bad there's no way of globally declaring a bean. We'd
basically be redefining the Tapestry client ID allocation.
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Tacos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tacos-devel
