You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Kristian Marinkovic (JIRA)" <de...@tapestry.apache.org> on 2007/10/04 12:56:50 UTC
[jira] Created: (TAPESTRY-1805) Reverse ordering/exceution of page
render phase methods (afterXXX and cleanupRender) incorrect when
short-circuiting
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
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
[jira] Commented: (TAPESTRY-1805) Reverse ordering/exceution of
page render phase methods (afterXXX and cleanupRender) incorrect when
short-circuiting
Posted by "Kristian Marinkovic (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557242#action_12557242 ]
Kristian Marinkovic commented on TAPESTRY-1805:
-----------------------------------------------
my use case: i use (or at least i'd like to:)) mixins is for enable/disable handling and user rights handling within forms
therefore i have a Editable Mixin that has a boolean parameter that shortcuts the rendering of a field and only renders/displays the value of the field (btw. because i can not determine the value of the components value parameter i have to pass the value to the Editable Mixin as well). furthermore i have a RoleWarrant Mixin that prevents rendering of page parts the users roles are not sufficient. both Mixins essentially shortcut the rendering of the components they are applied to. sometimes they both are applied to the same component
so i shortcut the rendering in Mixin.setupRender because i want to prevent the rendering. but shortcutting setupRender does not prevent calling Component.cleanupRender although expected (at least by me). because Component.setupRender has not been called and therefore has not been able to initialize its state, exceptions can occur if Component.cleanupRender relies on the state set in Component.setupRender.
for example this happens if you try to shortcut a Form component because during the cleanup event it tries to remove a service from the environment it should have set in the beginRender event. this is a very unsatisfying situation if many components from different sources are used.
i hope this example helps
> 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
> Assignee: Howard M. Lewis Ship
> 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
[jira] Commented: (TAPESTRY-1805) Reverse ordering/exceution of
page render phase methods (afterXXX and cleanupRender) incorrect when
short-circuiting
Posted by "Kristian Marinkovic (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532584 ]
Kristian Marinkovic commented on TAPESTRY-1805:
-----------------------------------------------
hi nick,
the point is why should a inverse render phase method of a nested component be called if the component has not be rendered or the corresponding render phase method has not been called.
so... why call cleanupRender if setupRender has not been called? :) if you return false on beginRender the beforeRenderRemplate won't be called either.
i don't think components should be aware of short-circuiting... makes it just harder for developers
g,
kris
p.s.
the quick solution for me was to make the cleanupRender method of the Tapestry Form component public and to create an own Form component by extending Tapestry Form. This Form component overrides cleanupRender after it checked the Environment with peek
> 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
[jira] Commented: (TAPESTRY-1805) Reverse ordering/exceution of
page render phase methods (afterXXX and cleanupRender) incorrect when
short-circuiting
Posted by "Nick Westgate (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532567 ]
Nick Westgate commented on TAPESTRY-1805:
-----------------------------------------
This behaviour is actually consistent with the render phase diagram.
The solution may be as simple as ensuring that components gracefully handle short-circuiting.
In this case Form could peek before it pops, or catch the exceptions etc.
Cheers,
Nick.
> 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
[jira] Commented: (TAPESTRY-1805) Reverse ordering/exceution of
page render phase methods (afterXXX and cleanupRender) incorrect when
short-circuiting
Posted by "Nick Westgate (JIRA)" <de...@tapestry.apache.org>.
[ 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 short-circuited.
I so wish I could dig further into this area (see TAPESTRY-1662) but my hands are tied right now.
Cheers,
Nick.
> 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
[jira] Updated: (TAPESTRY-1805) Reverse ordering/exceution of page
render phase methods (afterXXX and cleanupRender) incorrect when
short-circuiting
Posted by "Robert Zeigler (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Zeigler updated TAPESTRY-1805:
-------------------------------------
Attachment: jira1805sample.tgz
Attaching a project which illustrates this issue (also highlights the TAPESTRY-1622).
Extract the project, cd jira1805sample, then mvn jetty:run.
Go to the index page; the IndexPage has a variety of links which will load blocks with different combinations of mixins. One block doesn't skip the component to be skipped (and shouldn't, given the mixin), but is there for comparison.
The remainder will garner an exception due to Form trying to pop services off of Environment that weren't pushed there in the first place in cleanupRender.
> 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
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: jira1805sample.tgz
>
>
> 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
[jira] Updated: (TAPESTRY-1805) Reverse ordering/exceution of page
render phase methods (afterXXX and cleanupRender) incorrect when
short-circuiting
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship updated TAPESTRY-1805:
-------------------------------------------
Assignee: (was: Howard M. Lewis Ship)
> 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
> Attachments: jira1805sample.tgz
>
>
> 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
[jira] Commented: (TAPESTRY-1805) Reverse ordering/exceution of
page render phase methods (afterXXX and cleanupRender) incorrect when
short-circuiting
Posted by "Kristian Marinkovic (JIRA)" <de...@tapestry.apache.org>.
[ 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Issue Comment Edited: (TAPESTRY-1805) Reverse
ordering/exceution of page render phase methods (afterXXX and
cleanupRender) incorrect when short-circuiting
Posted by "Robert Zeigler (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596506#action_12596506 ]
ongakugainochi edited comment on TAPESTRY-1805 at 6/28/08 10:48 AM:
--------------------------------------------------------------------
Attaching a project which illustrates this issue (also highlights the TAPESTRY-1662).
Extract the project, cd jira1805sample, then mvn jetty:run.
Go to the index page; the IndexPage has a variety of links which will load blocks with different combinations of mixins. One block doesn't skip the component to be skipped (and shouldn't, given the mixin), but is there for comparison.
The remainder will garner an exception due to Form trying to pop services off of Environment that weren't pushed there in the first place in cleanupRender.
was (Author: ongakugainochi):
Attaching a project which illustrates this issue (also highlights the TAPESTRY-1622).
Extract the project, cd jira1805sample, then mvn jetty:run.
Go to the index page; the IndexPage has a variety of links which will load blocks with different combinations of mixins. One block doesn't skip the component to be skipped (and shouldn't, given the mixin), but is there for comparison.
The remainder will garner an exception due to Form trying to pop services off of Environment that weren't pushed there in the first place in cleanupRender.
> 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
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: jira1805sample.tgz
>
>
> 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
[jira] Updated: (TAPESTRY-1805) Reverse ordering/exceution of page
render phase methods (afterXXX and cleanupRender) incorrect when
short-circuiting
Posted by "Kristian Marinkovic (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Marinkovic updated TAPESTRY-1805:
------------------------------------------
Priority: Critical (was: Major)
> 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
[jira] Commented: (TAPESTRY-1805) Reverse ordering/exceution of
page render phase methods (afterXXX and cleanupRender) incorrect when
short-circuiting
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555379#action_12555379 ]
Howard M. Lewis Ship commented on TAPESTRY-1805:
------------------------------------------------
I'm glad you are making use of the mixins. I think there's a difference in the mental model between your view of mixins and how they are actually designed and implemented.
Your view resembles a nested procedure call. The actual design and implementation is event based, with fixed rules for how event notifications are propogated to the component and its mixins.
I think neither solution can solve all problems.
I'm not yet persuaded to change anything. Perhaps with some more specific examples? I think you may need to use instance variables to store flags in your Mixin to catch after events when you've short-circuitted the corresponding begin/before event.
> 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
[jira] Reopened: (TAPESTRY-1805) Reverse ordering/exceution of page
render phase methods (afterXXX and cleanupRender) incorrect when
short-circuiting
Posted by "Kristian Marinkovic (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Marinkovic reopened TAPESTRY-1805:
-------------------------------------------
please see example in previous comment
> 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
> Assignee: Howard M. Lewis Ship
> 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
[jira] Closed: (TAPESTRY-1805) Reverse ordering/exceution of page
render phase methods (afterXXX and cleanupRender) incorrect when
short-circuiting
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAPESTRY-1805.
------------------------------------------
Resolution: Invalid
Assignee: Howard M. Lewis Ship
As stated, the work around is to use your own flag variable, and implement the begin/before method and the corresponding after method.
> 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
> Assignee: Howard M. Lewis Ship
> 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
[jira] Closed: (TAP5-126) Reverse ordering/exceution of page render
phase methods (afterXXX and cleanupRender) incorrect when short-circuiting
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-126.
-------------------------------------
Resolution: Won't Fix
Assignee: Howard M. Lewis Ship
I still see this as mixins doing what they are designed and documented to do which, alas, is not quite what you want them to do.
> Reverse ordering/exceution of page render phase methods (afterXXX and cleanupRender) incorrect when short-circuiting
> --------------------------------------------------------------------------------------------------------------------
>
> Key: TAP5-126
> URL: https://issues.apache.org/jira/browse/TAP5-126
> Project: Tapestry 5
> Issue Type: Bug
> Environment: Tapestry 5.0.6-SNAPSHOT
> Reporter: Kristian Marinkovic
> Assignee: Howard M. Lewis Ship
> Priority: Critical
> Attachments: jira1805sample.tgz
>
>
> 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