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] > <mailto:[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] >> <mailto:[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] <mailto:[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
