thx for your answers - i think i am going to evaluate 1.0.4 and its new dialog implementation.
Torsten Am Dienstag, den 24.10.2006, 01:48 -0400 schrieb Rahul Akolkar: > 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 > > > >
