It probably wouldn't know whether the window was closed or not, but you
could just hold onto it for the length of the session. The
implementation could probably just stuff another map into the session
map for each window.
Travis
Korhonen, Kalle wrote:
Good point, but it could be
viewed to behave as designed. It'd still be a request scoped object
with an extended lifetime. If you wanted the object to be kept alive on
another page, you'd need to put the keepAlive with the same id on that
other page. Yeah, I know it's not a let-framework-handle-it type of a
solution like a new window scope, but it would put more burden on the
developer to manage the lifetime of objects. However, I can see
problems with the proposed window scope - like how would the framework
know when the window is closed and the objects should be removed?
Kalle
Your suggestion still would not work though if the user has two windows
open since if the user opens a new window to surf somewhere else, your
component state will be lost since:
"Thus if a component with the same x:saveState id would
exist on a subsequent page, the component would be "kept alive"."
So if they went to a different page in a different window, then went back to the first window, the component state would have already been thrown out.
Travis
Korhonen, Kalle wrote:
Just a quick comment, since I've been thinking about the same thing but
from a bit different perspective. x:saveState works well for saving the
state of request scoped object, but when a reference to the object is
put into session (server-side), it'll stay there till the session
expires if not explicitly nullified. Thus, I was thinking of
implementing a x:keepAlive component (name not important, could be
implemented as an attribute of existing saveState), which would also
register to listen to JSF lifecycle. It would listen to some state in
the request lifecycle and look up if a component with the same id would
exist in the component tree and if not, remove itself (or its data) from
the session. Thus if a component with the same x:saveState id would
exist on a subsequent page, the component would be "kept alive". I
haven't had time to try to implement it yet, but in principle it should
work for server side state saving. It might be a little harder to
implement with a client side state saving, as you would need to
explicitly prevent deserialization of the object - well... I guess the
easiest would be if you would only conditionally deserialize the content
of the object, but hard part is to know when it should be serialized and
when not. Anyway, this way we wouldn't need another scope, but we could
just extend the lifetime of request scoped object a bit. I'll try
implementing it at some point, if no one hasn't done this or gets there
before me.
Kalle
-----Original Message-----
From: Travis Reeder [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 28, 2004 5:15 PM
To: MyFaces Discussion
Subject: New Scope
What do you guys think of this?
http://www.crack3r.com/2004/12/another-scope-for-web-app-param
eters.html
--
Travis Reeder
Ecommstats Web Analytics
www.ecommstats.com
--
Travis Reeder
Ecommstats Web Analytics
www.ecommstats.com
--
Travis Reeder
Ecommstats Web Analytics
www.ecommstats.com
|
