I have considered @AfterRender (and tried it at some point), but I may have to revisit that since it's been a while and maybe I was missing something.
... and since you asked: We are building components by tightly integrating .java, .tml, and .js, so that they can be re-used by non specialists. Due to our product requirements we typically have to heavily customize components, or roll our own integrations between Tapestry, client side JS, and JQuery (in addition to using and modifying available integrations and components, which are a great place start). We are trying to stay within the TS framework as much as possible, which causes us to use "Zone" a lot, and that means dealing with the 't:id' vs 'id' issues since we often need to pass clientId's into our JavaScript integrations, and that in turn causes us to manage our own id's. That and guessing at the custom events that Tapestry or tapestry-jquery may be using are the two sharp edges we've not been able to find satisfying solutions for. That being said, Tapestry is a fantastic framework which I wouldn't want to miss, and it provides tons of value. What I am talking about above is what we are seeing when we are pushing the boundaries of Tapestry towards more customized client-side experiences, including ones that go way beyond BeanEditor and similar components. Maybe this was a case of "too much information" ... but there you have it ;-) J On Mar 8, 2012, at 8:53 AM, Thiago H. de Paula Figueiredo wrote: > On Thu, 08 Mar 2012 13:46:47 -0300, Jochen Frey <joc...@jochenfrey.com> wrote: > >> My real concern is slightly different. It boils down to the fact that it is >> incredibly hard (if not impossible in certain situations) to determine the >> automatically generated ClientID of a component (that's embedded in the >> current component) during @SetupRender. > > Have you tried it in @AfterRender? > >> Worst of all, it really slows down adoption (or acceptance) of Tapestry with >> JavaScript specialists. > > I guess they wouldn't use Zones anyway . . . or am I wrong? (often I am). > > Maybe this is a similar scenario to what we sometimes find with > BeanEditForm/BeanEditor: they're meant to be used as scaffolding, giving nice > results for more common scenarios, not meant to be used in heavy > customization ones. > > -- > 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 --- joc...@jochenfrey.com +1.415.366.0450 @jochen_frey
