[
https://issues.apache.org/jira/browse/TAPESTRY-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529729
]
Nick Westgate commented on TAPESTRY-1662:
-----------------------------------------
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
