How to handle links outside a SCXML Dialog?

[Paul Spencer <pa...@apache.org>]

I am having an issued when users click links that are not known to the 
SCXML dialog.  When this occurs an exception from 
ShaleApplicationFilter.doFilter() is thrown. The links are part of the 
page's headers, footer, and navigation bar.  The expected behavior when 
the user click one of the links, like "Home", is the dialog will be 
closed and the desired page will be displayed.

How do I support links that are outside the dialog without adding each 
possible link to each dialog?

Paul Spencer

Re: How to handle links outside a SCXML Dialog?

[Werner Punz <we...@gmail.com>]

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 <we...@gmail.com> 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)

Re: How to handle links outside a SCXML Dialog?

[Craig McClanahan <cr...@apache.org>]

On 6/29/07, Werner Punz <we...@gmail.com> 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.
>
>

Re: How to handle links outside a SCXML Dialog?

[Werner Punz <we...@gmail.com>]

Rahul Akolkar schrieb:
> On 6/29/07, Werner Punz <we...@gmail.com> 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.

Re: How to handle links outside a SCXML Dialog?

[Rahul Akolkar <ra...@gmail.com>]

On 6/29/07, Werner Punz <we...@gmail.com> 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

Re: How to handle links outside a SCXML Dialog?

[Werner Punz <we...@gmail.com>]

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.

Re: How to handle links outside a SCXML Dialog?

[Rahul Akolkar <ra...@gmail.com>]

On 6/28/07, Paul Spencer <pa...@apache.org> wrote:
> I am having an issued when users click links that are not known to the
> SCXML dialog.  When this occurs an exception from
> ShaleApplicationFilter.doFilter() is thrown. The links are part of the
> page's headers, footer, and navigation bar.  The expected behavior when
> the user click one of the links, like "Home", is the dialog will be
> closed and the desired page will be displayed.
>
> How do I support links that are outside the dialog without adding each
> possible link to each dialog?
>
<snip/>

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


> Paul Spencer
>