webpage instance scope?

[dukehoops <ni...@doppelganger.com>]

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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: webpage instance scope?

[Eelco Hillenius <ee...@gmail.com>]

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 <ni...@doppelganger.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: webpage instance scope?

[Eelco Hillenius <ee...@gmail.com>]

> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: webpage instance scope?

[dukehoops <ni...@doppelganger.com>]

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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: webpage instance scope?

[Eelco Hillenius <ee...@gmail.com>]

> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: webpage instance scope?

[dukehoops <ni...@doppelganger.com>]

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 <ni...@doppelganger.com> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> 

-- 
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: webpage instance scope?

[Johan Compagner <jc...@gmail.com>]

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 <ni...@doppelganger.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>