Craig McClanahan schrieb: > On 6/28/07, Werner Punz <[EMAIL PROTECTED]> wrote: >> Hi everybody, I am just digging through the shale dialog codebase. >> Maybe I am missing something here, but I cannot see following usecase >> covered. >> A User is in a dialog and exits the dialog by altering the url... >> Now what happens then? >> I cannot see any codepart of where the dialog then is dropped >> and an event is issued to its referencing dialogcontext listeners. >> > > At least for the "basic" implementation (probably the SCXML one as > well), you're correct ... the identifier for the current dialog > context is saved and restored as part of the JSF component tree state, > which gets lost if you manually alter the URL in the browser (and > therefore cause a new component tree to be created). > >> Am I missing something here or is this a bug? > > It's definitely a non-covered use case :-), so please do file an > issue. Figuring out what to do about it will be kind of interesting > ... for example, you can't just assume that a request (in the same > session) that doesn't include a JSF component tree (with the context > identifier) means that all existing dialog contexts should be > terminated ... that would have nasty consequences for things link > stylesheet and Javascript links. > I will tonight, sorry for being a little bit late on this, as for the losing the state thing.
The best solution probably is to have some kind of garbage collecting cleanup task which issues the relevant commands to shale periodically if not having been accessed for a certain period of time. (Probably 5-10 minutes) That way a back button should trigger correctly if not done very late. And you do not run into some resource loading or ajax killing off the conversation problems. Of course the downside of this is that you might run into a page timeout issue that way. Well that could be again resolved by adding an ajax conversation refresh code to a page under conversation which is intercepted by a phase listener upfront which only renews the access time, if you do not want to live with page/conversation timeouts. I agree simply dropping it by running into a page with a non jsf component tree is problematic, due to ajax... Also simply dropping it if someone messes with the urls also is somewhat problematic (ajax again) I will add the issue later tonight.
