Hello Frank, there is nothing wrong with your reason A and B. But the decision what to include in the "decision logic" is an engineering decision, and in engineering you always have a certain leeway within the margin set by mathematical or natural laws. Is maintenance easier if you have 2 rules where there is absolutely no decision in RHS code or is it better to have one rule plus a simple mapping function? What if this distinction must be made in a number of rules so that you have 2*n compared to n plus one function?
As for C, I just don't know how you envisage a "business user" and his or her capabilities. Understanding rules that go beyond the noncommittal "there is a thing with property X equal to x and property Y equal to y" is not something a layman can be expected to have at his fingertips. But, assuming this "business user" can read logic: there is not good reason why he or she shouldn't be able to understand a simple functional mapping. Cheers Wolfgang On 27/01/2012, FrankVhh <frank.vanhoensho...@agserv.eu> wrote: > Hi Wolfgang, > > Can I push you for a clarification on this statement? > > Imho, any of the following reasons is good enough to put a "decision" in > rules > A- The decision logic is likely to be subject to change > B- The decision logic is too complex to implement in a procedural way > C- The decision logic is making sense to business users. (i.e. > non-technical logic) > > In this case, option B is opviously way off. But one can only guess > regarding A and C. > > Regards, > Frank > > > laune wrote >> >> Oh my, aren't we a wee bit too dogmatic? I've certainly been known as >> being >> a stickler to style and best practice and what not, but in this particular >> case I'd use a single rule and offload the earth-shaking decision between >> 'Y' and 'N' into a function: >> >> rule x >> when >> samplefact1( $status: status, state == "CA" ) >> then >> fact0.setField1( yn( $status) ); >> end >> >> Cheers >> -W >> _______________________________________________ >> rules-users mailing list >> rules-users@.jboss >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/setting-different-value-in-consequence-RHS-part-based-on-a-conditional-check-tp3690826p3692750.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users