Isn't the tree visitor pattern used now in T4 to intialize the parameter bindings on the page's component tree? I'm nowhere near the code so I can't check.
If this is the case then it should be possible to use the same mechanism to call listeners. Geoff On 3/11/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > I don't personally have a problem with it, but I don't remember enough about > AbstractPage to have a very good opinion ;) > > I have a problem with the current behaviour of a couple things in general, > but don't want to invest too much intellectual capitol into solutions until > I see more of what Howard has coming. (at least for these core-ish things) > If there's a way to fix it now that doesn't hurt performance or anything > else then why not right? > > On 3/11/06, Mind Bridge <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > As it has been discussed on the user list and in JIRA issue > > *TAPESTRY-733 <http://issues.apache.org/jira/browse/TAPESTRY-733>*, the > > order of pageBeginRender invocations often needs to be in the order of > > the page first, to the inner most components last. At the moment the > > order is undefined. > > > > Since the listeners are currently invoked in the order in which they are > > added, they are added in the finishLoad() methods, they are therefore > > invoked in precisely the opposite order -- inner-most components first > > and page last. > > > > One simple modification would be to change AbstractPage, so that the > > listeners are invoked in the opposite order in which they are added. > > This small change would take care of *TAPESTRY-733 > > <http://issues.apache.org/jira/browse/TAPESTRY-733>* and a number of > > other issues. Does anyone see a problem with this approach? > > > > The long time solution would of course be to abstract the whole listener > > logic into a HiveMind service, and perhaps declare the order of > > invocation in its configuration. But the above modification can happen > > immediately with multiple positive effects. > > > > - mb > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- The Spindle guy. http://spindle.sf.net Get help with Spindle: http://lists.sourceforge.net/mailman/listinfo/spindle-user Blog: http://jroller.com/page/glongman Feature Updates: http://spindle.sf.net/updates --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
