Proposal: multiple price class rules

[Ean Schuessler]

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?

--
Ean Schuessler, CTO Brainfood.com
[hidden email] - http://www.brainfood.com - 214-720-0700 x 315

[David E Jones-3]

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

[Ean Schuessler]

----- "David E Jones" wrote:

> 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.

It might be a nice compromise to have the web GUI interface output code that is compiled by a more featureful rules engine. Then you could have an "expert" mode that lets you write conditions and actions directly or use the more simple CASE tool if that's where your skill level is at.

--
Ean Schuessler, CTO Brainfood.com
[hidden email] - http://www.brainfood.com - 214-720-0700 x 315