[rules-dev] Re: ruleflow processes

[Michael Neale]

OK I will look into doing it. Unless someone beats me to it.

I propose a addRuleFlow() to PackageBuilder - and the rest is behind the
scenes.

Sound good?

On 5/25/07, Mark Proctor <mproctor at codehaus.org> wrote:
>
>  Was fine for the initially implementaiton, woudl rather have it fully
> integrated for 4.0 final.
>
> Mark
> Michael Neale wrote:
>
> great, not sure if I will do this for 4.0 though, will see, but certainly
> this sounds like it can work nicely.
>
> Keeping it decoupled as it was is/was probably the best thing, definitely
> the right way to go.
>
> So it ruleflow still "experimental" class for 4.0? or is it now officially
> part of the core?
>
> Michael
>
> On 5/22/07, Kris Verlaenen < kris.verlaenen at gmail.com> wrote:
> >
> > The reason it was specified in a separate class is that it is still
> > more experimental, and I didn't want to interfere with the core stuff
> > too much.  I don't see any real downsides, ruleflows are indeed just
> > another asset I think.
> >
> > Kris
> >
> > On 5/22/07, Michael Neale < michael.neale at gmail.com> wrote:
> > > Kris, looking at the ruleflow stuff (not the core, but the .rf stuff),
> > I
> > > have a suggestion on how to make it more integrated with the
> > ruleset/package
> > > structure.
> > >
> > > At the moment Ruleflow packages are a seperate entity that is merged
> > into a
> > > RuleBase as needed.
> > >
> > > Does anyone have any objections if we add the ability to have ruleflow
> > as
> > > part of a rule Package itself? (thus when that package is added to the
> > > rulebase, all the processes for ruleflow go along with it)? so a
> > ruleflow.rf
> > > file for example becomes just another asset like a drl?
> > >
> > > Kris? thoughts? downsides?
> > > No need to change the current API.
> > >
> > > Michael
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070525/b7c849d6/attachment.html