RL2 Rule sets + prevent / ensure

[Stray]

Something we've chatted about and decided was a better solution than people making adhoc mappings, was the ability to wire whole rulesets to application state changes (events, signals, messages etc).

@tdavies has a valid use case for changing the mediators on buttons during an app-state-change which doesn't involve them being removed / added. He has a workable solution involving a state-pattern and delegating to sub-mediators inside his mediator, but it reminded me that RuleSets really are worth implementing.

I'm going to go ahead and TDD some stuff around this as it's technically quite difficult to implement.

As a starting point I'm going with usage something like:

1. Create a subclass of RuleSet
2. Within your class override the ensure() method.
3. Within that method you do mappings and unmappings, apparently as normal, on installed extensions.

I ditched prevent because ensure with unmapping is the equivalent.

My initial thinking is that extensions would need to support this individually and explicitly via some kind of utility class that replicated the interfaces on the extension but with Robotlegs-magic™ under the hood.

I'm already seeing some issues I'm going to run in to (dsl chain completion etc), but I'll tease that stuff out in the TDDing.

There's also an issue around how we get access to those magical-classes in the RuleSet itself - I'm thinking something like a custom provider for RuleSets @tschneidereit ? That would make sure that the injection points for mediatorMap etc are fulfilled with the Robotlegs-magic™ ruleset instances and not actual injector / mediatorMap etc.

Please chip in with any early requests / caveats / thoughts.

[tdavies]

Just being awkward as normal :) While I partially understand at least some of the reason against it allowing remapping of mediators for views on the stage would do exactly what I need. I had actually assumed that you could do this until I tried it. It would mean no additional API's etc. and seems the simplest solution but then my knowledge of the whole system is somewhat limited.

[Stray]

Hi Tom,

the problem is that there's no way of knowing whether someone wants to change the rules for the future, or to apply them to everything immediately.

In most cases when someone removes a mapping they don't want it to be immediately applied - at least that has been our experience in that most people have been happy with the default behaviour in RL1.

You can always fork-and-fix it though :)

[Stray]

Btw - the situation with RuleSets would be that they always applied immediately.

[Stray]

These are a post-release feature to be added. Currently thinking:

1. Each extension / map will need to have a class that enables this - a wrapper for the real map.
2. Need to look closely at how the 'apply immediately' side of things is implemented - eg for mediators.
3. Need to think more about sealed mappings.

[darscan]

Closing as "out-of-scope"