On 8/24/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: <snip/>
In my ideal world scenario, we'll be able to rebuild things on the inside, with minimal-to-none impact on how an application developer uses it. However, I'm not convinced that goal is actually achievable, if we're going to have a dialog infrastructure that meets the functional requirements we've outlined. Even if it is not totally possible, however, I'm a fan of the way dialogs are currently configured, and would like to keep as much of that as possible, even if we did something radical like used Commons SCXML as the execution engine under the covers (betcha Rahul just perked up :-) -- things like that should be on the table at this point, as far as I can see.
<snap/> Yes, that draws my attention, not (only) because I'm a Commons SCXML developer, but because I believe this is the right way moving forward for Shale dialogs (I'll articulate in detail in another thread). No doubt that backwards compatibility should be maintained as far as possible. To use Commons SCXML to also support the current dialog notation, three approaches come quickly to mind: 1) Run a XML tranform under the hood (possibly tricky, since dialog-configs can contain multiple dialogs). 2) Write a specific digester that can map dialog-config.xml to the Commons SCXML model package [1]. 3) Do a Java object mapping (basically walk the object graph) of the Shale object model to a Commons SCXML one. Any other ideas? Any preferences? -Rahul (long, possibly fragmented URL below) [1] http://jakarta.apache.org/commons/scxml/apidocs/org/apache/commons/scxml/model/package-summary.html
Craig
