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.
