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.
* 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? -Rahul
