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. 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. 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. 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 curious as to what others think. Sean 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 > >
