----- "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 [email protected] - http://www.brainfood.com - 214-720-0700 x 315
