Discussions

Decision engine Rules vs CA

This a starter post for the discussion on the Rules vs Conditional Actions debate that comes up whenever Ubercore is discussed.

The current thought is to make the system work with both and start with CA as it seems like an easy port. (Jody and Mike are taking this on:

We all agree that we want to support rules as soon as there is something to support.

Tim
Posted: Nov 20, 2009

Comments

jody on November 21, 2009

It seems like there are lots of great reasons to use Rules, but the biggest argument against it is the fear that relying on it for critical Ubercore functionality will significantly slow down Ubercore release.

I pinged fago to request his input here.

fago (not verified) on November 24, 2009

hi! thanks for pinging me!

I'm already working on rules2 for quite a while. I try to give you a short overview.

With Rules2 the internals work object-oriented, which allowed me to redesign the API to be much more flexible and modular than before. This was necessary to be able to easily integrate new features like loops and lists. However the API for writing conditions/actions/events hasn't changed much, it's basically staying I'm just trying to clean it up where possible.

I've the API mostly done, I think I'll have something workable till the end of the week and plan to have it completely done with all features like scheduling and so on 1 or 2 weeks later on.

For the UI though I expect a first usable version with the end of year.

If you are interested check out the code at github: http://github.com/fago/rules As I write tests for mostly everything, the tests are a good place to see how things can work now.

Some other design goals for rules2:
* Make the components (conditions/actions/..) better reusable on it's own, so modules can easily integrate them.
* Make the rules engine itself more modular and extensible.
* Provide UI components that can be easily reused.

Thus it should be able to make use of rules while integrating with a own UI easily. This should help a lot if you want to do a deep integration with ubercore.

So I'd love to work with you together to make sure rules is usable for you as you need it. Also instead of doing new developments for CA please consider joining forces with rules, talk to me about what you want to achieve and I'm sure we find a good way to go. That way we could not only avoid duplicated efforts for the rules engine, but also a lot of duplicated efforts in doing module integrations for two basically equal systems..

Joel Stein (not verified) on January 18, 2010

I see several big advantages of depending on and building upon Rules, many of which are outlined here. But just to throw out a couple more...

1) It's to the point now where I can manage nearly all of my business logic through the Rules interface. Occasionally I have to touch PHP, but when I do, it's very easy to create the Rules event/condition/action in a custom module, and then use the UI to manage the logic. This is especially true with the new Rules Forms integration, which exposes validation and custom form handling, all through the UI. It's wonderful.

2) Since so many other modules are using Rules' API, there is a high level of interaction which various Drupal events which will not be available to Conditional Actions. In other words, using Rules allows stores to be more tightly integrated and customizable through the interface than is possible with Conditional Actions.

3) Since Conditional Actions only concerns itself with Ubercart/Ubercore/Commerce, it will never evolve like Rules will, which concerns itself with the holistic Drupal experience. It does one thing, and it does it very well.

I'm not too concerned about the fact that the Commerce package will require a dependency. The flexibility afforded with using Rules will far outweigh any cons. Plus, if you poke around in the issue queue, you'll see that the Rules maintainer is fast, efficient, well-tempered and very interested in cross-module integration (its very nature depends upon working well with other modules). With all due respect, I doubt we'll get to a point where Commerce is developing and evolving so rapidly that Rules can't catch up.

geerlingguy on January 19, 2010

I am also strongly in favor of Rules as the only interface; The more sites I've built, the more I've relied on Rules to manage most of the condition/event parts of the site. Since I typically build in a store after the main site development, it's always messy trying to then jump into Conditional Actions (which is sometimes missing some key event conditions that I can get in Rules) to finish up the rest of the site...

servantleader (not verified) on January 26, 2010

If it comes to a point of having multiple solutions for e-comerce in Drupal, there is no doubt that integration with Rules would give this initiative a decisive 'competitive advantage' especially with developers deciding what to contribute to/integrate with.

Having built many complex sites using UC, I must admit that the limitations of CA was by far the greatest frustration in the process. This is because I have mostly worked on complex use cases (particularly conference/event registration). I have spent much time putting logic into custom modules that could have easily been implemented in rules because of the number of modules it integrates with.

Example: If add to cart were an action in Rules, then we would automatically have integration with Views Bulk Operations which would allow for complex views with a ‘add all selected to cart’ button while allowing complex validation logic on each product.

I am exited about this project and will be looking for ways to help in the near future.