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)
