Allow components as conditions

+1

I think this is a good idea, but I think it is better to have a dedicated "condition rule set" or something – not to use general components that return a boolean.

There are component sets... but you did say you wanted iteration through abstraction (kinda), so it seems you mean #1495718: Add option to convert a set of conditions or actions to a component, or more generally, #1498834: Facilitate rule configurations made entirely of components... Right?

If not, please reopen the issue and explain a bit more. Or if it is, please give feedback in those issues. Thanks!

Yea.. um.. :) Disregard #4.

Best I can tell from trying to read over and trying to understand the nature of the previous issue, this request is for a new condition component used specifically for list operations that wouldn't need to be run as many times and would be more intuitive to configure than current methods. Expounding on this would be appreciated (for us non-programmers) and help toward preparing the docs, which will likely go into a child page of Lists and loops.

+1

Rules Collections appears to solve this. The git application has more info: #1968118: [D7] Rules Collections.

@fago: Do you like the sandboxed code and class refactorization described in [D7] Rules Collections: Why not make this a patch to Rules for providing this functionality?

@all: Am I reading this correctly? The "complex evaluations in conditions" that "allow iterative analysis of conditions" through "looping in conditions" appears to be solved with these ANY / ALL operand plugins. What are your evaluations?

@mitchell: I think your description is correct.

(I was expecting that this issue would discuss running conditions inside loops, which I find useful sometimes, but that must have been another issue.)

I must say I like the functionality. I'm not sure how useful it is for the average rules user, but I can definitely see it being useful.

Why not make this a patch to Rules

Integrating this directly into Rules would be tricky. To do it properly there would be some refactoring necessary in Rules' core. For example, the UI plugin for the Any and All loops is derived from RulesLoopUI which is a RulesActionContainerUI not a RulesConditionContainerUI and then the functionality of RulesConditionContainerUI (a negation checkbox) is bolted on. Similarly, the code in the base class for Any and All is genetically related to both RulesLoop and RulesConditionContainer.

afaik, it uses the action UI plugin in conditions - so yep we'd have to fix that for inclusion in Rules. I'd be happy to discuss necessary re-factorings. We'd have to watch out to keep the API stable though.

Nevermind i found the solution of my problem

It's https://drupal.org/project/rules_list_conditions now.

It's not something that comes up every day. It should likely stay a separate module just for that reason.

But I've found it invaluable for dealing with Drupal Commerce, where I regularly have to insert (often confoundingly) complicated business logic for enabling shipping methods and providing special handling of some orders after they're placed. It may not come up too often but when it does it's really difficult to massage rules into handling the case and I'd usually end up just inserting a PHP blob to do the checking, which is always a bummer since it usually means doing the stuff that would be simpler to do with rules in the blob as well.

I'm not sure how you'd go about refactoring Rules to make implementing this sort of thing easier without having a RulesConditionLoop(UI) that was basically a carbon copy of RulesLoop(UI) or moving to a less inheritance-based hierarchy where there's a lot of interfaces and composition, but I don't see any way to do that and remain backwards compatible.

Ultimately you'd need some way to implement the looping part of RulesLoop(UI) separately somehow and just have RulesLoop(UI) call that and have a similar stub for RulesConditionLoop(UI).

I'm not really an expert on Rules codebase, though. I only did enough spelunking to figure out how to do what I needed.

No patch, so nothing to review ...