Shale dialog question

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

Hi everybody, I am just digging through the shale dialog codebase.
Maybe I am missing something here, but I cannot see following usecase
covered.
A User is in a dialog and exits the dialog by altering the url...
Now what happens then?
I cannot see any codepart of where the dialog then is dropped
and an event is issued to its referencing dialogcontext listeners.

Am I missing something here or is this a bug?



Werner

Re: Shale dialog question

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

Craig McClanahan schrieb:
> On 6/28/07, Werner Punz <we...@gmail.com> wrote:
>> Hi everybody, I am just digging through the shale dialog codebase.
>> Maybe I am missing something here, but I cannot see following usecase
>> covered.
>> A User is in a dialog and exits the dialog by altering the url...
>> Now what happens then?
>> I cannot see any codepart of where the dialog then is dropped
>> and an event is issued to its referencing dialogcontext listeners.
>>
> 
> At least for the "basic" implementation (probably the SCXML one as
> well), you're correct ... the identifier for the current dialog
> context is saved and restored as part of the JSF component tree state,
> which gets lost if you manually alter the URL in the browser (and
> therefore cause a new component tree to be created).
> 
>> Am I missing something here or is this a bug?
> 
> It's definitely a non-covered use case :-), so please do file an
> issue.  Figuring out what to do about it will be kind of interesting
> ... for example, you can't just assume that a request (in the same
> session) that doesn't include a JSF component tree (with the context
> identifier) means that all existing dialog contexts should be
> terminated ... that would have nasty consequences for things link
> stylesheet and Javascript links.
> 
I will tonight, sorry for being a little bit late on this, as for the
losing the state thing.

The best solution probably is to have some kind of garbage collecting
cleanup task which issues the relevant commands to shale periodically if
not having been accessed for a certain period of time.
(Probably 5-10 minutes)

That way a back button should trigger correctly if not done very late.
And you do not run into some resource loading or ajax killing off the
conversation problems.

Of course the downside of this is that you might run into a page timeout
issue that way. Well that could be again resolved by adding an ajax
conversation refresh code to a page under conversation which is
intercepted by a phase listener upfront which only renews the access
time, if you do not want to live with page/conversation timeouts.

I agree simply dropping it by running into a page with a non jsf
component tree is problematic, due to ajax...
Also simply dropping it if someone messes with the urls also is somewhat
problematic (ajax again)

I will add the issue later tonight.

Re: Shale dialog question

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

On 6/28/07, Werner Punz <we...@gmail.com> wrote:
> Hi everybody, I am just digging through the shale dialog codebase.
> Maybe I am missing something here, but I cannot see following usecase
> covered.
> A User is in a dialog and exits the dialog by altering the url...
> Now what happens then?
> I cannot see any codepart of where the dialog then is dropped
> and an event is issued to its referencing dialogcontext listeners.
>

At least for the "basic" implementation (probably the SCXML one as
well), you're correct ... the identifier for the current dialog
context is saved and restored as part of the JSF component tree state,
which gets lost if you manually alter the URL in the browser (and
therefore cause a new component tree to be created).

> Am I missing something here or is this a bug?

It's definitely a non-covered use case :-), so please do file an
issue.  Figuring out what to do about it will be kind of interesting
... for example, you can't just assume that a request (in the same
session) that doesn't include a JSF component tree (with the context
identifier) means that all existing dialog contexts should be
terminated ... that would have nasty consequences for things link
stylesheet and Javascript links.

>
>
>
> Werner
>
>

Craig