[ http://issues.apache.org/jira/browse/TAPESTRY-733?page=comments#action_12361793 ]
Scott Russell commented on TAPESTRY-733: ---------------------------------------- The infinite recursion would never occur, because all components in the tree are different instances from the component pool, even if some nested components are the same class as a parent component. So PageBeginRender would only be called on individual component instances in all cases. +1 for this to be fixed. I think the component hierarchy should be initialised from outermost component (ie. the page) inwards to the most deeply nested. This would seem most intuitive. > Tapestry should call listeners (such as PageBeginRenderListener) in some > predefined order > ----------------------------------------------------------------------------------------- > > Key: TAPESTRY-733 > URL: http://issues.apache.org/jira/browse/TAPESTRY-733 > Project: Tapestry > Type: Improvement > Versions: 4.0 > Environment: Tapestry 4.0-beta-11 > Reporter: Leonardo Quijano Vincenzi > > This is important in order to allow initialization of nested componentes in a > subcomponent. Right now, Tapestry uses a for-loop to iterate over all > listeners (3900+), and then executes pageBeginRender on every entry. The > order of execution is undefined, so pageBeginRender() methods can't rely on > parent component's initialization to be run. > For example if a page has an element "foo" initialized in pageBeginRender: > setFoo(new Foo()); > and a component call like this: > <span jwcid="@SomeComponent" bar="ognl:foo.bar" /> > And then SomeComponent tries to initialize "bar" in pageBeginRender" > ... > setBar(new Bar(...)); > This could throw a binding exception since there's no guarantee that Foo's > pageBeginRender has ever been called. Right now I'm using a workaround, > making my own listener interfaces and calling "nestedInit" from a master > pageBeginRender() method. I think a better option would be to guarantee that > parent components get their pageBeginRender method executed before their > child ones. > Of course, I guess some provisions should be taken to avoid infinite > recursions. Maybe Tapestry can build up a stack while calling listeners, and > check if the listener has already been called in case a component re-utilizes > one of its parent as sub-component. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
