shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [dialog] Get rid of subdialogs
Date Thu, 24 Aug 2006 21:24:10 GMT
On 8/24/06, Craig McClanahan <craigmcc@apache.org> 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
>
>

Mime
View raw message