<br><font size=2 face="sans-serif">Thank you Wolfgang, that works brilliantly.</font>
<br>
<br><font size=2 face="sans-serif">I appreciate your thoughts on Parameters
and will be doing something along that line as that looks cleaner again
- I hadn't gotten up to eliminating magic numbers yet.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">-Trav<br>
<br>
</font><font size=1 face="Arial"><b>Travis Smith</b><br>
Analyst Programmer<br>
Development Centre<br>
BNZ<br>
<br>
DDI: +644 4746356 (Or Ext 76356)</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<br><font size=1 color=#800080 face="Arial"><b>Wolfgang Laun <wolfgang.laun@gmail.com></b></font>
<br><font size=1 color=#800080 face="sans-serif">Sent by: </font><font size=1 color=#800080 face="sans-serif">rules-users-bounces@lists.jboss.org</font>
<p><font size=1 face="sans-serif">17/02/2011 05:44 a.m.</font>
<br><font size=1 face="sans-serif">Please respond to<br>
Rules Users List <rules-users@lists.jboss.org></font>
<td>
<td>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">Rules Users List <rules-users@lists.jboss.org></font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: [rules-users] using "contains"
against a List<BigInteger></font></table>
<br></table>
<br>
<br>
<br>
<br><tt><font size=2>It's Java, after all...<br>
<br>
The "contains" operator requires a Collection (or array) and
an<br>
Object. A plain numeric literal won't result in a BigInteger without<br>
you providing a hint.<br>
<br>
You can write<br>
$performance : Performance( calcScore contains
(BigInteger.valueOf(6)) )<br>
or<br>
dialect "mvel"<br>
when<br>
$performance : Performance( calcScore contains
(6I) ) # capital "i"<br>
<br>
All of these (and your eval) use magic numbers, so my preferred way of<br>
dealing with this would be s.th. like this, using a singleton<br>
Parameter fact for this and other values:<br>
<br>
when<br>
Parameter( $bis: bigIntSix )<br>
$performance : Performance( calcScore contains $bis
)<br>
<br>
-W<br>
<br>
<br>
2011/2/16 <Travis_Smith@bnz.co.nz>:<br>
><br>
> Hi,<br>
><br>
> A newbie question I'm afraid. I've been unsuccessful searching the<br>
> mailing-list archive (and google) for this.<br>
><br>
> I'm trying to simplify rule-writing for Statistical Analysts to be
able to<br>
> write rules. I'm hoping to achieve this without resort to DSLR files
and a<br>
> DSL if possible as we currently need them for nothing else<br>
><br>
> One of the situations I have is the following:<br>
> --------------------<br>
> when<br>
> $performance : Performance(<br>
> eval(calcScore.contains(BigInteger.valueOf(6)))<br>
> )<br>
> then<br>
> [...]<br>
> --------------------<br>
><br>
> That works absolutely fine: CustAccPerf being a having several members,<br>
> including an ArrayList<BigInteger> called calcScore<br>
><br>
> Howwever I'd like to rewrite it like:<br>
> --------------------<br>
> when<br>
><br>
> $performance : Performance( calcScore contains 6 )<br>
> then<br>
> [...]<br>
> --------------------<br>
><br>
> Given the support for BigInteger & BigDecimal type comparison,
and the<br>
> structure of the 'contains' operator, I couldn't see why this wouldn't
work.<br>
><br>
> If someone could explain this would be excellent - for now I'm gong
ahead<br>
> with the eval, but from a non-technical usability POV the latter form
would<br>
> be far preferable: I'd prefer that the users don't have to worry about
eval<br>
> or BigInteger, and while I realize it's not possible (currently) to<br>
> eliminate that altogether, I would like to eliminate as many of the
(to<br>
> quote) "meaningless tech stuff" questions as possible.<br>
><br>
> Alternately if some kind person wants to tell me a better way of structuring<br>
> that rule so I can use it as a template, then that'd be welcome also.<br>
><br>
> Unfortunately we're dealing with a feed from a 3rd party system so<br>
> restructuring the data is not a desirable option.<br>
><br>
> Thank you for your time,<br>
> -Trav<br>
><br>
> Travis Smith<br>
> Analyst Programmer<br>
> Development Centre<br>
> BNZ<br>
><br>
> CAUTION - This message may contain privileged and confidential information<br>
> intended only for the use of the addressee named above. If you are
not the<br>
> intended recipient of this message you are hereby notified that any
use,<br>
> dissemination, distribution or reproduction of this message is prohibited.<br>
> This email was sent by the Bank of New Zealand. You can contact us
on<br>
> 0800 ASK BNZ (0800 275 269). Any views expressed in this message are
those<br>
> of the individual sender and may not necessarily reflect the views
of Bank<br>
> of New Zealand.<br>
><br>
> _______________________________________________<br>
> rules-users mailing list<br>
> rules-users@lists.jboss.org<br>
> https://lists.jboss.org/mailman/listinfo/rules-users<br>
><br>
><br>
<br>
_______________________________________________<br>
rules-users mailing list<br>
rules-users@lists.jboss.org<br>
https://lists.jboss.org/mailman/listinfo/rules-users<br>
</font></tt>
<br><pre>
CAUTION - This message may contain privileged and confidential information
intended only for the use of the addressee named above. If you are not the
intended recipient of this message you are hereby notified that any use,
dissemination, distribution or reproduction of this message is prohibited.
This email was sent by the Bank of New Zealand. You can contact us on
0800 ASK BNZ (0800 275 269). Any views expressed in this message are those
of the individual sender and may not necessarily reflect the views of Bank
of New Zealand.
</pre>