You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Bill Holloway <bi...@peoplepad.com> on 2008/08/15 01:42:15 UTC
Re: T5.0.14: Parent before child clarification
Back to this one again! I have two components. One inherits from
Grid; the other, GridRows. My GridRows subclass has a setupRender and
beginRender.
If either one has arguments (MarkupWriter w, Event e), I get a
java.lang.AbstractMethodError with the stack trace listed at the
bottom of this message (although line numbers are different in classes
followed by $, as you can imagine). But interestingly, my subclass
beginRender is never called, under any circumstances even though it
causes the exception with the prior arguments! If I give setupRender
just a MarkupWriter as an argument, it is properly called.
Could the lack of a call into my subclass' beginRender be due to the
fact that GridRows' beginRender returns a boolean?
This all started, BTW, after my 5.0.13 upgrade :) I sure do need my
subclass' beginRender invoked.
Other ideas?
Stacktrace:
* org.apache.tapestry5.internal.structure.ComponentPageElementImpl$11$1.run(ComponentPageElementImpl.java:334)
* org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:899)
* org.apache.tapestry5.internal.structure.ComponentPageElementImpl.access$200(ComponentPageElementImpl.java:50)
* org.apache.tapestry5.internal.structure.ComponentPageElementImpl$11.render(ComponentPageElementImpl.java:338)
* org.apache.tapestry5.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:68)
* org.apache.tapestry5.internal.services.PageRenderQueueImpl.render(PageRenderQueueImpl.java:108)
* org.apache.tapestry5.services.TapestryModule$15.renderMarkup(TapestryModule.java:1128)
* org.apache.tapestry5.services.TapestryModule$24.renderMarkup(TapestryModule.java:1472)
* org.apache.tapestry5.services.TapestryModule$23.renderMarkup(TapestryModule.java:1453)
* org.apache.tapestry5.services.TapestryModule$22.renderMarkup(TapestryModule.java:1435)
* org.apache.tapestry5.services.TapestryModule$21.renderMarkup(TapestryModule.java:1415)
* org.apache.tapestry5.internal.services.PageMarkupRendererImpl.renderPageMarkup(PageMarkupRendererImpl.java:64)
* org.apache.tapestry5.internal.services.PageResponseRendererImpl.renderPageResponse(PageResponseRendererImpl.java:57)
* org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:59)
* org.apache.tapestry5.services.TapestryModule$29.handle(TapestryModule.java:1653)
* org.apache.tapestry5.internal.services.PageRenderDispatcher.process(PageRenderDispatcher.java:97)
* org.apache.tapestry5.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:73)
* org.apache.tapestry5.services.TapestryModule$13.service(TapestryModule.java:953)
* org.apache.tapestry5.internal.services.LocalizationFilter.service(LocalizationFilter.java:42)
* org.apache.tapestry5.services.TapestryModule$2.service(TapestryModule.java:586)
* org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
* org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:79)
* org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:93)
* org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:84)
* org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:83)
* org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:106)
* org.apache.tapestry5.services.TapestryModule$12.service(TapestryModule.java:933)
* org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:44)
* org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
* org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:177)
* org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
* org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
* org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
* org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
* org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
* org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
* org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
* org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
* org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
* org.mortbay.jetty.Server.handle(Server.java:313)
* org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
* org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830)
* org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
* org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
* org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
* org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
* org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
On Mon, Jun 23, 2008 at 8:04 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> So the sub-class setupRender() overrides the base-class setupRender()?
>
> The method setupRender() is still invoked at the appropriate time. The
> difference is that it is not invoked twice, as it was before 5.0.13.
>
> In coding terms, what happens is that Tapestry provides an
> implementation of the method void setupRender(MarkupWriter writer,
> Event event) in the base class that invokes the base class'
> setupRender() method.
>
> The sub class also gets an implementation of void
> setupRender(MarkupWriter writer, Event event) ... the first thing it
> does is invoke the super implementation.
>
> In 5.0.11 and earlier, the subclass implementation of setupRender(...)
> would invoke the subclass' override of setupRender(). Thus, the base
> class would invoke it once, then the subclass would invoke it again.
>
> In 5.0.13 this was changed so that the subclass implementation of
> setupRender(...) would *NOT* invoke the setupRender() method; because
> setupRender() overrides a base class method; the base class is
> responsible for invoking it. This is what that documentation is
> referring to when it mentions the "timing" of the method invocation.
>
> Thus if you want the base classes' implementation to be invoked, the
> method override must call super.setupRender().
>
> Hope this is a bit clearer.
>
> Then end result is that overriding render phase methods should now fit
> better, conceptually, with how method overrides work in ordinary Java,
> which is a good thing.
>
>
> On Fri, Jun 20, 2008 at 5:55 PM, Bill Holloway <bi...@peoplepad.com> wrote:
>> The JIRA on this states that the "overridden method will be invoked
>> only by the parent class, not the subclass." So I have a page that
>> inherits from a base page class. Both have setupRender() on them. I
>> have no code in the parent class that actually invokes setupRender,
>> but I hope it will be invoked. Will it?
>>
>> --
>> Bill @ PeoplePad
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Bill @ PeoplePad
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14: Parent before child clarification
Posted by Bill Holloway <bi...@peoplepad.com>.
Actually, I found that I can do what I need to do in beforeRenderTemplate.
Bill
On Thu, Aug 14, 2008 at 6:42 PM, Bill Holloway <bi...@peoplepad.com> wrote:
> Back to this one again! I have two components. One inherits from
> Grid; the other, GridRows. My GridRows subclass has a setupRender and
> beginRender.
>
> If either one has arguments (MarkupWriter w, Event e), I get a
> java.lang.AbstractMethodError with the stack trace listed at the
> bottom of this message (although line numbers are different in classes
> followed by $, as you can imagine). But interestingly, my subclass
> beginRender is never called, under any circumstances even though it
> causes the exception with the prior arguments! If I give setupRender
> just a MarkupWriter as an argument, it is properly called.
>
> Could the lack of a call into my subclass' beginRender be due to the
> fact that GridRows' beginRender returns a boolean?
>
> This all started, BTW, after my 5.0.13 upgrade :) I sure do need my
> subclass' beginRender invoked.
>
> Other ideas?
>
> Stacktrace:
>
> * org.apache.tapestry5.internal.structure.ComponentPageElementImpl$11$1.run(ComponentPageElementImpl.java:334)
> * org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:899)
> * org.apache.tapestry5.internal.structure.ComponentPageElementImpl.access$200(ComponentPageElementImpl.java:50)
> * org.apache.tapestry5.internal.structure.ComponentPageElementImpl$11.render(ComponentPageElementImpl.java:338)
> * org.apache.tapestry5.internal.services.RenderQueueImpl.run(RenderQueueImpl.java:68)
> * org.apache.tapestry5.internal.services.PageRenderQueueImpl.render(PageRenderQueueImpl.java:108)
> * org.apache.tapestry5.services.TapestryModule$15.renderMarkup(TapestryModule.java:1128)
> * org.apache.tapestry5.services.TapestryModule$24.renderMarkup(TapestryModule.java:1472)
> * org.apache.tapestry5.services.TapestryModule$23.renderMarkup(TapestryModule.java:1453)
> * org.apache.tapestry5.services.TapestryModule$22.renderMarkup(TapestryModule.java:1435)
> * org.apache.tapestry5.services.TapestryModule$21.renderMarkup(TapestryModule.java:1415)
> * org.apache.tapestry5.internal.services.PageMarkupRendererImpl.renderPageMarkup(PageMarkupRendererImpl.java:64)
> * org.apache.tapestry5.internal.services.PageResponseRendererImpl.renderPageResponse(PageResponseRendererImpl.java:57)
> * org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:59)
> * org.apache.tapestry5.services.TapestryModule$29.handle(TapestryModule.java:1653)
> * org.apache.tapestry5.internal.services.PageRenderDispatcher.process(PageRenderDispatcher.java:97)
> * org.apache.tapestry5.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:73)
> * org.apache.tapestry5.services.TapestryModule$13.service(TapestryModule.java:953)
> * org.apache.tapestry5.internal.services.LocalizationFilter.service(LocalizationFilter.java:42)
> * org.apache.tapestry5.services.TapestryModule$2.service(TapestryModule.java:586)
> * org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
> * org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:79)
> * org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:93)
> * org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:84)
> * org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:83)
> * org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:106)
> * org.apache.tapestry5.services.TapestryModule$12.service(TapestryModule.java:933)
> * org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:44)
> * org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
> * org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:177)
> * org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
> * org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
> * org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> * org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> * org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
> * org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> * org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
> * org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> * org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> * org.mortbay.jetty.Server.handle(Server.java:313)
> * org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
> * org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830)
> * org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
> * org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> * org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
> * org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
> * org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
>
> On Mon, Jun 23, 2008 at 8:04 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> So the sub-class setupRender() overrides the base-class setupRender()?
>>
>> The method setupRender() is still invoked at the appropriate time. The
>> difference is that it is not invoked twice, as it was before 5.0.13.
>>
>> In coding terms, what happens is that Tapestry provides an
>> implementation of the method void setupRender(MarkupWriter writer,
>> Event event) in the base class that invokes the base class'
>> setupRender() method.
>>
>> The sub class also gets an implementation of void
>> setupRender(MarkupWriter writer, Event event) ... the first thing it
>> does is invoke the super implementation.
>>
>> In 5.0.11 and earlier, the subclass implementation of setupRender(...)
>> would invoke the subclass' override of setupRender(). Thus, the base
>> class would invoke it once, then the subclass would invoke it again.
>>
>> In 5.0.13 this was changed so that the subclass implementation of
>> setupRender(...) would *NOT* invoke the setupRender() method; because
>> setupRender() overrides a base class method; the base class is
>> responsible for invoking it. This is what that documentation is
>> referring to when it mentions the "timing" of the method invocation.
>>
>> Thus if you want the base classes' implementation to be invoked, the
>> method override must call super.setupRender().
>>
>> Hope this is a bit clearer.
>>
>> Then end result is that overriding render phase methods should now fit
>> better, conceptually, with how method overrides work in ordinary Java,
>> which is a good thing.
>>
>>
>> On Fri, Jun 20, 2008 at 5:55 PM, Bill Holloway <bi...@peoplepad.com> wrote:
>>> The JIRA on this states that the "overridden method will be invoked
>>> only by the parent class, not the subclass." So I have a page that
>>> inherits from a base page class. Both have setupRender() on them. I
>>> have no code in the parent class that actually invokes setupRender,
>>> but I hope it will be invoked. Will it?
>>>
>>> --
>>> Bill @ PeoplePad
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Bill @ PeoplePad
>
--
Bill @ PeoplePad
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org