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@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@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