This is weird, I never received Martin's email! I managed to see it in
your first reply Vineet... I also lost a few hours' worth of mailing
list emails.
Removing the caching in isPageStateless() would indeed make sure that
the code in WebPageRenderer would not get the wrong value. However, all
the calls made to isPageStateless() before that point could still get
the wrong value returned, depending on the page. In that case, it seems
kind of pointless to rely on isPageStateless() for anything at all
before rendering (or at least onBeforeRender) occurs.
I had a deeper look at callers of isPageStateless() in Wicket's source
and found two possible causes of concern:
WebPageRenderer#respond(RequestCycle) and
ListenerInterfaceRequestHandler#respond(RequestCycle). I'll need to
examine in them in more details.
To be continued...
On 10/08/2012 6:33 PM, vineet semwal wrote:
you are right onconfigure is executed once before rendering .
actually isPageStateless() can be broken easily as that variable can
be populated before the page#onbeforerender is completed ie. say if
some component in onbeforerender uses ispagestateless() then the
variable will be set prematurely
now i see martin-g is correct the solution is to just remove the
caching but the problem can be that method is used in a lot of places
and can be called many times foreg. it's used inside urlFor in
Component which means link will at least call this method once in
getUrl and if you have a repeater of 20 links this is 20 X
isPageStateless() ,it actually depends on how expensive
ispagestateless() itself is and at how many places is it used ..
On Fri, Aug 10, 2012 at 10:53 PM, Bertrand Guay-Paquet
<ber...@step.polymtl.ca> wrote:
On 10/08/2012 12:12 PM, vineet semwal wrote:
it might give you wrong result even if you add your component after
adding all the components because some components foreg. a repeater
like listview/dataview/gridview add children in onbeforerender so
isPageStateless() can be assumed to work correctly only after
onbeforerender
Yes that's exactly what I wanted to say! The repeaters are only populated in
their onBeforeRender() which is executed after onConfigure().
that caching part is ok imho for isPageStateless() ,actually that
cached variable is reset in page#onbeforerender which is the another
reason isPageStateless() should work correctly after onbeforerender
I hadn't noticed that reset in Page#onBeforeRender() so I had a look since
it would contradict my observations.
This is the stack trace when my label's onConfigure() is reached :
TmpPage$1.onConfigure() line: 24 <-- my stateless indicator label; calls
isPageStateless()
TmpPage$1(Component).configure() line: 1028
TmpPage$1(Component).internalBeforeRender() line: 913
TmpPage$1(Component).beforeRender() line: 990
TmpPage(MarkupContainer).onBeforeRenderChildren() line: 1688
TmpPage(Component).onBeforeRender() line: 3830
TmpPage(Page).onBeforeRender() line: 802 <--- line 799 already did the
reset of the cached "stateless" var
TmpPage(Component).internalBeforeRender() line: 922
TmpPage(Component).beforeRender() line: 990
TmpPage(Component).internalPrepareForRender(boolean) line: 2204
TmpPage(Page).internalPrepareForRender(boolean) line: 247
TmpPage(Component).render() line: 2289
TmpPage(Page).renderPage() line: 1021
This stack trace occurs before the repeating view is populated which would
render the page stateful and causes the Page to cache that it is stateless.
By the way, I did find a workaround to achieve the desired effect so that's
not why I brought this up here. I'm just concerned that such erroneous
computations of the page's stateless state might cause other bugs down the
road.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
