But i am just curious if i could move page.internalDetach() to go much earlier..
for example in the page.renderPage() where also internalAttach() is called.
I guess then it will sometimes be called twice.. ( RequestTarget.detach()) and in page.renderPage()
because both have to do it.. else the event handling page (that is not the response page) is not detached.
johan
On 8/10/06,
Eelco Hillenius <[EMAIL PROTECTED]> wrote:
---------- Forwarded message ----------
From: Jonathan Locke <[EMAIL PROTECTED]>
Date: Aug 10, 2006 1:01 PM
Subject: Re: [Wicket-develop] Page.internalAttach () or better said
detachModels() problem
To: Eelco Hillenius <[EMAIL PROTECTED]>
don't know. my only thought about these methods in general is
that i like the After/Before naming convention because it is very clear.
something like onBeforeInternalDetach() is very self explanatory
or onAfterAttach(). etc... i would have to go read the code again in
detail to have thoughts on this again. ;-)
jon
On Aug 10, 2006, at 12:06 PM, Eelco Hillenius wrote:
> Jonathan, I believe you implemented that part. Any thoughts?
>
> Eelco
>
>
> ---------- Forwarded message ----------
> From: Johan Compagner <[EMAIL PROTECTED]>
> Date: Aug 10, 2006 6:33 AM
> Subject: [Wicket-develop] Page.internalAttach() or better said
> detachModels() problem
> To: wicket-develop@lists.sourceforge.net
>
>
> Why are the above methods called so late?
>
> only the:
>
> public void detach(RequestCycle requestCycle)
> {
> if (page != null)
> {
> page.internalDetach();
> }
> }
>
> of a RequestTarget does it.
> But before that we do session.touch(page)
> and with a second level cache. We will save that page then. We now do
> there quickly:
>
> // TODO check can this be called everytime at this place?
> Putting should
> // be called after the rendering so it should be ok.
> page.detachModels();
>
> (and this call is now changed to page.internalDetach())
>
> but this brings the question why arent we do this earlier?
>
> Why does page.renderPage() an internalAttach() call but not at the and
> internalDetach()?
> I know we still have to do it in the request cycle because it can be a
> RequestTarget that is only used for handling the event.
> And not processing the response (so the page is not rendered)
> Can't we streamline this a bit more?
>
> What we also could do is call session.touch() in the
> page.internalDetach()
> but don't know what the result of that would be for that because then
> touch can be called on a event page not a response page.
> But i guess this should be done anyway because if the event page is
> called on and some changed then we don't record this.
> because it isn't touched?
>
> johan
>
>
> ----------------------------------------------------------------------
> ---
> Using Tomcat but need to do more? Need to support web services,
> security?
> Get stuff done quickly with pre-integrated technology to make your
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Wicket-develop mailing list
> Wicket-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
