Support logic-based dialects (if/then/else)

hm, no. It would be easy to introduce something like ELSE in rules though - however I've not done it yet as I can't think of a clean way to integrate it in the UI.

I'd do it that way and just list:

Conditions:
...
Actions:
....
Else, Actions:
.....

So I'd add them at the bottom of the current rule configuration screen. However we would need new appropriate label: "Else actions" sure isn't. Any suggestions?

Another thing I plan for rules is tagging rules (-> categories). This is a feature we could backport to workflow-ng once it is in rules.

I'm not sure if this is absolutely necessary, because as the initial post states, it is possible, but it's ugly. However, for the sake of usability, this may greatly improve Rules's heuristics. And since it's already possible, then all it will take is creating another rules user interface :) perhaps this is 7.x-3.0 material.

Any suggestions?

Here's a start of some searching I did for UI mockups:

• How to Use IF Field in a Word Document

• Intelligent Lead Routing

• Business Rules (BR) Engine

• Use Word fields to customize your form letters

• WYSIWYG rule editor: create and test rules for any .NET type

• Adding an IfElse Activity

• Reaction RuleML

Additional note: I found this issue while adding #742402: Integrate Spam module with Rules module.

What do you think about using a structure like Switch?

Something like this:

1. When creating a new rule, you'd have an empty/true condition, and an empty set of actions to populate. If that is all you need, just throw in your actions and you're done.
2. If you have conditions you want to test, throw them in too (in the empty condition set).
3. If you have an if/then/else situation, create another condition set and another action set.
4. If you have an if/then/elseif/else situation, just keep adding condition sets and corresponding action sets.

I think a structure like this could help optimizing the performance of condition evaluation (http://groups.drupal.org/node/58283), and probably also make it easier to write complex conditions for Rules.

If taken one step further, you could apply these condition sets not to the rules themselves, but to the triggers the rules acts upon. "When content is saved, check any condition sets provided by Rules, and THEN invoke any actions/rules (if appropriate)."
However, this approach could be tricky since you sometimes want to have multiple action sets executed on one trigger – and thus you can't put them all in a single switch statement. ("First see if any fields should be updated. Then check if any e-mails should be sent.")

Those are my five cents of thoughts. I wish I could code PHP, so I could provide five cents of code as well. :-/

+1
If/then/else would be great

In addition to making a new UI, this would require refactoring the rules engine to support a whole nother dialect, called logic-based dialects (RIF-BLD). Reaction based rules (RIF-PRD) and logic-based rules can be represented in a single dialect (RIF-Core), however according to the W3C workgroup on rules, this only provides "limited rule exchange between logic rule dialects and production rules."

The use of separate dialects and limitation in unifying both implies that rules would need a separate backend to support logic-based rules. Fortunately it would able to take advantage of most of Rules's engine, UI API, scheduler, module integrations, and user base.

See RIF for more info.

Postponing this because it wouldn't be suitable for Rules 7.x-2.0, which is a more important milestone for now.

This issue should be broken out into separate issues, or meta-issues, for work on building a UI and refactoring the rules engine.

Hmm... why complicated? Keep your tree as the UI visualization:

Condition1: FALSE -> STOP
_________ TRUE *-> Condition2 -> FALSE: DO THIS
_________________________ **-> TRUE: DO THAT

* AND/NAND/OR/NOR/THEN
** to make it more interesting even more options could be granted

Implement a STOP action 1). You allready have the possibility to add steps and the logical operators in order to define whether there is a hierarchy/dependency between the conditions. (Bit of a mess. I hope you get the point anyway. I'd love to put it into practice but believe me, you don't want me to mess up your beautiful module with my overly poor php :)

1) I have been missing this option: my first query is very easy and takes << 1 ms to finish. But instead of stopping there the rule is forced to go through the whole rest where every single condition takes twenty times as long to finish.

CAVE: such an approach will require validation! A user mustn't be able to clearing for both conditions (ie several roles!) which is a bit of a mess to check, as many steps should be allowed in order for the revision to unleash it's full power!

BTW: The solution mentioned by in the intro is none. Spare the work. I have tried that and it doesn't work (I need the same), cloning and simply changing to NOT with condition and the action will cause both rules not to work: 'preventing recursion'!

Let's stay simple.

I agree with: Stay simple! You can use components that are firing other components for complicated rules.
But it would be great to use simply two actions sets - IF and ELSE.

Simple example:
IF ([node:field-date-for-publish] > now) {
DO (SET [node:status] = 0; SCHEDULE publish_action; SET MESSAGE "publish is scheduled") }
ELSE {
DO (SET [node:status] = 1; SET MESSAGE "content was published")
}

In the current situation i have to create two rules and if i need to change IF statements then i have to make double work. I think that this should not be a complex change of API or UI so it should not take a huge work. And also it can accept previously created rules - if there is nothing for ELSE so simple do nothing(let's say it is just optional).

#11: You could also introduce a boolean variable in the first rule, set it to TRUE if the rule is executed, and then check its value in the conditions for the second rule.

I think it is not a good idea with rules scheduler, but can be with "normally" executed rules.

I know this doesn't go into Rules, but perhaps Conditional Rules may be useful.

zhangtaihao: Hey, cool project! Didn't know it existed. Are you planning on a dev release?

I've added the release as soon as I promoted the project. Drupal.org mustn't have got to packaging it yet.

zhangtaihao: Awesome!

There's a setting on one of the project edit tabs, that turns on displaying dev releases. I think that's what's missing.

The release was packaged about 6 hours ago. I've turned on its display.

zhangtaihao: Great! I added the module to my little docs project over here: http://skillcompass.org/topic/conditional-rules

Looking forward to trying it out.