Order of invoking listeners (such as pageBeginRender) in AbstractPage

[Mind Bridge <mi...@yahoo.com>]

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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

Re: Order of invoking listeners (such as pageBeginRender) in AbstractPage

[Geoff Longman <gl...@gmail.com>]

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 <jk...@gmail.com> 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 <mi...@yahoo.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>


--
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

Re: Order of invoking listeners (such as pageBeginRender) in AbstractPage

[Jesse Kuhnert <jk...@gmail.com>]

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 <mi...@yahoo.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>