Yet on the other hand, if/when it would be possible to use column binding in field constraints, this functionality will be possible to achieve like this, ie, rewrite this piece:

Record (fieldAsString matches “[xyz]” or fieldAsInt > 1, $myOtherField : myOtherField)

Record ($field : field, fieldAsString matches “[xyz]” or fieldAsInt > 1, myOtherField == $myOtherField)

Record (field == $field)

as

$r: (

    $r1: (

Record (fieldAsString matches “[xyz]”) or

Record (fieldAsInt > 1)

    )

    $r2: (

Record (fieldAsString matches “[xyz]”, myOtherField == $r1.myOtherField) or

Record (fieldAsInt > 1, myOtherField == $r1.myOtherField)

    )

    Record (field == $r2.field)

)

More verbose, but I think it should work the same way….

---

From: rules-users-bounces@lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Olenin, Vladimir (MOH)
Sent: 27 March 2007 11:02
To: Rules Users List
Subject: [rules-users] followup - 'or' for different field constraints

… the only thing that would not be allowed is to do the binding on the this ‘connective constraint’, since it would make sense. Eg, Record ($invalidBinding : fieldAsString matches “[zxc]” or fieldAsInt > 0) ) , since it’s kind of ‘views’ for the ‘field’ variable, while this one will work: Record ($correctBidning : field, fieldAsString matches “[zxc]” or fieldAsInt > 0) ), ie you need to bind the ‘original’ field, NOT the views. To think of this, it would actually be need to the <field>AsString, <field>AsInt, etc getters to be autogenerated…. Or even better – do that behind the scene depending on the context, if there is no ambiguity involved…

Vlad