Aha! That's exactly the sort of syntax I was looking for! :)
I just couldn't find any examples of the DRL syntax for 'creating' a value like
that in the LHS. A quick test with a contrived little example shows me that the
following works:
rule "Warn when my meal is too large"
when
$meal: Meal($calories: calories > 1000)
$unit: String() from "calories"
then
insert(new MealTooBigWarning("That meal is bigger than your 1000 " + $unit
+ " limit."));
end
So, based on that I'm able to write a DSL like this:
[when][]I am given a meal of more than "{sizeLimit}" "{unit}" = $meal:
Meal($size: {unit} > {sizeLimit}); $sizeLimit: Integer() from {sizeLimit};
$unit: String() from "{unit}"
[then][]Warn that the meal is too big = insertLogical(new
MealTooBigWarning("That meal is bigger than your " + $sizeLimit + " " + $unit +
" meal limit."));
Which means that I can write DSLR like this:
rule "Warn when my meal has too many calories"
when
I am given a meal of more than "1000" "calories"
then
Warn that the meal is too big
end
… which gives me:
That meal is bigger than your 1000 calories meal limit.
Or this:
rule "Warn when my meal has too many diet club points"
when
I am given a meal of more than "11" "dietClubPoints"
then
Warn that the meal is too big
end
… which gives me:
That meal is bigger than your 11 dietClubPoints meal limit.
So I can define an enumeration:
'MealSize.units': ['calories=calories', 'dietClubPoints=diet club points']
So that in Guvnor, I have a single sentence with a drop-down menu containing
the options "calories" and "diet club points". That keeps things nice and clean
for the users.
Thanks for the pointer.
Steve
ps - My 'real' application is validating different types of exposure limits for
a hedge fund, but the examples above seemed a bit more readable for anybody who
doesn't work for a hedge fund. :)
On 4 Jun 2013, at 17:18, Davide Sottara <[email protected]> wrote:
> The usual (and only reasonable way) to "set" a variable in the LHS is to bind
> it to a Drools variable,
> including things like:
>
> ...
> $x : String() from /* expression here */
> ...
>
> any usage of the "=" operator is generally suspicious..
> but I'm not sure I have understood your use case completely.. :)
>
>
>
> On 06/04/2013 05:59 PM, Stephen Masters wrote:
>> Thanks for the cheat idea Mike. I wasn't really expecting any help from the
>> tooling itself. Just hoping that there might be some trickery within the DSL
>> that I could try, to generate some code which would set up a variable for me.
>>
>> Unfortunately I do need to combine LHS sentences and multiple RHS sentences,
>> so your idea isn't really an option in this case. :(
>>
>> As it is I have created a little enumeration in the RHS sentence, and it's
>> not looking too bad. At least, with some selective wording, it doesn't look
>> completely redundant!
>>
>> Steve
>>
>>
>>
>> On 4 Jun 2013, at 16:33, Michael Anstis <[email protected]> wrote:
>>
>>> This would need to be provided by the tooling; I don't think it's something
>>> that's even remotely possible at runtime (unless you stored the field name
>>> in a Fact and used reflection on the RHS).
>>>
>>> That said (and you're going to guess my next comment) this is not provided
>>> in the guided editors. Depending on how complex your DSLs are and whether
>>> users need to combine DSL Sentences; IDK if a "cheat" works:
>>>
>>> [when]Do something with {field} and {value}=$f : Fact({field}=={value} then
>>> $f.{field} = {value}
>>>
>>> I've not tried it; nor know whether it fits your requirements.. but a hack
>>> worth trying?
>>>
>>>
>>> On 3 June 2013 17:40, stephen.masters <[email protected]> wrote:
>>> Hi folks,
>>>
>>> Is there a decent way to set a value in the LHS of a rule so that it's
>>> available in the RHS?
>>>
>>> Reason being I have a DSL driving the guided rules editor which will pluck
>>> out the value of a field, where the name of that field is driven by a drop
>>> down menu enumeration.
>>>
>>> A change I now have would be a lot easier if I could assign a string to a
>>> variable in the LHS, which could be read by the RHS. Otherwise I might need
>>> to extend the RHS DSLs to include the same enumeration as the LHS. Which
>>> looks a bit redundant for a business user wondering why the need to write
>>> the same thing twice.
>>>
>>> Any thoughts?
>>>
>>> Steve
>>>
>>>
>>>
>>>
>>> Sent from Samsung Mobile
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> [email protected]
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> [email protected]
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> [email protected]
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
