>> Zone with an id generated randomly(ajax request) is useless > > It isn't (I've explained it in this thread: > http://www.mail-archive.com/[email protected]/msg57958.html), > otherwise Tapestry committers wouldn't care to implement.
You have only explained why there are random ids, I'm not saying there are bad just in this case a zone with a random id is useless. There is only one way how to use random id zone is to extract its id after rendering and honestly I don't think is the right way. Most developers will not understand why a zone inside a zone doesn't work without knowing all nuances, some kind of warning or even error which will tell to provide explicit id whould be nice. On 27.1.2012, at 13:32, Thiago H. de Paula Figueiredo wrote: > On Fri, 27 Jan 2012 03:22:58 -0200, Paul Stanton <[email protected]> wrote: > >> Just a side note, this has caught a few users over time (since t5.1). >> >> Boris' expected behaviour does not seem to me to be too unrealistic an >> expectation! Depending on your personality type ;) you may even consider >> this a bug. >> >> Maybe the zone re-rendering process should handle this client id changeover >> gracefully? > > The non-developer-provided ids change because otherwise the page could have > different elements with the same id after a zone update. Automating the > EventLinks (and ActionLinks) to point at new ids is quite hard: Tapestry > would need to keep a server-side map of which link points to each zone, > figure out which ids changed and then send a (EventLink, new target id) > change them after a zone update. This would probably need to rewrite all > JavaScript code related to zones. You can avoid this by providing client-side > ids to Zones, so I don't think this whole change is worth. > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and > instructor > Owner, Ars Machina Tecnologia da Informação Ltda. > http://www.arsmachina.com.br > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
