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.vanhoenshoven(a)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-...
Sent from the Drools: User forum mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users