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.
Comments
Easy port or easy use ?
Hi,
I would suggest rules because this is the killerapp when you are looking for a condition / action module. And it would be totally inline with the Ubercore philosophy to develop friendship with other killer modules.
In addition, rules have a better UI and working with this module will open an ubercore integration with all others modules that already using rules. (change a product price when joining a group ?, add a product to the cart when changing a theme,...) don't know but the possibilities can be huge without writing our own integrations for CA.
So, when you think to all possibilities it can offer, it's a far easier task to write the Ubercart rules into rules module that write all contributed modules rules to CA
The module have a very good support in addition. Known as workflow-ng for 5.x, Fago always supported it very well and it will be supported forever with the large number of user it have.
So, better UI, more flexible, well supported. Except the developping time I don't see any reason to continue to deal with CA.
After that, I don't know the change made between rules for d6 and the next rules for d7 (which subscribed to the d7cx initiative). But maybe it would be good to work on another things until a first 7.x dev version of rules would be released to see all the major changes and take a decision knowing all the facts.
I'm not sure porting CA to convert it to rules later is not a lost of time, it's like porting Ubercart and working on ubercore at the same time ;)
Timeline
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.
rules..
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..
Excellent, wasn't aware of
Excellent, wasn't aware of the Git repo for Rules2. Will try to check it out, but can't make any promises with my currently crazy schedule. : (
Conditional actions UI
In terms of the usability of CA, Maarten Verbaarschott is on board to help us improve that.
Do we really want to him to
Do we really want to him to design a great UI for CA when we're planning to move to Rules?
+1 for this Maybe before
+1 for this
Maybe before working on CA UI, it would be better to be sure that Rules will not replace it.
In addition, even if Rules don't replace it in a very short deadline, it will replace it one day or another, so putting too much effort on a thing that will have a limited lifetime is probably not a good thing.
+1
No amount of work on the CA UI is going to change the fact that you end up with two different UIs for (conceptually) the same thing. An admin must not only know both UIs, but which to use for each case, and what works (or doesn't work) with what. They need to know the internal programmatic details of all the modules on the site in order to feel comfortable making basic administrative changes like altering the text of a notification. That's not right. And if CA doesn't work with something, then extra development to make duplicate code or adapters is needed. Wasted time, cost, and effort.
CA would be great if Rules didn't exist, and would be a good standalone module in that case. But with Rules existing as a standalone, it just complicates things.
Rules
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.
At this point, I'll also add
At this point, I'll also add that going with Rules will make a nice clean break from Ubercart so there's no confusion about the new direction of this initiative.
Amen! :) Maybe also use
Amen! :)
Maybe also use fago's entity API can be used. So, mong other dvtanges, the Rules integration if "for free".
^^oops, sorry for all the
^^oops, sorry for all the typos there :/
I am also strongly in favor
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...
Rules would give this initiative a decisive advantage
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.