|
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
|
