it actually is "isPageStatelessAtTimeIAmChecking" i have one idea ..if isPageStateless() is only made to cache that variable after page#onbeforerender then it will be ok. if some call is made before that then don't allow caching of that variable ,it's very easy to make this improvement... what should be returned if call is made before page#onbeforerender depends how much you want to deviate from current behvior,you can return the isPagestateless() without caching with a warning *too early to check if page is stateless* or change the return type to Boolean and return null or throw runtimexception.
On Sat, Aug 11, 2012 at 10:33 AM, Bertrand Guay-Paquet <ber...@step.polymtl.ca> wrote: > 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 > -- regards, Vineet Semwal --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
