But my rule is an emty one : #list any import classes here. import java.util.List; import java.util.Date; #declare any global variables here rule "ruleDsl" when une date then end And in my dsl file I have : [condition][]une date=Date() And I have an expanderException ... unexpected token 'une' !! :( Manukyan, Sergey wrote: -- View this message in context: http://www.nabble.com/error-using-a-dsl-tf4248883.html#a12094053 Sent from the drools - user mailing list archive at Nabble.com.

Thanks Edson for workaround, IMHO that looks like a limitation to me, is there a particular reason why left side should always be a field? -Sergey ________________________________ From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Edson Tirelli Sent: Friday, August 10, 2007 11:58 AM To: Rules Users List Subject: Re: [rules-users] bug or feature not yet implemented Sergey, That is how it is supposed to work. A field constraint in Drools always has a field at its left side. If you want arbitrary expression, just embed it in an inline eval: S : Supplier( $sts : supplierBusinessStatus.businessStatus, $csts : corporateSupplier.supplierBusinessStatus.businessStatus, eval ( $sts != $csts ) ) Although, for this specific case, it would be better (more performatic) to simply write: S : Supplier( $sts : supplierBusinessStatus.businessStatus, $csts : corporateSupplier.supplierBusinessStatus.businessStatus != $sts ) []s Edson 2007/8/10, Manukyan, Sergey <SManukyan(a)lear.com&gt;: Folks, I found that drools 4.0GA doesn't recognize variables in the left side of operator expression Like this produces error: When S : Supplier( $sts : supplierBusinessStatus.businessStatus , $csts : corporateSupplier.supplierBusinessStatus.businessStatus, $sts != $csts ) Then ... It tries to treat the $sts variable as a field of Supplier, instead understanding that it is a variable declared earlier, Please advise, Thanks, -Sergey ********************** ** LEGAL DISCLAIMER ** ********************** This E-mail message and any attachments may contain legally privileged, confidential or proprietary information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this E-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this E-mail message from your computer. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli Software Engineer - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11 9287-5646 JBoss, a division of Red Hat @ www.jboss.com

Thank you Edson, I am not a developer of drools, so I appreciate your sharing of design decisions here. I still wish the "field constraint" be a field constraint no matter how this field is referenced, be it by name or by variable that references this field, otherwise it is more like "field name constraint" So I wish I could do: Person( $a : age, $minAge : 30, $maxAge : 40, $a > $minAge && < $maxAge) The introduction of local variable can be helpful when field names are complex and long (that is the case I have now), and need to be used more then once inside of expression. Also using eval involves performance penalty, so I would like to avoid it wherever possible, Just my 2 cents... -Sergey ________________________________ From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Edson Tirelli Sent: Friday, August 10, 2007 3:17 PM To: Rules Users List Subject: Re: [rules-users] bug or feature not yet implemented Sergey, Well, a "field constraint" must always involve a field. The decision to have it on the left side is to simplify syntax. For instance, if you want to write something like: "age between 30 and 40", you can do: Person( age > 30 && < 40 ) So you declare the field only once and can have as many expressions applied over it as you want, using restriction connectives (&& and ||). Now, if your expression does not involve a field, then it is not a "field constraint". It may be an "inline-eval" (previously called predicate expression) for instance. And in this case, you use the "eval" keyword as showed in my previous example. Unfortunatelly, to avoid language ambiguities, we can't support arbitrary expressions without a markup keyword, and "eval" was the chosen keyword. []s Edson 2007/8/10, Manukyan, Sergey <SManukyan(a)lear.com&gt;: Thanks Edson for workaround, IMHO that looks like a limitation to me, is there a particular reason why left side should always be a field? -Sergey ________________________________ From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Edson Tirelli Sent: Friday, August 10, 2007 11:58 AM To: Rules Users List Subject: Re: [rules-users] bug or feature not yet implemented Sergey, That is how it is supposed to work. A field constraint in Drools always has a field at its left side. If you want arbitrary expression, just embed it in an inline eval: S : Supplier( $sts : supplierBusinessStatus.businessStatus, $csts : corporateSupplier.supplierBusinessStatus.businessStatus, eval ( $sts != $csts ) ) Although, for this specific case, it would be better (more performatic) to simply write: S : Supplier( $sts : supplierBusinessStatus.businessStatus, $csts : corporateSupplier.supplierBusinessStatus.businessStatus != $sts ) []s Edson 2007/8/10, Manukyan, Sergey <SManukyan(a)lear.com >: Folks, I found that drools 4.0GA doesn't recognize variables in the left side of operator expression Like this produces error: When S : Supplier( $sts : supplierBusinessStatus.businessStatus , $csts : corporateSupplier.supplierBusinessStatus.businessStatus, $sts != $csts ) Then ... It tries to treat the $sts variable as a field of Supplier, instead understanding that it is a variable declared earlier, Please advise, Thanks, -Sergey ********************** ** LEGAL DISCLAIMER ** ********************** This E-mail message and any attachments may contain legally privileged, confidential or proprietary information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this E-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this E-mail message from your computer. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli Software Engineer - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11 9287-5646 JBoss, a division of Red Hat @ www.jboss.com _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli Software Engineer - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11 9287-5646 JBoss, a division of Red Hat @ www.jboss.com