You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Nick Westgate (JIRA)" <de...@tapestry.apache.org> on 2007/09/23 05:31:50 UTC
[jira] Issue Comment Edited: (TAPESTRY-1662) Render phase
short-circuiting is not implemented for methods of the same phase.
[ https://issues.apache.org/jira/browse/TAPESTRY-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529729 ]
sicklittlemonkey edited comment on TAPESTRY-1662 at 9/22/07 8:31 PM:
------------------------------------------------------------------
Sorry, I should have given an example, but at the time I thought the bu was pretty clear.
Here's what I posted about it to the dev list over 2 months ago:
Subject: T5: Clarification on render phase component/mixin conflict behaviour
Newsgroups: gmane.comp.jakarta.tapestry.devel
http://article.gmane.org/gmane.comp.jakarta.tapestry.devel/20864/
Date: 2007-07-20 10:22:32 GMT (9 weeks, 1 day, 16 hours and 28 minutes ago)
Hi.
The component rendering guide suggests ordering and short-circuiting
should prevent components and mixins using the same render phase from
crossing swords, so to speak.
Basically I've got a case where this doesn't seem to work out:
AbstractField has a @Mixin DiscardBody.
@Mixin DiscardBody returns false for beforeRenderBody().
(Note that @Mixin DiscardBody has a @MixinAfter.)
My component derives from AbstractField.
My component returns true for beforeRenderBody().
According to the docs I expect my component to short-circuit the
phase and prevent DiscardBody's beforeRenderBody() from being invoked,
but instead an exception is thrown. (Full stack trace appended below.)
My expectation seems reasonable, especially considering the comment
before the exception raising code, but which is correct? ;-)
// Given that this method is *only* invoked from code
// that is generated at runtime and proven to be correct,
// this should never, ever happen. But what the hell,
// let's check anyway.
Cheers,
Nick.
java.lang.IllegalStateException
Can not store result from invoking method org.apache.tapestry.corelib.
mixins.DiscardBody.beforeRenderBody() (at DiscardBody.java:31), because
an event result value has already been obtained from some other event
handler method.
Stack trace
* org.apache.tapestry.internal.services.EventImpl.storeResult(EventImpl.java:58)
* org.apache.tapestry.corelib.mixins.DiscardBody.beforeRenderBody(DiscardBody.java)
* org.apache.tapestry.internal.structure.ComponentPageElementImpl$8$1.run(ComponentPageElementImpl.java:283)
* org.apache.tapestry.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:931)
* org.apache.tapestry.internal.structure.ComponentPageElementImpl.access$100(ComponentPageElementImpl.java:69)
* org.apache.tapestry.internal.structure.ComponentPageElementImpl$8.render(ComponentPageElementImpl.java:287)
* org.apache.tapestry.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:57)
* org.apache.tapestry.internal.services.PageMarkupRendererImpl.renderPageMarkup(PageMarkupRendererImpl.java:40)
* org.apache.tapestry.internal.services.PageResponseRendererImpl.renderPageResponse(PageResponseRendererImpl.java:71)
* org.apache.tapestry.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:81)
* org.apache.tapestry.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:72)
* org.apache.tapestry.services.TapestryModule$12.service(TapestryModule.java:1066)
* jp.co.key_planning.kzoku.tapestry.services.AppModule$4.service(AppModule.java:211)
* jp.co.key_planning.kzoku.tapestry.services.AppModule$6.service(AppModule.java:274)
* org.apache.tapestry.internal.services.LocalizationFilter.service(LocalizationFilter.java:43)
* org.apache.tapestry.services.TapestryModule$2.service(TapestryModule.java:657)
* org.apache.tapestry.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:63)
* org.apache.tapestry.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:97)
* org.apache.tapestry.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:88)
* org.apache.tapestry.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:77)
* org.apache.tapestry.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:110)
* org.apache.tapestry.services.TapestryModule$11.service(TapestryModule.java:1044)
* org.apache.tapestry.TapestryFilter.doFilter(TapestryFilter.java:135)
* org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
* org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
* org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
* org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
* org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
* org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
* org.mortbay.http.HttpServer.service(HttpServer.java:909)
* org.mortbay.http.HttpConnection.service(HttpConnection.java:820)
* org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986)
* org.mortbay.http.HttpConnection.handle(HttpConnection.java:837)
* org.mortbay.http.SocketListener.handleConnection(SocketListener.java:245)
* org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
* org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
was (Author: sicklittlemonkey):
Sorry, I should have given an example, but at the time
Here's what I posted about it to the dev list over 2 months ago:
Subject: T5: Clarification on render phase component/mixin conflict behaviour
Newsgroups: gmane.comp.jakarta.tapestry.devel
http://article.gmane.org/gmane.comp.jakarta.tapestry.devel/20864/
Date: 2007-07-20 10:22:32 GMT (9 weeks, 1 day, 16 hours and 28 minutes ago)
Hi.
The component rendering guide suggests ordering and short-circuiting
should prevent components and mixins using the same render phase from
crossing swords, so to speak.
Basically I've got a case where this doesn't seem to work out:
AbstractField has a @Mixin DiscardBody.
@Mixin DiscardBody returns false for beforeRenderBody().
(Note that @Mixin DiscardBody has a @MixinAfter.)
My component derives from AbstractField.
My component returns true for beforeRenderBody().
According to the docs I expect my component to short-circuit the
phase and prevent DiscardBody's beforeRenderBody() from being invoked,
but instead an exception is thrown. (Full stack trace appended below.)
My expectation seems reasonable, especially considering the comment
before the exception raising code, but which is correct? ;-)
// Given that this method is *only* invoked from code
// that is generated at runtime and proven to be correct,
// this should never, ever happen. But what the hell,
// let's check anyway.
Cheers,
Nick.
java.lang.IllegalStateException
Can not store result from invoking method org.apache.tapestry.corelib.
mixins.DiscardBody.beforeRenderBody() (at DiscardBody.java:31), because
an event result value has already been obtained from some other event
handler method.
Stack trace
* org.apache.tapestry.internal.services.EventImpl.storeResult(EventImpl.java:58)
* org.apache.tapestry.corelib.mixins.DiscardBody.beforeRenderBody(DiscardBody.java)
* org.apache.tapestry.internal.structure.ComponentPageElementImpl$8$1.run(ComponentPageElementImpl.java:283)
* org.apache.tapestry.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:931)
* org.apache.tapestry.internal.structure.ComponentPageElementImpl.access$100(ComponentPageElementImpl.java:69)
* org.apache.tapestry.internal.structure.ComponentPageElementImpl$8.render(ComponentPageElementImpl.java:287)
* org.apache.tapestry.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:57)
* org.apache.tapestry.internal.services.PageMarkupRendererImpl.renderPageMarkup(PageMarkupRendererImpl.java:40)
* org.apache.tapestry.internal.services.PageResponseRendererImpl.renderPageResponse(PageResponseRendererImpl.java:71)
* org.apache.tapestry.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:81)
* org.apache.tapestry.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:72)
* org.apache.tapestry.services.TapestryModule$12.service(TapestryModule.java:1066)
* jp.co.key_planning.kzoku.tapestry.services.AppModule$4.service(AppModule.java:211)
* jp.co.key_planning.kzoku.tapestry.services.AppModule$6.service(AppModule.java:274)
* org.apache.tapestry.internal.services.LocalizationFilter.service(LocalizationFilter.java:43)
* org.apache.tapestry.services.TapestryModule$2.service(TapestryModule.java:657)
* org.apache.tapestry.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:63)
* org.apache.tapestry.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:97)
* org.apache.tapestry.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:88)
* org.apache.tapestry.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:77)
* org.apache.tapestry.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:110)
* org.apache.tapestry.services.TapestryModule$11.service(TapestryModule.java:1044)
* org.apache.tapestry.TapestryFilter.doFilter(TapestryFilter.java:135)
* org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
* org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
* org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
* org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
* org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
* org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
* org.mortbay.http.HttpServer.service(HttpServer.java:909)
* org.mortbay.http.HttpConnection.service(HttpConnection.java:820)
* org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:986)
* org.mortbay.http.HttpConnection.handle(HttpConnection.java:837)
* org.mortbay.http.SocketListener.handleConnection(SocketListener.java:245)
* org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
* org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> Render phase short-circuiting is not implemented for methods of the same phase.
> -------------------------------------------------------------------------------
>
> Key: TAPESTRY-1662
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1662
> Project: Tapestry
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.0.5
> Reporter: Nick Westgate
> Priority: Critical
>
> According to the docs on render phase short-circuiting for methods of the same phase:
> http://tapestry.apache.org/tapestry5/tapestry-core/guide/rendering.html
> "If a method returns a true or false value, this will short circuit processing.
> Other methods within the phase that would ordinarily be invoked will not be invoked."
> This is currently unimplemented. (Only other "inner" phases are short-circuited & not invoked.)
> Changes would primarily affect:
> org.apache.tapestry.internal.structure.ComponentCallback
> org.apache.tapestry.internal.structure.ComponentPageElementImpl
> In ComponentPageElementImpl.invoke(...), the loop:
> while (i.hasNext())
> callback.run(i.next());
> needs to implement the short circuiting, for example:
> while (i.hasNext())
> if (callback.run(i.next()))
> break;
> This change would cascade up to ComponentCallback and all its usage in ComponentPageElementImpl.
> Cheers,
> Nick.
--
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