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]
