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 <dsotty(a)gmail.com> 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 <michael.anstis(a)gmail.com> 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 <stephen.masters(a)me.com> 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
>> rules-users(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users