tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Westgate (JIRA)" <...@tapestry.apache.org>
Subject [jira] Commented: (TAPESTRY-1805) Reverse ordering/exceution of page render phase methods (afterXXX and cleanupRender) incorrect when short-circuiting
Date Fri, 05 Oct 2007 07:58:50 GMT

    [ https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532587

Nick Westgate commented on TAPESTRY-1805:

Yes, you're right in your particular case.
It's hard to wrap one's head around the event code unless you've been staring at it for 20
mins. ;-)

Still, part of my point was that Form pushes the environmentals in beginRender, but pops them
in cleanupRender.
This asymmetry means the same problem with Form would occur even if only beginRender were

I so wish I could dig further into this area (see TAPESTRY-1662) but my hands are tied right


> Reverse ordering/exceution of page render phase methods (afterXXX and cleanupRender)
incorrect when short-circuiting
> --------------------------------------------------------------------------------------------------------------------
>                 Key: TAPESTRY-1805
>                 URL: https://issues.apache.org/jira/browse/TAPESTRY-1805
>             Project: Tapestry
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.0.6
>         Environment: Tapestry 5.0.6-SNAPSHOT
>            Reporter: Kristian Marinkovic
>            Priority: Critical
> ComponentPageElementImpl is responsible for calling the render 
> phase methods of the components. It calls the setupRender method 
> on the attached Mixins then the components and then the Mixins that
> have a @MixinAfter annotation. If in this phase the setupRender of a
> Mixin returns a boolean value that will be saved into the Event object and
> in case of a "false" the setupRender calls of the subsequent components 
> will be aborted. 
> During the "inverse" lifecycle the order is simply reversed and the render
> phase method of the Mixin with @MixinAfter annotation is called, then
> the render phase method of the component and then the method of the
> Mixin is called. The problem is now that the "inverse" render phase 
> methods are getting called without checking whether the corresponding 
> other render phase methods have been executed. 
> So in my case the cleanupRender method of the Form component gets
> called although i have short-circuited the beginRender method with my 
> Mixin because there is no state available that indicates that the beginRender
> method of the Form component has NOT been executed.
> private void invoke(boolean reverse, ComponentCallback callback)
> {
>            ....
>             Iterator<Component> i = reverse ? 
> InternalUtils.reverseIterator(_components)
>                     : _components.iterator();
>             while (i.hasNext())
>                 callback.run(i.next());
> A possible solution would be to create a List that contains those 
> components whose render phase methods really have been 
> executed. This list is then used in the "inverse" lifecycle.
> see also:
> http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562001.html
> http://www.nabble.com/T5%3A-Mixin-on-Form-does-not-work-as-expected-tf4562724.html

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

View raw message