On 8/30/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 8/30/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
>
> The init and destroy commands for the Shale dialog configs will need
> to have mods for dialog2 (atleast init).
>
> Should we copy them over to the sandbox so we can work with them? Need
> to be able to configure the parser.
I actually finessed this on the legacy version, by reading the configuration
stuff on demand.
<snip/>
Yup, I used the same scheme in shale-dialog2-scxml on that one ;-),
just wasn't sure if it was a sandbox thing. Will be a noticeable hit
for the first dialog instantiation, depending on the size and number
of dialogs.
One thing I didn't like about the original pattern was
these classes only got invoked if you happened to define the Shale
application filter. I've been on a kick to make the various parts of Shale
as self-configuring as possible, and this seemed like another opportunity.
<snap/>
Makes sense, that way the only remaining thing that the application
filter seems to be invoking is the deprecated remote stuff.
-Rahul
-Rahul
>
Craig
