On 12/16/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
On 12/16/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 12/16/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: <snip/> > > The subdialog issue doesn't exist in the Commons SCXML impl (its one > > machine, rather than a stack of machines at runtime) -- ofcourse, the > > downside is that IDs in the parent and subdialog need to be unique > > (there are a few best practices to mitigate that, plus the next WD may > > have other recommendations regarding this, IIUC). > > > The experiment I'm trying on the Basic impl is to declare, via a context > init parameter, a "strategy" value for what getOpaqueData() should return, > with the default being "none" as is the current behavior. I'm looking at a > couple of possible strategies: > <snap/> Interesting, I actually gave a thought to (similarly) having a way to have multiple behaviors as well (and have the app developer select one via the dialog-config for each dialog) but for some reason it didn't stick in my mind. At some point, I remember going so far as to think if it would be possible for the app developer to provide such a "strategy" impl his/her dialog(s) -- in addition to a small list provided -- but that seemed to involve too many details of the dialog impl.
Agreed ... I could see actually implementing it with pluggable package-private implementations in the same package, but that seems like overkill for what will be a pretty small amount of implementation code. And that still wouldn't let the user extend it anyway, unless they put their own classes in the same package.
* Current state name (+ some way to tell if you crossed a subdialog > boundary so you can throw an exception) > > * The entire stack of Position instances, which includes the "data" > objects at each level, so unwinding and rewinding changes everything. > > An interesting question to contemplate is what should happen with event > firing with our shiny new DialogContextListener interface. > <snap/> Indeed, I think a common paradigm will be: do stuff on entry / undo on exit. In which case, the onExit() from the previous view state and the onEntry() into the new view state (whose corresponding view user navigated to using browser buttons) should minimally be fired. WDYT?
That certainly seems reasonable. I don't know about calling onTransition() though ... it seems quite likely that the "transition" implemented by responding to the navigation-induced changes will identify an arc that does not actually exist in the state diagram. -Rahul
