11:17 a.m.
Hi,
I opened myself a good can of worms yesterday.
The long and short of it is the following behave differently (with regard
to the DRL generated):-
- XLS Decision Tables
- Templates
- KIE-WB Guided Decision Tables
- KIE-WB Guided Decision Table Template fragments
There is a further complication:
https://bugzilla.redhat.com/show_bug.cgi?id=996964
All of the listed rule types currently discount a constraint if it#s value
is empty, or value.trim() is empty. The requirement really only affects
String field types. The difficulty is how to differentiate between a
null-value (empty cell) and empty-string that works consistently with XLS
and the KIE-WB editors.
So, my question is what behaviour should we standardize on?
I propose the following:
- For a Pattern, with no constraints we exclude the pattern (this is
current XLS behaviour).
e.g. Person( name == $name, age == $age ). If we don't provide values for
$name and $age we don't include the Person pattern. If a user wants to
include the Pattern they'd need to add a constraint "this != null".
If we include the pattern when there are no constraints then it is more
difficult to provide a work-around to exclude the pattern if this is what
some users need (and since it's the existing behaviour; less likely to be
an issue for the majority of XLS users).
- Support escaping String literals with quotes; so a user would enter ""
or " ". This make it obvious that the cell contains a non-null value. The
surrounding quotation marks would be stripped before being used in the DRL.
WDYT? Should I put this out to the community for opinions too?
With kind regards,
Mike
2:41 p.m.
On 01/08/2014, Michael Anstis <michael.anstis(a)gmail.com> wrote:
I propose the following:
- For a Pattern, with no constraints we exclude the pattern (this is
current XLS behaviour).
e.g. Person( name == $name, age == $age ). If we don't provide values for
$name and $age we don't include the Person pattern. If a user wants to
include the Pattern they'd need to add a constraint "this != null".
If we include the pattern when there are no constraints then it is more
difficult to provide a work-around to exclude the pattern if this is what
some users need (and since it's the existing behaviour; less likely to be
an issue for the majority of XLS users).
- Support escaping String literals with quotes; so a user would enter ""
or " ". This make it obvious that the cell contains a non-null value.
The
surrounding quotation marks would be stripped before being used in the
DRL.
If the first character is not the quote character (0x22), assume that
the value in the cell is the actual value of a String. The result to
be used in DRL code will be quoted, and all characters will be escaped
as required according to Java rules.
If the first character is a quote character (0x22), assume that the
value in the cell is a complete String literal, according to Java
rules. It will be used "as is" in DRL code.
my 2¢
Wolfgang
WDYT? Should I put this out to the community for opinions too?
With kind regards,
Mike
7:52 p.m.
Closing the loop.
Implemented as proposed and seconded by Wolfgang with the additional nicety
of also checking for common auto-corrections in spreadsheet applications
(left-quote/right-quote replacing double-quote etc).
Also ensured guided templates, guided decision tables and XLS decision
tables all work consistently with empty cells and empty Strings.
Sent on the move
On 1 Aug 2014 13:42, "Wolfgang Laun" <wolfgang.laun(a)gmail.com> wrote:
On 01/08/2014, Michael Anstis <michael.anstis(a)gmail.com>
wrote:
> I propose the following:
>
> - For a Pattern, with no constraints we exclude the pattern (this is
> current XLS behaviour).
>
> e.g. Person( name == $name, age == $age ). If we don't provide values for
> $name and $age we don't include the Person pattern. If a user wants to
> include the Pattern they'd need to add a constraint "this != null".
>
> If we include the pattern when there are no constraints then it is more
> difficult to provide a work-around to exclude the pattern if this is what
> some users need (and since it's the existing behaviour; less likely to be
> an issue for the majority of XLS users).
>
>
> - Support escaping String literals with quotes; so a user would enter
""
> or " ". This make it obvious that the cell contains a non-null
value.
> The
> surrounding quotation marks would be stripped before being used in the
> DRL.
If the first character is not the quote character (0x22), assume that
the value in the cell is the actual value of a String. The result to
be used in DRL code will be quoted, and all characters will be escaped
as required according to Java rules.
If the first character is a quote character (0x22), assume that the
value in the cell is a complete String literal, according to Java
rules. It will be used "as is" in DRL code.
my 2¢
Wolfgang
>
>
> WDYT? Should I put this out to the community for opinions too?
>
> With kind regards,
>
> Mike
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
3550
days inactive
3555
days old
2 comments
2 participants
participants (2)
-
Michael Anstis -
Wolfgang Laun