Yeah, I remember the exchanges from a long time ago about "else" in DRL. IIRC, Mark wasn't keen on the idea.I didn't like the way Ilog did "else", where it only works on an "eval" node and must be the last CE in a rule.
If the first branch is true it'll continue to propgate to the next node which is part of the [then] chain, [then] is implicit for the first branch. If b1 or b2 are true it'll it will activate the labelled block
branch( Pattern(....),
[b1] Pattern(....),
[b2] Pattern(....) )
If none of the branches match then the [b3] default branch is activated.
branch( Pattern(....),
[b1] Pattern(....),
[b2] Pattern(....),
[b3] default )
We can have branches activated when the pattern is not matched.
branch( [!b1] Pattern(....),
[!b2] Pattern(....),
[!b3] Pattern(....) )
In the case of b2 and b3 if the pattern is not true, it'll do nothing, if the pattern is false the b2 will or b3 will activate. In the case of first pattern, if it's false the b1 block will activate, if it's true it will continue to propagate to the rest of the rule. ** is this consistent and intuitive?
** Each branch does not need to be a Pattern it can have any drl, be it an 'else', 'not', 'and'. If you want multiple patterns, make sure to use the 'and' CE. We shouldn't allow 'or' CE's as I think that would get too messy
** At the moment we don't ensure any xor type behaviour. For
instance we could have it that so only one branch can activate,
it'll start at the top and try each one in turn, exiting after the
first one is activated.
Anyway, provided my "reversals" make sense it's almost complete in the guided dtable; it only uses SimpleFieldConstraints so doesn't have the complexity of compound constraints :)
On 31 March 2011 22:20, Michael Neale <michael.neale@gmail.com> wrote:
Otherwise has been dragging on since 2006. There are many skeletons in that cave.
I will believe it when I see it !--
On Fri, Apr 1, 2011 at 7:25 AM, Michael Anstis <michael.anstis@gmail.com> wrote:
I bet Edson can't wait to refactor the parser for that ;)
On 31 March 2011 21:11, Mark Proctor <mproctor@codehaus.org> wrote:
on a related note I do plan to add OTHERWISE support at a DRL level, just no time to do it right now. Once it's supported at a DRL level, you won't need to as much work on figuring out the inverse options etc.
Mark
On 31/03/2011 20:25, Michael Anstis wrote:_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-devHi,
I'm adding support for "otherwise" to (for the time being) the guided decision table in Guvnor.
The idea being if you set a cell to represent "otherwise" the generated rule is the opposite of the accumulation of the other cells; perhaps best explained with an example:-
Person( name == )
Mark
Kris
Geoffrey
<otherwise>
This would generate:-
Person(name not in ("Mark", "Kris", "Geoffrey")
Equals is the simple example, this is my thoughts for the other operators we might like to support:-
- != becomes "in (<list of the other cells' values)"
- < becomes ">= the maximum value of the other cells' values
For example:-
Person ( age < )
10
20
30
<otherwise>
Person ( age >= 30 )
- <= becomes "> the maximum value of the other cells' values
- > becomes "<= the minimum value of the other cells' values
- >= becomes "< the minimum value of the other cells' values
- "in" becomes "not in (<a list of all values contained in all the other cells' lists of values>)"
For example:-
Person ( name in )
Jim, Jack
Lisa, Jane, Paul
<otherwise>
Person ( name not in ("Jim", "Jack", "Lisa", "Jane", "Paul" ) )
- I'm not sure there is a simple solution for "matches" and "soundslike" but welcome advice, although a possibility might be to create a compound field constraint:-
Person ( name soundslike )
Fred
Phil
not Person ( name soundslike "Fred" || soundslike "Phil" )
Would this be considered the most suitable approach?
Inputs and thoughts welcome.
Thanks,
Mike
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev