Re: How to handle links outside a SCXML Dialog?
Ok first of all I added an issue https://issues.apache.org/struts/browse/SHALE-453 to streamline this discussion. Craig McClanahan schrieb: On 6/29/07, Werner Punz [EMAIL PROTECTED] wrote: Rahul Akolkar schrieb: I suspect this will be relevant to both implementations. By design, it helps to think of a dialog as a complete model. However, I think we have talked about bits like headers, footers and navigation bars some time ago, and one of the things that could be done is to wire each outside link to an action that checks whether there is an active DialogContext and stop()s it, if there is one. See bottom of this page for some documentation on terminating dialogs: http://shale.apache.org/shale-dialog/index.html (v1.1.0-SNAP) -Rahul This is lots of wiring, and does not cover the case of a user typing in an outside url of the application manually or pushing it in via a bookmark. I assume the best option would be to leave it open for a short period of time of a few minutes and then do some garbage collecting of tangeling conversations. (Orchestra does it like that btw... and it works pretty well, not sure how Seam copes with this, but I assume very similarily) From an architectural viewpoint, this sounds suspiciously like how the recover abandoned connections capability of Commons DBCP works. I hesitate to call this a feature :-) because I think it begins from a misconception -- if the application hasn't given back a connection, it must have just forgotten to do so, and we'd better go clean up the mess. To me, not returning a connection is a bug in the application. Well session termination also works on the principle so it is not DBCP alone. For dialogs, I've been thinking about this a bit as well, given this thread. When the dialog stuff was first being designed, Sean ran into exactly this use case when trying to design a non-Hello World application. The approach Rahul described (have your menu links execute the exit actions) was the solution we came up to at the time, and I think it is still the best answer. Consider a scenario where you (the user) have multiple windows (or frames) open into the same application. This didn't work until Shale 1.0.4, but you can now have an independent active dialog context in each of them. As the user, I expect to be able to go back and forth between the windows, and interact with them in any order. As long as I don't let my session time out, *all* of those dialog contexts are, and should remain, active. I'm going to be really unhappy if you time out my processing in one of the windows, simply because I haven't been there in a while. Well... for that solution a triggered ajax callback or a frame/window refresh works best to keep the timeout token up to the current time. This is not really a big deal since shale already alters the component tree, so adding such a refresh component is not that much of an issue. (Since we are on jsf probably the ajax solution is a better fit than refresing the entire frame periodically)
Re: Shale dialog question
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.
Re: How to handle links outside a SCXML Dialog?
Rahul Akolkar schrieb: On 6/29/07, Werner Punz [EMAIL PROTECTED] wrote: Rahul Akolkar schrieb: I suspect this will be relevant to both implementations. By design, it helps to think of a dialog as a complete model. However, I think we have talked about bits like headers, footers and navigation bars some time ago, and one of the things that could be done is to wire each outside link to an action that checks whether there is an active DialogContext and stop()s it, if there is one. See bottom of this page for some documentation on terminating dialogs: http://shale.apache.org/shale-dialog/index.html (v1.1.0-SNAP) -Rahul This is lots of wiring, snip/ Maybe, but had the singular advantage of being a possible solution with what was in trunk when the question was asked :-) and does not cover the case of a user typing in an outside url of the application manually or pushing it in via a bookmark. snap/ Yes, as you're discussing in the other thread already. So, on to design ... I assume the best option would be to leave it open for a short period of time of a few minutes and then do some garbage collecting of tangeling snip/ Do you mean dangling? Sorry wrong word, I am not a native speaker, the problem I see currently is that shale leaves dialogs in ram if you do not terminate correctly. It either just leaves them or drops into an error state instead of simply closing it once the blackbox is left. So we have something left in the ram which probably is never recovered or will be cleared once the session is dropped. conversations. (Orchestra does it like that btw... and it works pretty well, not sure how Seam copes with this, but I assume very similarily) snap/ Haven't looked at Orchestra, perhaps you have a sample app with the specific functionality you can point to? Well if just build the examples, it is easy to follow... I havent had a look at the integrated examples (I was building my own app with it) but the situation is like that, that orchestra has a cleanup thread which currently is triggered every five minutes a conversationcontext (a collection of conversations/dialogs under one id) not accessed for five minutes currently simple is closed no matter what and it then can do its cleanup and close tasks. Currently it does not cover the keep it alive if you are on a correct page task, but it does neither leave connections open nor does it leave something in the ram. Have in mind having left a dialog open in ram for a long period of time is way more critical in orchestra due to the orm/jdbc connection handling it does. So the close has to be issued, and is. I assume Seam follows a similar timeout path/pattern (I have not had a look at it) If you do not want to live with page timeouts which are the result of such a thing, then adding a subsequent small ajax part which triggers internal dialog refreshes might help to avoid it, since shale dialog alters the jsf page tree anyway, adding another small ajaxing codepart might not be the biggest problem. I am not too familiar yet with shale dialog, but would it be possible to set wildcards that way it also could be possible to cover the case... all outcomes, urls and actions which are covered are covered as is, all other outcomes, and actions covered by some wildcard pattern go straight to exit. Of course that does not relieve shale from getting into tangeling dialogs from time to time especially in configuration changes or configuration errors, but it would also not break the metaphor shale tries to follow and would reduce the problem to a bare minimum. snip/ Thanks for these suggestions, quite useful. Not sure what to make of either approach, need to dwell on it a bit. We could invent a dialog timeout and then work to keep things from timing out when they shouldn't, though its still unclear whether that covers all bases (such as when you manually try to navigate away from a dialog to initiate another dialog etc.). The wildcard idea is interesting, but Well that case definitely is covered if you navigate away the first dialog is abandoned and then basically it is timed out after a while, the garbage collecting thread will clean it up and will close it properly after a while. also makes the model fuzzier (because there is some additional, perhaps implicit, behavior and that needs to be configured and the extent to which such behavior can be configured will tend to bloat, the dialog configuration becomes potentially distributed etc.). If you can capture your ideas in a ticket in JIRA, that'd be a start for this discussion. In my mind, the best proposals will be those that do not compromise the completeness of the dialog descriptor, nor the (relative) simplicity of design (and thereby, authoring). I will open the issue in 1-2 hours to collect everything ideawise. I will post the issue link later in this thread.
