Craig,
On 10/11/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> Rahul,
<snip/>
>
>
> You definitely piqued my interest when I saw a couple of "Shale related" SVN
> commits on the Commons developer list :-). It's pretty interesting stuff --
> and the set of state diagrams that can be described is quite a lot larger
> than the scope I originally had in mind for Shale's dialogs (which were
> intended to be as simple as could possible to support the basic dialog
> facilities, integrated with JSF's expression language semantics). It would
> be interesting to compare the expressive power of SCXML to the configuration
> file format for Spring Web Flow as well.
>
<snap/>
Your observation about the scope of SCXML is quite accurate. SCXML,
part of its inspiration being Harel State Tables, is probably going to
be theoretically as complete as a declarative notation of state charts
will get. As some background, this Working Draft has come out of the
Voice Browser Working Group of the W3C, and is getting widespread
attention. Voice applications have traditionally needed very
expressive dialog managers, and much of that experience has also gone
into SCXML. When I looked at Shale's dialog-config.xml, I said this
looks like shorthand SCXML (without a bunch of things such as
Parallel, UML state/activity separation, onexit and ontransition
executable content etc.). As you note below, this does mean that the
simplest dialogs appear more verbose. More importantly though, the not
so simple dialogs will be possible.
Ofcourse, all this talk needs someone to write working samples.
Comparing SCXML with Spring Web Flow, for example, will definitely be
an interesting exercise, and I'd really like to create an expressivity
matrix and compare and contrast when I find some cycles. Having said
that, I must add I am not keen on playing King of the Hill, thats not
what this is about, I'd rather get something (good) done ;-)
>
> I wouldn't object to posting this stuff on the Shale Wiki ... although it
> might be better as a link to the Commons SCXML pages (and I can add a link
> to the Dialog part of the Shale website as well).
<snip/>
Sounds good, will add that recipe (changed per your next email below)
to the Commons SCXML site, probably tomorrow.
>
> A couple of quick questions, as this was my first exposure to SCXML.
>
> * A quick skim through the SCXML working draft didn't point me at any
> definition of the syntax and semantics of the expressions being used.
> Is that totally up to the implementation?
<snap/>
It doesn't say, and while that may change, I am secretly hoping that
the freedom to choose will be retained simply because it allows an
environment agnostic SCXML engine implementation (such as Commons
SCXML) to be used in multiple, varied environments by plugging in the
appropriate evaluation contexts and evaluators. And state charts
really have many use cases, so such a constraint would be restrictive.
>
> * It looks like you are using a mixture of JSP 2.0 EL (${...}) and JSF 1.1EL
> (#{...}) expressions. If so, it might make sense to standardize on only
> one of them throughout -- probably the JSF one because it knows what
> a method binding expression is, to reduce confusion.
<snip/>
Thats fine, I have no particular affinity to that scheme. I'm probably
just used to seeing JSP 2.0 as the view layer technology with JSF
wherein the two types of expressions may be intermixed (say JSTL + JSF
tags).
>
> I need to do more research before I have any real opinion on the potential
> applicability of SCXML inside Shale -- in particular, one concern is that
> for the simple cases the XML is somewhat more verbose. This could be
> mitigated by tools support that generated the things from a real state
> diagram, and/or some sort of XSLT transformation that converts an existing
> Shale Dialog configuration file into the SCXML format automatically. The
> latter sort of tool would be very useful for someone who started with the
> simpler Shale version, then needed extra power.
>
> What do you think?
<snap/>
Tooling and/or an XSLT (or other) interchange between formats can only
add value, but your next email is more in line with something floating
in my mind, so moving on ...
On 10/11/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 10/10/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> >
> > Rahul,
> >
> >
> > > http://people.apache.org/~rahul/scxml-in-shale/<http://people.apache.org/%7Erahul/scxml-in-shale/>*time-sensitive
> > > URL*
> >
> >
> One other note before I hit the sack tonight ... with regards to your
> "either/or" question, you could actually have *both* SCXML-based and
> Shale-dialog-based support at the same time pretty easily. All it takes is:
<snip/>
Someday, I will be able to express myself clearly ;-) I never intended
to ask an either-or question. What [
http://people.apache.org/~rahul/scxml-in-shale/#thisthat ] says in
response, is "Both, and more". It talks about a front-end navigation
handler and appropriate delegation, and I think our thoughts might be
coalescing towards the similar things.
>
> * Use a prefix on logical outcome strings different from "dialog:xxx" to
> invoke the special SCXML processing. Maybe "scxml:xxx"?
>
> * Make sure your NavigationHandler implementation delegates
> when it's not inside an SCXML based flow (probably already
> does, didn't check the code).
<snap/>
Yes, it does. It would be a shame not to.
>
> * Add a META-INF/faces-config.xml in your JAR file that defines
> just the SCXML navigation handler implementation.
>
>
> That would make the option of gradually transitioning to SCXML based dialogs
> much easier, and would avoid a bunch of the work you describe to modify the
> standard Shale environment.
<snip/>
Moving to the "black box" dialog and "dialog definition tuple" that I
mention briefly in the #thisthat section, given that there are more
than one ways to describe a dialog, as long as each dialog manager /
navigation handler is well behaved with respect to the mutual
contracts between dialog managers (the stack, status and position etc.
in Shale), then you should be able to write your dialog-config.xml and
I'll write my dialog.scxml and you can call me and I can call you and
we are a happy family. If dialog foo is simple, I can write my
shorthand, if dialog bar needs SCXML (or something else), then thats
what I use. A couple of NavigationHandlers come with shale-core (I
believe we are close to having two already), others may come up with
what they fancy. The reason why a front-end delegating
NavigationHandler might be important is because your quick recipe
above, while very useful for one additional NavigationHandler (and it
indeed is an easier recipe than what I wrote up requiring a shale-core
rebuild), may not scale very well. OTOH, if the "default"
NavigationHandler within shale-core is able to map the prefix to the
appropriate NavigationHandler to delegate to, we're in better shape(it
probably doesn't even have to be a JSF NavigationHandler, rather a
"ShaleDialogHandler" interface, since the front-end NavigationHandler
has everything we need to pass on to the delegate). The
ShaleDialogHandler associated with a particular dialog then becomes
part of the "dialog definition tuple", vaguely similar to how each
instance of rdc:group identifies the DM strategy implementation
managing its children [1].
-Rahul
[1]
http://wiki.apache.org/jakarta-taglibs/ReusableDialogComponents/Tutorials/Aggregation
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
