10x Ryan for the quick reply - it makes sense what you wrote...
While reading I realized we actually might be able to enjoy both worlds -
1. CA events can trigger Rules.
2. We might be able to automatically create Rule actions/ conditions based on the API of CA - so a user can decide which module to use.

I'll keep my eye on this issue and we'll try to make it happen

hm, it's sad that you go on and create your own solution instead of relying on a existing one

>We could, as was suggested, help out instead with Rules and make sure folks can port their code from Workflow-ng to Rules...

I think you got something wrong, there will be a straight upgrade path from workflow-ng to rules supporting even changed conditions/actions.
Of course there was also an upgrade from 1.x to 2.x - I don't noted that ubercart has troubles with workflow-ng 2.x - which can't be really serious as workflow-ng 2.x is nothing more than a little improved 1.x version, which is of course compatible with it. If you'd have contacted me, I'm sure we would have been able to fix the issues.

About UI integration:
* Rules comes with a well founded API - so it would be no problem to create your own UI on top of it.
* I think it wouldn't be hard to integrate in another place the existing UI either.

Rules comes also with a new concept: Rule Sets, which could be compared with subroutines.
They can be used for customization, so you don't need to create events when there aren't really one. Instead you could ship with a default rule set, which users then can customize by adding/changing rules.

Anyway it looks like the decision has been made

@fago: Hey fago, thanks for stopping by. As I mentioned above, we're very grateful for your work and don't want to discourage you from continuing to innovate and improve your system. We just had to decide whether to keep depending on an external module for an essential core feature or roll the necessary functionality into core with a system that is similar but more suited to our needs.

For example, we offer in core a basic product list and a basic catalog. Either one of these is possible in Views with much more flexibility, but we know that new users to Drupal and Ubercart would expect at least some sort of store product listing. To that end, we provided a basic solution so folks aren't overwhelmed.

However, we also provide integration so users wishing to take advantage of Views (who doesn't? ) can still do so. We want people to be able to use the best tools possible in building their Ubercart sites. However, we don't want the core of Ubercart to be restricted by an external dependency. It's just not something we can govern or troubleshoot as easily as we can a core file. (And when I say "restricted", I don't mean the external modules are inferior or incomplete, but rather they have different use cases than what we might need to accomplish in core.)

So, I still think a contributed module can easily integrate UC w/ Rules, especially since it seems we'll both have similar hook structures and requirements. In fact, I'd be quite interested to see it happen.

@zmove: Ideally, the things Ubercart needs in its core will be easier to accomplish with the new system - defining complex taxes, shipping rules, and automated order processing. We'll provide similar conditions for necessary things like checking/modifying user roles. However, for external integration that's twice removed (i,e, UC -> Rules -> OG), there would just have to be an extra step in the form of a CA action that invokes a Rules trigger.

The CA system in core uses a similar enough hook structure that UC modules won't have a problem using the new system with little conversion. I don't expect third party modules to integrate with Ubercart's CA system in their core, though they'd be welcome to do so. Instead, it would seem like a module could function as a lightweight bridge that maps CA into Rules or vice versa. I think we'll just have to see what needs/use cases pop up as the project moves forward.

----

The real clincher here, too, is speed of development. A Drupal 6 version of UC is almost ready for testing, and we simply can't do that with Rules as is. It's hard enough integrating w/ complete, stable modules, much less modules that are still in alpha development.

thanks for your explanation.

>there would just have to be an extra step in the form of a CA action that invokes a Rules trigger.
I think using "Rule Sets" would perfectly fit here. Just do an action that invokes rule sets and you'll be able to use the whole power of rules.
Perhaps it's easily possible to make your conditionals available as rules condition too.

I have created a while back this issue - http://support.ubercart.org/case/80. I've looked in the code again. Converting back or at least adding rules integration seems a pretty straight forward task. It will even save the TODO of ca_conversion_page() from workflow-ng...

Again, if there will be an Ok from the Ubercart guys I'll be happy to help.

Great, I've started working on it, accept to see patches in Drupal.org soon.

Fago, in Ubercart they have the predicate concept. Basically it a predefined configuration of conditions and actions. The special this is that the predicate invokes another event. How should we do it in Rules?

I think differently. Let's take the organic groups module case. It has the core functions, but for lists it uses the Views module. In other words - you don't have to install Views, but its is recommended.

I'll project this to rules and CA. You may install ubercart, but for triggering actions you will need to install Rules.

Fago is a well known contributor, having a dependency on one of his modules IMHO is safe.

Anyway, as I suggested before, I'll help with any Ubercart's decision regarding this.

Hmm... very good points, zmove. Will keep that in mind as we figure out recommended usage.

hehe I understand. I am still interested in an actual code comparison, and not just a feature comparison. I understand that Rules has broader module integration and some more advanced features related to the setup of configurations, but it's been my experience that the code is not easy to follow. This presents a maintenance and scalability problem for us long term. We've tried to be as straightforward and small as possible with the code in ca.module that relates directly to evaluating predicates, and I'm curious if you have any feedback related to that.

The things that annoy me a little about CA is that, all "non ubercart related" features needs to be programmed.

Simple real recent example : I needed to check some informations about the user to calculate tax, especially user roles. In 5.x with workflow, it was possible through the UI. With CA, I had to hack the core to write some conditions related to users for orders. Ok, it was simple, it was quick, now it's done it probably will be added to the next release but, imagine you will have to rewrite for CA all conditions, actions that could be already integrated into rules.

And a module maintainer will that would want to add some trigger / conditions / actions functionnalities to his module will probably write an integration with Rules, not CA, because CA is only related to Ubercart whereas Rules already have lots of modules integration.

After that, I didn't look in the Rules code to see how it's done, I just saw that it was pretty simple to write some things for CA cause I wrote some users conditions, maybe this is a Nightmare to write things for Rules. But I know that I think the total amount or work will be higher if you want to write all features of rules into CA than integrating Ubercart conditions/actions into rules. But in the first case, the task is for Ubercart team, in the second case the task is divided among modules maintainers/Ubercart users...

thanks amitaibu for pointing to this thread..

I've just digged through the ca code. So I try to compare both modules:

First of let's compare the basic concepts:
* Your predicate is what in rules is a rule. In rules there is also the possibility to have default rules - like you have with your predicates. Btw. in theoretical computer science the term "predicate" is used for something else: http://en.wikipedia.org/wiki/Predicate_(logic) - which confused me at the beginning as I thought it might be a special kind of condition.
* Your "triggers" are what in rules are events. In rules, rules get triggered when events occur..
* Rules additionally provides rule-sets, a set of rule which is defined to work with some defined arguments. It's somehow like a subroutine and can be executed by action or code.
* It's also possible to provide default rule sets, which is useful for a module to come with some default behaviour which users can adapt. Events do not really fit here, as an event is just the possibility to react on. But the concept of an event, doesn't necessarily need a reaction or so.
* Rules works on top of variables, which always are of a special data type. Events provide variables, but actions might add new variables too. In workflow-ng this was similar, but variables were just called arguments everywhere. As far as I've seen you still work argument-based, but have removed features like allowing actions adding new variables from ca? Allowing actions to add new variables is really useful when you want to get related data from existing data, e.g. return the referenced user of a node, or the content profile of a user.

ok, let's come to the features...
* As mentioned, rules allows actions to add new variables, which then consequent actions and rules may use.
* Rules features the concept of input evaluators, which allows module to provide input evaluators to rules. Then those input evaluators can be used in every text input field of conditions and actions - so there is an input evalutor for PHP code in rules as well as an token input evalutor shipping with token. So rules work fine without token, but as soon as the token module is installed you can make use of token replacements everywhere...
* Rules comes with a generic scheduling mechanism, which allows you to schedule the execution of every rule set. So you can schedule the execution of every rule, condition or action... E.g. you could use that in ubercart to automatically decrease the price each day or so - all configurable by the user.
* Then of course there is a lot of useful integration for rules... E.g. there is CCK integration which allows you to compare fields or populate a fields value. Furthermore rules supports executing drupal core actions.
* Rules is written with performance in mind - so it's optimized for fast rule evaluation and intelligently deals with rules.inc files inclusion for the other modules.
* Rules has improved logging compatibilites working fine even with recursive evaluation of rules - which is important for people to debug rule evaluation.

ok, then let's talk about the code.
* Rules is basically workflow-ng, but I've rewritten and refactored a lot of it - so it's easier to extend and adapt it.
* Rules tries to separate different functionality in different parts, e.g. code for dealing with variables or data types sits in it's own include file and provides useful API functions. This makes the code easy to read, maintain and extend.
* Rules has an much improved data API, which allows to specify custom data types. Additionally to "old entities" of workflow-ng, rules covers simple variables like strings, numbers or dates and allows users to input them on configuration time. So one can add further data types that use their own input form on configuration instead of the usual mapping to a variable.

Of course, rules is more complex than ca as it has a lot more features. But I do care about high quality code and good factorisation, so the code is easy to read and maintain - as this is really important for me to.. E.g. the variable subsystem deals with loading/saving variables for actions - just relying on the data type's implementation to deal right with the data.. I've also done some simpletests ensuring rules evaluation works right. Then do not forget, I'm available for digging through the rules code if there would be any troubles...

It's really easy to write things for rules. Check the docs: http://drupal.org/node/298534
In comparison to workflow-ng I've worked on simplifying it - which let me create the input evaluation system. So you don't have to really care about integrating with token or so, it just works!

ok, let's consider how ubercart could integrate with rules:

* As discussed at the drupalcon, you could support invoking rule sets and add ing rule-sets returing a boolean as condition. So one could set up any rule set and fire it up by the integration. But as zmove already mentioned, it would be quite complicated to handle as you have 2 similar systems: ca and rules.

Integrating both systems seamslessy these way might get hard - as I've seen you also changed the "entity system". So you'd also need a mapping of data types.. Perhaps it would make more sense to use the same condition and action format, as well as the same data types. But anyway for both solutions, you would be able to use only a subset of available stuff or replicate the whole module...

So if you would completely rely on rules, you could do it this way:
* I think some of your "triggers" would be best implemented as a rule set. Just provide a default rule set and execute it out of your code.
a) You could lock the rule set and build your own UI for configuring it.
b) You could lock just on rule of the rule set, build your own UI for configuring this rule, but allow users to add further rules to the rule set through the rules interface
c) You could not lock the rule set and point at the rules admin page for editing the rule set for modifying it.
d) You could embed the rules UI into yours, which seamlessy makes use of the rules UI for editing rules. So once you edit a condition or action, you would make use of the rules UI and once submitted you get back. Furthermore we could modify the breadcrumbs during editing you they point back at the ubercart UI. So there are some possibilities for integrating the UI, I'd help here if I can. Of course I'm also open for rules UI improvements..

If having a dependency is a problem for you, you could also do it that way:
* Rely on rules as above, but don't force the people to install rules.
* If rules is not available, provide a simple alternative that takes the available rules conditions and actions provided by ubercart and allows a simplified configuration of those. Probably best you maintain a whitelist of your conditions/actions working with your simple alternative (e.g. by an extra hook).
* If one wants more, e.g. use tokens or using other conditions/actions one has to install rules.

So the simple alternative could fullfill basic needs, while people needing more can install rules.

thanks fago!
so, Ryan - what's the verdict?

Hi,

I understand your opinion I often have the dilemma concerning the use of a module, sometimes "too big" to do a little thing or writing my own submodule to do exactly what I need.

My Drupal experience make me lean more and more often on already developped module solution, at least, it depend on the module.

For example, instead of writing my own module for a taxonomy or node listing (like a catalog of products ^^). I try to do all things using views. Even if a customer want a product catalog exactly as the Ubercart catalog module provide. I do it with views, even if it's longer/harder.

Because there is all possible features around views, even if I don't use them for the listing I need. If, one day, I want to add some exposed filters or changing the display. It will be so easy and quick to do it with views than altering my custom module, and views is a "big" module that we can thrust. This is the same for Rules..

So, my decision often depend on the already existing module that can do the job. If it's a big module like CCK or views, I will choose this soluion because it's secure enought and it will provide a lot of extensibility.

I didn't know what to choose on the begining of that discussion because I didn't know Rules and CA. Now I test them both, I would suggest to use Rules instead. Maybe it will be a little harder to implement, a little harder to write custom rules/action, but You will be able to profit to all the drupal community work, and more and more modules write some integration with Rules. I even believe that CCK have some code for rules... And it will bring a lot more number of marketing possibilites for store owner.

Simple example : You want to change the theme of a customer that finished his checkout. With Workflow-ng (don't know for rules, didn't tested but I think it has been ported), it was easy, because switch theme had an integration with it, and Ubercart too... So you put "Customer has finished checkout" with Ubercart, and, you set your Switch theme action.

Imagine if you want to do the same job with CA now, you need to develop the feature, reinvent the wheel... Not sure it's simpler for user.

Globally, I think it's better to have a "little harder" coding, but need to use it rarely that have a "quite easy" coding and need to use it very often. In addition, I'm sure Fago will create us a nice documentation of it's not already done.

I hope it can help in your decision

For EU B2B tax calculation I am missing a condition check "User has role(s)". Is it still on your todo list?

TIA

@zmove, cha0s

Are you guys on IRC - maybe we can unite forces and create a battle plan?

Just want to voice my support that Rules should still be supported. Leaving that out limits Ubercart module design wrt. Drupal functionality.

Also, please write some CA API urgent. And maybe an article on how to upgrade from workflow-ng to CA so that we can upgrade our modules to Drupal 6.

+1 need rules integration! That would be so frickin awesome.

It isn't possible just yet. However, I did just create the custom PHP action for CA that you could use to trigger Rules events. I'll be posting a patch shortly once I've duplicated it as a condition.

Wrapped the patch up yesterday but forgot to post back here.

http://drupal.org/node/372384

Hi all,
I'm just starting to realise the power and potential of Rules, so a big +1 for a uc_rules module.

The fact that Ubercart doesn't want to reply on rules module as it is an extra dependency is more a symptom of a wider Drupal problem of packaging modules together.

Similarly Views and Token complement many modules - but if a Views or Token isn't already installed, the user has to download it separately.

I'm sure there is work going on to address that issue - so I'll have a look out for it.

Alan