[CAUSEWAY-831] Extend (custom) EventBus vetoing logic so that can also encompass hide, disable, validate.

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: core-1.5.0
• Fix Version/s: core-1.6.0
• Component/s: Core
• Assignee: Daniel Keir Haywood
• Reporter: Daniel Keir Haywood
• Created: 30/Jun/14 22:18
• Updated: 28/Jul/14 13:35
• Resolved: 11/Jul/14 13:10

Description

Previously raised on mailing list : http://markmail.org/thread/3z27xshelu4r7cx4

~~~~~
in the "typical" Isis programming model we use hideXxx(), disableXxx() and validateXxx() as three different precondition checks ("see it, use it, do it").

For event bus subscribers however, an interaction can only be vetoed by raising an exception in the execute phase.

An improvement would be to define some mechanism by which the subscribers can be involved in these other business rules. That is, a subscriber could cause an action to be hidden or greyed out if the state of the would-be source of the event is such that the action cannot be called.

One possible design is to introduce a "Mode" enum:

public enum Mode {
    HIDE, DISABLE, VALIDATE, EXECUTE
}

and then:

public abstract class ActionInteractionEvent {
    Mode getMode();
   ...
}

and some custom subclass:

public class MyActionInteractionEvent extends ActionInteractionEvent { ... }

The framework would then raise the (same) event multiple times for each action. The subscriber would switch on the mode:

@Subscribe
public void on(MyActionInteractionEvent ev) {
    switch(ev.getMode()) {
        case HIDE:
          // veto if required, ie cause action to be hidden
        case DISABLE:
          // veto if required, ie cause action to be greyed out
        case VALIDATE:
          // veto if required, ie cause action prompt to be redisplayed with error message
        case EXECUTE:
          // veto if required by raising exception, 
          // else perform appropriate actions
    }
}

The event could also, perhaps, provide the mechanism to allow the veto to be communicated:

public abstract class ActionInteractionEvent {
    Mode getMode();
    void vetoHide();
    void vetoDisable(String reason);
    void vetoValidate(String reason);
    ...
}

thus:

@Subscribe
public void on(MyActionInterationEvent ev) {
    switch(ev.getMode()) {
        case HIDE:
           ... if required ... ev.vetoHide();
        case DISABLE:
           ... if required ... ev.vetoDisable("Not allowed because...");
        case VALIDATE:
           ... if required ... ev.vetoValidate("Not allowed because...");
        case EXECUTE:
           ...
    }
}

One final refinement; it's likely that work done during the validation phases (eg querying a repo) may be useful for the later execution phases. So the event could also act as a simple map:

public abstract class ActionInteractionEvent {
    ...
    void put(Class subscriber, String key, Object val);
    Object get(Class subscriber, String key)
    ...
}