Yeah, I remember the exchanges from a long time ago about "else" in DRL. IIRC, Mark wasn't keen on the idea.
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 :)
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 <email@example.com> wrote:
I bet Edson can't wait to refactor the parser for that ;)On 31 March 2011 21:11, Mark Proctor <firstname.lastname@example.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.
On 31/03/2011 20:25, Michael Anstis wrote:_______________________________________________ rules-dev mailing list email@example.com 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 == )
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
Person ( age < )
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 )
Lisa, Jane, Paul
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 )
not Person ( name soundslike "Fred" || soundslike "Phil" )
Would this be considered the most suitable approach?
Inputs and thoughts welcome.
rules-dev mailing list
rules-dev mailing list
Michael D Neale