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