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.
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.
I believe it is the application developer who knows when temporary
data stores like the dialog context are done being needed, and it is
the *responsibility* of the developer to do their own cleanup at those
known times. This advice holds if you're using Shale Dialogs, or if
you're using Seam (you do it there by ensuring that the action you
execute from your menu is annotated to exit the dialog), or Spring Web
Flow, and the same principle will likely be the standard approach for
Web Beans (JSR-299)'s ultimate framework ... and, I'd recommend it to
people using any other dialog framework as well.
Craig
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.
