[
https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532602
]
Kristian Marinkovic commented on TAPESTRY-1805:
-----------------------------------------------
https://issues.apache.org/jira/browse/TAPESTRY-1662 is quite similar :)
do you know how howard perceives this bugs? do you think there we'll be a
solution soon? I use Mixins a lot
for enable/disable handling and for short-circuiting of render phases (that
makes the use of if components almost unnecessary) and page
decoration/enhancement (HTML, JS). for me it is important to have them
integrate into the rendering phases correctly. a great way to achieve
separation of concerns.
summary of how i think t5 event handling should work:
as you mentioned in your bug and as it is documented a short-circuit will omit
the inner render phase methods.
if a component has a mixin attached the component render phase methods become
the inner render phase methods of my mixin. therefore a mixin short-circuit
will omit the components render phase methods.. even the inverse one ... and
the other way round if you have MixinAfter :)
g,
kris
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
