Consider Views' configuration paradigm of a {"view"} having a {master "display"} and {overridden "displays"}. We could make each {"rule" have a master "configuration"} and {overridden "configurations"}.

This idea, as I conceive it, depends on #1498834: Facilitate rule configurations made entirely of components...

Each rule could contain reused components, as well as, overrides and their own additions. I doubt I need to reexplain views displays and overrides, but the mobility of components would be a bit different.

Just in terms of testing as you build a rule, for example, if you started knowing that you want to react on user login and that it should say something and send a remote web request. You could try different things with the same master configuration of the event, so with one non-default configuration work on the message display and another the web call. Each could be debugged individually, then combined.

This would also be useful for humungous rule configurations, because the exported/imported code could be much simpler which I think would also come from the other referenced issue.

Comments

mitchell’s picture

mitchell commented
Issue tags: +Needs mockups
dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
commented

i'd much rather do #1269884: Inline rules support, so instead of overriding rules you can have different implementations of logic within decision trees inline.

also, in views a master display is made of a large number of components that can be overridden individually by other displays.
what would the equivalent in rules be? override a the whole event/condition/action tree or just single items? if you go down to overriding single items, you would need to add identifiers for all of them

mitchell’s picture

mitchell commented
Title: Allow rules to have default states and overrides » Create "master_defaults_overrides" branch
Project: Rules » Rules UI Mockups
Version: 7.x-2.x-dev »
Component: Rules Engine » Code

in views a master display is made of a large number of components that can be overridden individually by other displays.
what would the equivalent in rules be? override a the whole event/condition/action tree or just single items?

That's one of the planned benefits of #1498834: Facilitate rule configurations made entirely of components... I need to rework that issue to make it clearer, so please either read into it deeper, through the gaps, or wait for that update.

if you go down to overriding single items, you would need to add identifiers for all of them

Wouldn't it be only for non-default plugin instances? I would think that simple plugin instances could be attached to the master display without any additional configuration.

Dasjo, ...by all means, if you can evaluate this idea more thoroughly from the API side, that would really help me think through what the UI might look like and what other API changes might be necessary.