[rules-users] Possible to use functions in DRL when dialect is mvel?

[Wolfgang Laun]

In 5.4.0 (and 5.3.0) using an
   import function x.y.CloneMessage.cloneMessage
lets me compile the MVEL version even with separate files all into the
same package (as in your post). Without this import, using
   CloneMessage.cloneMessage(...)
works for me, also both versions.

HTH
-W


On 19/06/2012, Stephen Masters <stephen.masters at me.com> wrote:
> My understanding from the docs is that the DRL functions are converted into
> helper classes, which can be imported with "import function
> mypackage.CloneMessage.cloneMessage", although it's not clear what that
> 'class name' (?) in the middle refers to. Maybe the generated helper class?
> However, if the function is in your current package the import is
> automatically derived for you. Hence no import statements in my tests. Which
> is nice. :)
>
> I just tried combining them in a single file, and it still fails for the
> same reason.  I'm still on 5.3.1 at the moment, so I think this might be a
> new item for my list of reasons to roll up my sleeves and upgrade.
>
> Thanks for taking a look,
>
> Steve
>
>
> On Jun 19, 2012, at 01:42 PM, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>
> It works (5.4.0) with both, Java and MVEL, if all is in the same DRL file.
>
> I'm somewhat surprised that "import" should work for DRL functions,
> but I may have missed some development. But your snippets don't show a
> DRL import statement?
>
> -W
>
>
> On 19/06/2012, Stephen Masters <stephen.masters at me.com> wrote:
>> Okay Wolfgang ... you asked for it. Here's a version which takes it pretty
>> much to the minimum.
>>
>> The error I see is "Unable to resolve method using strict-mode:
>> mypackage.CloneMessage.cloneMessage(mypackage.Message)"
>>
>> However, the error is only seen when I use mvel dialect. The working Java
>> dialect rule is also included below.
>>
>> Note that when I re-wrote the example function to take a common type such
>> as
>> String as argument, then the mvel version worked. It's when the argument
>> is
>> a declared type that it fails.
>>
>> Thanks for taking a look,
>>
>> Steve
>>
>>
>>
>> file - MessageFact.drl
>>
>> package mypackage
>>
>> declare Message
>> Text: String
>> end
>>
>>
>>
>> file - CloneMessage.drl
>>
>> package mypackage
>>
>> function Message cloneMessage(Message originalMessage) {
>>
>> Message newMessage = new Message();
>> newMessage.setText(originalMessage.getText());
>> return newMessage;
>>
>> }
>>
>>
>>
>> file - SayHelloRuleJava.drl
>>
>> package mypackage
>>
>> rule "Say hello"
>> dialect "java"
>> lock-on-active true
>> when
>> # Always
>> then
>> Message originalMessage = new Message();
>> originalMessage.setText("Hello, World!");
>>
>> Message clonedMessage = cloneMessage(originalMessage);
>>
>> insert(clonedMessage);
>> end
>>
>>
>>
>> file - SayHelloRuleMvel.drl
>>
>> package mypackage
>>
>> rule "Say hello"
>> dialect "mvel"
>> lock-on-active true
>> when
>> # Always
>> then
>> Message originalMessage = new Message();
>> originalMessage.Text = "Hello, World!";
>>
>> Message clonedMessage = cloneMessage(originalMessage);
>>
>> insert(clonedMessage);
>> end
>>
>>
>>
>> On Jun 19, 2012, at 12:27 PM, Wolfgang Laun <wolfgang.laun at gmail.com>
>> wrote:
>>
>> Can you please provide an example where and how you import and use a
>> DRL function so that it works/doesn't work with MVEL/Java?
>>
>> -W
>>
>>
>> On 19/06/2012, Stephen Masters <stephen.masters at me.com> wrote:
>>> Hi folks,
>>>
>>> Is it possible to refer to DRL functions from a DRL when the dialect is
>>> mvel?
>>>
>>> I have been working on unit tests for a rule that were consistently
>>> failing
>>> due to not being able to find the function that should be imported.
>>> Having
>>> tried various formats (the documentation is rather unhelpful here) for
>>> the
>>> import, I thought I'd see what happened if I just switched to the Java
>>> dialect. Suddenly it worked without even needing an import statement.
>>>
>>> Unfortunately, this forces me to switch from the neat ...
>>> newFact.Property = otherFact.Property
>>> ... to the rather ugly Java-style
>>> newFact.setProperty(otherFact.getProperty())
>>>
>>> So I would quite like to know if there is an undocumented (or
>>> well-hidden-documented) mechanism for using functions when in mvel
>>> dialect.
>>> Or am I stuck with switching to Java?
>>>
>>> Thanks in advance for any pointers anybody can provide,
>>>
>>> Steve
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>