as a programmer using rules i often miss the possibility to just add "if-then-else" branching within a set of actions in rules.
Currently, one would implement this by adding two components: one for the if-branch, another for the else branch. unfortunately both components need to be administrated separately, though using yet another condition-set component might help centralizing the administration of if-then-else conditions again but we end up with 3-4 rules/components for just a simple if-then-else branching.
from an UX perspective, i think it would be crucial to streamline this approach. on the other hand i understand that rules separates the list of actions from the list of decision consistently and we might end up with some confusion combining both of them in order to realize an "if-then-else" action.
we could have an "add branching" or "add if/else" in addition to the "add action" and "add loop" links. this would automatically create a special rule plugin that has a condition plus two if and else branches or like the switch statement allow for creating multiple condition + action compositions (cases).
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | rules-inline.patch | 430 bytes | fago |
Comments
Comment #1
delykj commentedsubscribe
Comment #2
fagoyep, being urged to create a component just to be able to do what you want sucks. You'll end up with meaningless components.
Maybe we should allow inline-rules? Attached patch allows them - we'd have to fix the UI though :D Best, we'd hide the actions and conditions from the overview, such you have to click edit to be able to edit it (just as for rules sets). Then make the name optional, e.g. have it to default to "inline rule" or so.
Comment #3
dasjojust brainstormed with fago
a good approach to solve this might be inline rules. this would create a "add rule" option besides the "add action" and "add loop" links.
open usability questions:
how should such embedded/inline rules look like in the interface?
minimal - show only inline rule name
this leads to the question, if inline rules need a name anyways? we might have the inline rule name optional and just show "inline rule" by default which on mouse hover displays the rule export.
extended - allow to display inline rule details
this might bloat up the interface. so we might want to have the minimal version by default and the edit button might just complete to the extended interface by doing an ajax request.
Comment #4
dasjorestore tags
Comment #5
mitchell commentedDasjo, I would like to steal your issue for a while, but I also want to make it a bit more touch-n-feel in addition to your descriptions. This way we can try to answer questions like:
And we can also look for the implications of the design for other changes and also track how these changes relate to other issues.
When's a good time to catch you on irc? I'm happy to setup the mockups or help you get started with the same tool I'm using.
Comment #6
mitchell commentedI don't like the idea of inlining rules, because a rule could potentially be configured to run from multiple rules. In that case, it would be better to click on the component to edit it directly. One way this might come out is where an embedded rule might have pseudo events for when a "rule is about to execute" or "rule is about to finish" with a condition. It would then appear in multiple rules. See also #1525588: Looping: add recursion or tail recursion.
Comment #7
zhangtaihao commentedI've tried implementing inline Rules (in the sandbox that Conditional Rules grew out of). Although it probably would've worked API-wise, the UI controller was a bit limited for nested UI to work properly.
In a nutshell, the UI controller displays a form for an embedded element by using the root element to navigate down to the embedded element given an ID. So, it will only work as far as the embedded element can be enumerated as "children" of the inline rule. So, when I tried to embed a rule inside another rule's action container, the default "AND" container showed up in the parent rule form (which is not desirable, but may be alleviated (!?) through #1666802: Keep embedded elements under compatible containers in container UI).
However, when I tried to suppress the condition from the "children" set, the nested UI stopped working because the RulesElementMap had no way to get to it, and thus the controller had no way to get to it.
I toyed with the idea of nesting a special controller. However, this isn't going to work either (at least not brilliantly) because these controllers would then need internal controllers for any compatible embeddable elements.
Just my 2 cents.
Comment #8
zhangtaihao commentedChanged the component by accident.
EDIT:
Or maybe not.
Comment #8.0
zhangtaihao commentedminor