[shale] Serious issue with dialog state

• Key: SHALE-48
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: sean schofield
• Component/s: Dialog
• Fix Version/s: 1.0.4

Environment

Operating System: other
Platform: PC

Description

Consider the following example:

Start up the usecases example and begin creating a new profile. Stop when you
get to page 2. Now open a new tab (use Firefox) and click the logon dialog
again. You get an exception:

java.lang.IllegalArgumentException: Position[dialogName=Edit
Profile,stateName=Page 2],outcome=dialog:Log On

This is because you have initiated the same dialog without finishing the
previous dialog. This is not as crazy of a test as it might seem. Consider
what would happen if you opened the dialog in popup window (instead of a browser
tab) and the user closed the window prematurely ... same problem.

Comments

[sean schofield]

Any thoughts on this one?

[sean schofield]

Why can't we do something like getExternalContext().getSessionMap().put
(Globals.STATUS,null) before calling the start action. Maybe there are some
issues involved with sub dialogs but IMO some solution should be found to this
problem.

[Craig McClanahan]

The underlying issue is broader than just trying to have two copies of the same
dialog running ... the current code doesn't support two simultaneous dialogs
(same or not). That will become attractive both in a Tiles world (where you
might well want a dialog running in each tile) and for things like a popup that
runs its own dialog without disrupting the dialog being run by the underlying
window.

An overall solution to running multiple dialogs simultaneously should address
this particular use case, plus a lot more.

[Craig McClanahan]

The issues raised in this ticket are the tip of the iceberg on a bunch of
improvements that are needed to the dialog facility with regards to
simultaneously active dialogs by the same user, and the back button. Deferring
those to a post-1.0.0 milestone (but not forgetting them), so they can be
addressed all at the same time.

[sean schofield]

I mentioned a possible solution on the dev list a while back but didn't get any
comments. I also discovered a new problem that I wasn't aware of. I'll add it
again here so we don't lost track of it.

If you are running a dialog in a popup window (very likely) or within a Tile
(also likely) your command links outside of the dialog are completely hosed by
DialogNavigationHandler. DialogNavigationHandler assumes that everything is
part of the dialog sequence as long as there is a non-null status/position.

One possible way out of this is to use something like "dialogName:" in your
actions. So to launch a dialog named Foo you would use action="Foo:". The
dialog navigation handler would check to see if there is a dialog named "Foo"
available and if so, then launch it.

For navigation inside the dialog, you would need to prepend your dialog name to
the actions. So your next and previous buttons in the Foo dialog would have
actions of "Foo:next" and "Foo:prev". The transitions in dialog-config would be
simple "next" and "foo" and DialogNavigationHandler would know what to do
because of the dialog name prefix.

I haven't worked out all of the details but perhaps there could be custom
commandLink and commandButton components that could add the appropriate prefixes
to the actions. Anyways, those are some thoughts.

[sean schofield]

A few more thoughts on my proposed solution. Rather than using the dialog name,
I am thinking the dialogs and their transitions should be identifiable according
to "context" (or perhaps scope, thread, track or some other word that describes
the concept.) So basically if you want to have two or more dialogs running at
the same time, you just initiate one with dialog:FooStep and the other with
dialog2:BarStep.

DialogNavigationHandler will assume anything before the ":" refers to a
particular dialog scope (I know scope isn't the right word exactly but its the
best I can do for now.) This doesn't rule out using regular faces navigation
rules with a ":" in them, if there is no such dialog then navigation will be
delegated. This way dialog positions can be stored in a map with this scope
name as the key. You can also clear the status/position information
automatically when launching a dialog (in case the dialog was a popup and the
dialog was terminated by closing the window.)

BTW, there is yet another use case the fails with this bug. In the current code
its impossible to have a sortable table in your dialog b/c all navigation is
assumed to be related to dialog transitions.

[Laurie Harper]

It may be well known or obvious to those familiar w/ Shale, but I found I got
bitten by this in the Use Cases sample app just by clicking the link for the
logon dialog, clicking the browser's back button to return to the home page and
then clicking any link... after which, I had to clear my session cookie to
experiment any further.

[sean schofield]

This issue hasn't really been fixed. Its was resolved as "Later" in bugzilla. Its still a pretty bug. I think we should reopen but leave it without a version to be fixed in.

[sean schofield]

Reopening this issue now that its been migrated from Bugzilla. Craig and I discussed a potential solution to this back at ApacheCon 2005 but the details elude me at the moment. I'd like to put this back on our radar screen. I'm happy to try and help with the solution. @Craig: Maybe you can refresh my memory about your proposed solution?

[Dominique Jean-Prost]

one of the problem is that the exception raised is very generic (ie IllegalArgumentException). I think it could be at least changed to something a bit more specific, for example : ShaleStateMachineUnsynchronizedException or whatever instead of the IllegalArgument.

Without needing a too much complex change that seems to be needed to fix the whole stuff, it could add a way to deal with the issue.

[Craig McClanahan]

The new shale-dialog functionality (and both the basic and scxml implementations) address the issue of multiple dialogs (each in their own window or frame), so I'm declaring this one as fixed.