You can make CLIPS (or, IMO any rule-based system) easy to use like this in one dimension, but not the dimension you want. For example, I had a system for diagnosis according to DSM-IV criteria. It had a nice interface for users to enter new "facts", which the rules would then run against. But, allowing users to be able to add new rules (and preserve the existing dependencies and logic) would have been way more difficult (or impossible).

How about the "standard" way of solving this? From your description of the problem, it's exactly what OO programming is about. You create business objects in clean OO code, and give them methods that model the business rules. The methods only allow the various operations to go through if whatever criteria is met. This is a really clean way to code, and yeah - you need an OO programmer to maintain it. But, the problem itself requires it, I think.

I definitely agree with Perrin. The most effective, usable system is going to be a framework that allows you to glue together concise, targeted bits of code. You can't beat the power of Perl for scripting complicated interactions between little bits of data.

We use XML::Comma for managing web-site user profiles, mailing list systems, content archives, etc. We haven't done quite this kind of shopping cart, but it's a pretty good fit.

In Comma, you write document definitions that specify data structures, constrain the contents of the parts of those structures, and govern how data is saved in filesystem- and database-backed storage. There's a pretty extensive API for manipulating both individial documents and collections of docs.

You always hand-write the definitions -- that's the core exercise of figuring out basic data structures and behaviors. Writing defs feels like a kind of OO mating ritual: XML on one side, perl on the other, and between the two of them a Class is born.

Most of our systems are built to assume completely tools-generated docs (for various definitions of "tools"). You can write docs by hand, and for your shopping cart system you might want to. For instance, creating a new "item" in the product catalog could be the job for a decent programmer who understands something about how the system is used but doesn't have much knowledge of the internals/architecture/subtleties.

Anyway, I threw together a bit of Comma stuff showing how you might structure your widgets & gizmos example. Whether or not you want to look more at Comma, it might provide some more food for thought. There are a few example "item" and "customer" docs, followed by defs for "item", "customer" and "cart".

<item>
  <name>widget</name>
  <base_cost>250</base_cost>
</product>

<item>
  <name>gizmo</name>
  <base_cost>125</base_cost>
  <cost_hook>
    <apply_order>100</apply_order>
    <!-- buy three widgets, get a gizmo free -->
    <cod><![CDATA[ 
    sub { 
      my ( $cart, $item, $customer, $cost ) = @_;
      if ( scalar(@{$cart->elements('widget')}) > 2 ) {
        return 0;
      } else {
        die;
      } ]]></cod>
  </cost_hook>
  <!-- buy 10 widgets, get $30-off per -->
  <cost_hook>
    <apply_order>110</apply_order>
    <cod><![CDATA[ 
    sub {
      my ( $cart, $item, $customer, $cost ) = @_;
      if ( $cart->number_of('gizmo') > 10 ) {
        return $cost - 30;
      } else {
        die;
      }
    } ]]></cod>
  </cost_hook>
</item>
[download]