On 8/28/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
I've checked in some progress on my experiments with how we can improve the
Dialog functionality. Even though they're not done yet, they are far enough
along to want some feedback and to make them available for experimentation
and further development. This mail will serve as a record of my thinking so
far, so you can get a feel for why I took the approach I've taken so far.
Initially, I wanted to address two shortcomings and one expanded feature in
our current approach:
* Make it possible for a single user to have multiple active dialog
instances
(although limited to one per JSF view, per our discussion).
* Make it possible to programmatically start up a dialog instance, as well
as
start one with a prefix on a logical outcome.
* Make it possible to plug in different state machine implementations
(i.e. Commons SCXML), perhaps with different detailed feature sets.
<snip/>
Yup, this pluggability lets us have our proverbial cake and eat it
too, in that we can make quick progress in the sandbox without having
to worry about features that are clearly non-portable (such as
"className" in shale-dialog2-legacy).
I have *not* tried to address synchronizing state when the user presses the
browser navigation buttons yet. One can of worms at a time :-).
<snap/>
Indeed, that can probably stay at the discussion level while we
fulfill the agenda you've outlined above in code.
Rahul had
some comments earlier today on how SWF deals with this. Seam does something
similar, and we'll undoubtedly need to add functionality here later.
To address these initial concerns, I focused first on abstracting out the
APIs that an application *using* the dialog feature should have to interact
with, and then providing generic integration for the navigation handler that
can start a new dialog, or operate an existing one. The guts of actually
processing the transitions, then, is delegated to a state-machine-specific
implementation. The key APIs are (so far) incredibly simple -- they are in
the "shale-dialog2" module in the sandbox.
<snap/>
Took a quick look. Beautiful :-), and I think we should try our best
to keep this baseline simple.
To validate this design, I've refactored the current support into a module
(shale-dialog2-legacy) that does pretty much the same thing as the existing
implementation, but organzied with the new APIs. (Side note ... Sean is
definitely not going to like what I did to the config classes, making
everything I could package private ... that's my new habit when designing
APIs ... we can make things more public later as needed, but cannot really
go the other way.) As I mentioned in the commit comments, this stuff has
only been desk checked and not actually used yet, so it undoubtedly has
bugs, but it should be easy to make functional -- and it benefits from the
"dialog instance per view" fix in the underlying architecture to fix that
problem.
A corresponding module for Commons SCXML has been started, but I got
sidetracked a bit on the legacy one. It'll be pretty easy to finish this
off in a similar fashion, though ... that'll be my next step unless someone
wants to volunteer to beat me to it.
<snip/>
I'll do it.
-Rahul
Craig
