shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [dialog] Progress on weekend experiments
Date Tue, 29 Aug 2006 05:05:41 GMT
On 8/28/06, Craig McClanahan <craigmcc@apache.org> 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
>
>

Mime
View raw message