On 11/10/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> I suppose we could have
>
>
On 11/10/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
>
> I know this conversation was over a week ago but I finally had some
> time to get back to my mailing list backlog... (see inline comments
> below)
>
> > How is this different from just encapsulating your setup logic into an
> > action metho
I know this conversation was over a week ago but I finally had some
time to get back to my mailing list backlog... (see inline comments
below)
> How is this different from just encapsulating your setup logic into an
> action method, and then calling it as the first state of the dialog
> explicitly
On 10/27/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 10/27/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> >
> > Just wanted to bounce an idea off of people. We have our own custom
> > Dialog class that makes use of a "beforeStart" attribute. Basically
> > there are certain steps we take b
On 10/27/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
>
> Just wanted to bounce an idea off of people. We have our own custom
> Dialog class that makes use of a "beforeStart" attribute. Basically
> there are certain steps we take before each dialog. We can't really
> reuse a state using XML entiti
Just wanted to bounce an idea off of people. We have our own custom
Dialog class that makes use of a "beforeStart" attribute. Basically
there are certain steps we take before each dialog. We can't really
reuse a state using XML entities because the "next" transition is
always different depending
