I dont know, if somebody of you is reading [EMAIL PROTECTED] Craig mailed there to a topic "Basic workflow engine"
he said: "So far, I'm developing some ideas and design patterns around state information that is saved longer than a request, but shorter than a session -- and gracefully managing the associated pages and corresponding view controllers. It's not quite ready for the rest of the world to look at yet, but will be soon." I guess it will be integrated into Shale. here is the link to the topic (which I am currently reading): http://tinyurl.com/63zac HTH, Matthias -----Original Message----- From: Travis Reeder [mailto:[EMAIL PROTECTED] Sent: Friday, December 31, 2004 2:29 AM To: MyFaces Discussion Subject: Re: New Scope 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 From: Travis Reeder [mailto:[EMAIL PROTECTED] Sent: Thursday, December 30, 2004 9:21 AM To: MyFaces Discussion Subject: Re: New Scope 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
