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