On May 1, 2009, at 5:21 PM, Ean Schuessler wrote:
I've been looking at the price rules code that allows you to reset
the price to the promotion price under certain conditions. I have a
situation where I would like to have several different price types
configured and then set the product price to one of those several
categories depending on a series of conditions. I wish that there
was a type of ProductPriceAction that would allow you to reset the
price to a PriceType based on a string passed in with the rule.
Unfortunately, ProductPriceActions only allow you to specify an
Double amount. I sort of wonder why this is not a string value that
could serve a variety of functions depending on the rule.
In a broader view, I'm frustrated with the primitive microlanguage
of the price rules. I wish for Drools style specification with full
language features. Drools is BSD, ya know, could we go there? Please?
One of the goals of the current price rules is to make them
configurable by end-users. Admittedly they are somewhat complex so it
takes a savvy person (in terms of business and logical thinking) to do
this. However, through the existing UI you can click through options
and get your price rules configured.
This kind of relates to the discussion going on right now around
security. The trick with either of these is that we don't want to
require coding in order to set things up... but we do want to support
dropping down to code when needed to supplement the configuration
options (since it's impossible to anticipate and handle every possible
complexity).
So, maybe we should change the calculatePrice service so it supports
evaluation conditional expressions (with JUEL or drools or whatever)
and invoking action scripts. We could add a price rule condition type
for an expression, and a price rule action type for action scripts.
On the other hand, we could try to go the other way and have the price
rule configurations drive the generation of the drools code and then
also allow other rules associated with the ProductPriceRule record to
be added to the mix before the rule set is processed.
I'm not sure which is better... The first option is probably easier to
implement and to control/debug/etc. The second one is probably more
flexible.
-David
