On 10/23/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 10/23/06, Torsten Krah <[EMAIL PROTECTED]> wrote:
>
<snip/>
> Btw ist 1.0.4 usable, especially the scxml dialog2?
From an API perspective, I think we're done (although a bit more testing
around browser navigation buttons is still needed). From an implementation
point of view, the scxml implementation passes all the same tests that the
basic version does, which is a "good thing" :-). But, because its
capabilities are different, I can't speak from personal experience to how
shaken out the underlying SCXML implementation stuff is. Rahul should be
able to add some insights here.
<snap/>
Here is a pointer to the browser buttons bit [1], you should evaluate
the impact for your application.
The underlying Commons SCXML implementation is quite stable, folks
have been using the core bits (those that are used by
shale-dialog-scxml) for quite a while. The W3C specification may bring
changes since its not a Candidate Recommendation yet (its a Working
Draft), but the API will evolve in line with Commons standards, which
are quite high, so that risk is well mitigated, IMO. You will find
most of the details and a user guide on the Commons SCXML site [2],
the background for the Shale dialogs piece is here [3]. I'm hoping to
port some of that and then add some docs in this (currently empty)
space [4] later in the week.
All the things you can do with the basic impl can be done easily with
the SCXML impl (lone exception is if you've subclassed the object
model for the basic state machine impl, that might require some
thinking while porting).
Additionally, you get certain things for "free". Some examples:
* Closer UML2 semantics, crisp mapping to state chart diagrams
* Per state contexts (for scratch space workflow variables)
* Arbitrary expression evaluation (rather than just method binding)
in dialog definition
* Histories, for navigation of the style - go back to (the view)
where I was at some prior point
And thats without exposing any SCXML implementation specific APIs
(just using the shale-dialog abstraction APIs). Therefore, there is
value to starting new applications with the SCXML dialogs
implementation, rather than the basic one. Most basic dialog
definitions can just be styled into SCXML dialog definitions, so its
possible to move existing basic dialog definitions over fairly
quickly, if thats the decision.
At some point in the future, it makes sense to expose some of the
underlying Commons SCXML APIs (such as the actual SCXML execution
engine instance) via the (SCXML) DialogContext to developers. This
will add another set of features that will become available to
developers if they can be assured that the dialog implementation is
the SCXML impl -- which they should be if they choose it ;-) -- but
one step at a time.
-Rahul
[1] https://issues.apache.org/struts/browse/SHALE-61
[2] http://jakarta.apache.org/commons/scxml/
[3] http://jakarta.apache.org/commons/scxml/usecases/scxml-in-shale-dialogs.html
[4] http://shale.apache.org/shale-dialog-scxml/index.html
Torsten
>
>
Craig
