On 8/25/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
I have few initial concerns after looking over the excellent documentation and examples on the Commons SCXML site. So far, my concerns are as follows: 1.) I'm not wild about having to run an XSL transform on dialogs during compile time but the SCXML approach to configuring dialogs seems to involve excessive XML if you're not using UML. Don't get me wrong. Its a very cool concept but I'm not sure going from UML to dialog config is the most important feature in a dialog solution.
Do you agree that we should continue to support a simplified configuration format like the current dialog-config style? Besides backwards compatibility (which is an issue), I'm thinking we want to offer an alternative that is easier for hand coders. The need goes down for this when there are GUI tools to assist you in setting it up (or a tool that translates a real UML state diagram). 2.) Each dialog needs its own SCXML file. In one extreme use case
where you have a ten step dialog and you want to have individual single step dialogs for each of ten steps, you'd need 11 SCXML files.
The states that represent your subdialog can be nested inside the state that represents each step, so they can all live in the same file. That only works if you don't need to resuse them, in which case a separate file (perhaps included via XML entities or something if you need the semantics of nested states) would seem like the way to go. 3.) Global transitions need to be configured in each of the SCXML
files (is that right?) While I realize these should be ideally coming from the UML, the reality is a lot of people will not be using SC to design their dialogs.
If I'm understanding Section 3.3.1 of the spec right, nesting the states of your subdialogs would deal with this as well ... the transition out of a substate can use a target state that is defined by a parent -- essentially behaving like a global transition. I haven't made up my mind on SCXML - in fact I seem to be swinging
back and forth. Even if we don't go with it right away, I think it merits further study (and a place in our sandbox.)
I'm definitely in favor of doing some experiments. My gut is that I'd rather focus on mapping a generic state machine to the web world than having to do that and maintain the state machine engine itself. In addition, an SCXML state engine has lots more power than the bare bones one that dialogs currently has. And things like the ability to use an EL expression on a "cond" (a guard condition on a transition) lets you express lots more complicated decisions without having to write any Java code. I'm curious as to what others think. Likewise. Sean Craig On 8/24/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> On 8/24/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > <snip/> > > > > Yes, the UML notation on a transition is: > > > > event[guard_condition] > > > > Simply put, the states that have faces.outcome listed as the event are > > view states (wait for the postback "event") and the others are action > > states. > > > <snap/> > > Sorry, the above should read: > > ... the states that have faces.outcome listed as the event *on > outbound transitions* are view states ... > > -Rahul > > > > You can skip the event, the guard condition or both on a transition. > > Eventless transitions get evaluated as soon as executable content > > "onentry" for that state is done. The symbol and text label under the > > "checkCookie" state label implies execute that method binding > > expression on entering the state (which gives us the logical outcome > > to choose the outbound transition). > > > > -Rahul > > > > >
