webpage instance scope?
Hi, I'm evaluating Wicket as a potential replacement for JSF and have a question (tried searching, read wiki): What is the lifespan of a WebPage / Panel subclass instance? In JSF, page-backing beans can be request/session/app scoped. I read that Wicket is an "unmanaged" framework. Does that mean the objects are request-scoped? If so, how how does one implement a session-persistent header (as Panel) + request-scoped body scenario? If this is documented in reference, please kindly point me to the specific section - I could not find anything relevant thanks -nikita -- View this message in context: http://www.nabble.com/webpage-instance-scope--tf4564224.html#a13027317 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: webpage instance scope?
pages are stored in the session (if they are statefull, that means they have callbacks) A stateless page could maybe been seen as a request scope object. there is no such thing as a combination of those 2. johan On 10/3/07, dukehoops <[EMAIL PROTECTED]> wrote: > > > Hi, > > I'm evaluating Wicket as a potential replacement for JSF and have a > question > (tried searching, read wiki): > > What is the lifespan of a WebPage / Panel subclass instance? In JSF, > page-backing beans can be request/session/app scoped. I read that Wicket > is > an "unmanaged" framework. Does that mean the objects are request-scoped? > > If so, how how does one implement a session-persistent header (as Panel) + > request-scoped body scenario? > > If this is documented in reference, please kindly point me to the specific > section - I could not find anything relevant > > thanks > -nikita > -- > View this message in context: > http://www.nabble.com/webpage-instance-scope--tf4564224.html#a13027317 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: webpage instance scope?
Sorry, I am still a bit unclear: 1.say I go to an app at localhost/MyApp/app 2.App's home page is HomePage.class; its' constructor executes 3.I do browser reload, HomePage's contructor is executed again (so I'm getting a new object and not one costructed in #2) How can I get Wicket to reuse object from #2 in step 3? thanks -nikita Johan Compagner wrote: > > pages are stored in the session (if they are statefull, that means they > have > callbacks) > > A stateless page could maybe been seen as a request scope object. > > there is no such thing as a combination of those 2. > > johan > > > > On 10/3/07, dukehoops <[EMAIL PROTECTED]> wrote: >> >> >> Hi, >> >> I'm evaluating Wicket as a potential replacement for JSF and have a >> question >> (tried searching, read wiki): >> >> What is the lifespan of a WebPage / Panel subclass instance? In JSF, >> page-backing beans can be request/session/app scoped. I read that Wicket >> is >> an "unmanaged" framework. Does that mean the objects are request-scoped? >> >> If so, how how does one implement a session-persistent header (as Panel) >> + >> request-scoped body scenario? >> >> If this is documented in reference, please kindly point me to the >> specific >> section - I could not find anything relevant >> >> thanks >> -nikita >> -- >> View this message in context: >> http://www.nabble.com/webpage-instance-scope--tf4564224.html#a13027317 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/webpage-instance-scope--tf4564224.html#a13029062 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: webpage instance scope?
> 1.say I go to an app at localhost/MyApp/app > 2.App's home page is HomePage.class; its' constructor executes > 3.I do browser reload, HomePage's contructor is executed again (so I'm > getting a new object and not one costructed in #2) Your home page is a bookmarkable page (and are thus not session relative), and bookmarkable pages are constructed for every request. Older instances will by default be pushed to second level cache. If pages are stateless, they are discarded right away and will not be part of the session store's history (we don't need that because the as state doesn't matter for these pages, we can construct them from scratch on every request, even for the back button). > How can I get Wicket to reuse object from #2 in step 3? You typically don't unless you have a very specific reason for it. But if you want, you can implement a custom page factory for instance. Though that's probably pre-mature optimization. If you navigate between pages, you can reuse instances by passing references to those pages. A typical use for that is when you have a list and a detail screen and from that detail screen you want to navigate 'back'. Again, if the only reason you want to do such things is efficiency, you're probably prematurely optimizing. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: webpage instance scope?
Scoping depends. RequestCycles and stateless pages are per request, Sessions are per session, Application is per Wicket filter. How pages are scoped basically depends on the session store you use, and whether they are reachable by the back button. By default, the current page is stored in the session, so that call backs (form submits, non-bookmarkable links, etc) can immediately be handled on the instance. New pages push older ones to 'second level cache', which is typically a file in a temp dir or a data store shared in a cluster (if you want to support fail over for the back button). As long as pages are in that second level store, they are reachable. Instead of using the Servlet API's scopes, it is probably more useful to think about reach-ability of your pages/ components, just like you would do with normal server-side/ desktop Java programming. Pages are reachable as long as the session stores can find them (and that is only really relevant for back button support), and components are reachable as long as you keep passing them on/ can be reached from the current page. Does that make sense? Eelco On 10/3/07, dukehoops <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm evaluating Wicket as a potential replacement for JSF and have a question > (tried searching, read wiki): > > What is the lifespan of a WebPage / Panel subclass instance? In JSF, > page-backing beans can be request/session/app scoped. I read that Wicket is > an "unmanaged" framework. Does that mean the objects are request-scoped? > > If so, how how does one implement a session-persistent header (as Panel) + > request-scoped body scenario? > > If this is documented in reference, please kindly point me to the specific > section - I could not find anything relevant > > thanks > -nikita > -- > View this message in context: > http://www.nabble.com/webpage-instance-scope--tf4564224.html#a13027317 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: webpage instance scope?
I think I understand your explanations yet I struggle to see how scenario I was describing is optimization-only. Consider these scenarios: Shopping w/o signing in. 1.I go to amazon.com and fill my shopping cart with stuff without signing in. 2.I navigate away to somewhere else and short time later (< HttpSession timeout) type in 'amazon.com' to go back. At this point I'd still expect to see my cart's content. My Home Page is a portal 1. My home page is my.yahoo.com. When I launch my browser I get authenticated via a previously-stored cookie. 2.During the course of the same browser session I can navigate away to another site and then hit CTRL+H to go to my home page again. 3.As I land on my.yahoo.com seems that I am *not* re-authenticated from a persistent cookie - instead a cookie issued in #1 is used to locate my server-side state. In both of these scenarios NOT retrieving state from steps #1 is not merely a non-optimization - but unexpected behavior. Do you agree? How would a Wicket-based app address these scenarios? If there is no out-of-the-box support for the above would something like the following be reasonable: 1. say my home page is defined by Home.java w/ mountPath of /Home. So going to app root: host/MyApp/app/ would redirect to host/MyApp/app/Home.1 2. User does something to alter state of this page -> redirected to host/MyApp/app/Home.2 3. User navigates away and returns by issuing /MyApp/app/ As it stands, seems like Wicket would: -'new' Home.java -redirect to /MyApp/app/Home.3 (not 2) But what would instead, given Home.class we'd find the latest stored instance in SessionStore. If does not exist -> create new; else redirect to that one. Thus in step 3 we'd find and redirect to /Home.2. Would that not address above scenarios? If it would, why would this not make sense as default behavior? thanks again, -nikita Eelco Hillenius wrote: > > >> How can I get Wicket to reuse object from #2 in step 3? > > You typically don't unless you have a very specific reason for it. But > if you want, you can implement a custom page factory for instance. > > > -- View this message in context: http://www.nabble.com/webpage-instance-scope--tf4564224.html#a13049622 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: webpage instance scope?
> I think I understand your explanations yet I struggle to see how scenario I > was describing is optimization-only. Consider these scenarios: > > Shopping w/o signing in. > 1.I go to amazon.com and fill my shopping cart with stuff without signing > in. > 2.I navigate away to somewhere else and short time later (< HttpSession > timeout) type in 'amazon.com' to go back. At this point I'd still expect to > see my cart's content. > > My Home Page is a portal > 1. My home page is my.yahoo.com. When I launch my browser I get > authenticated via a previously-stored cookie. > 2.During the course of the same browser session I can navigate away to > another site and then hit CTRL+H to go to my home page again. > 3.As I land on my.yahoo.com seems that I am *not* re-authenticated from a > persistent cookie - instead a cookie issued in #1 is used to locate my > server-side state. > > In both of these scenarios NOT retrieving state from steps #1 is not merely > a non-optimization - but > unexpected behavior. Do you agree? No I don't. This is where bookmarkable pages are meant for. In both cases you would use cookies, and these bookmarkable pages read the cookies to determine what's in the cart. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]