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:
and some custom subclass:
The framework would then raise the (same) event multiple times for each action. The subscriber would switch on the mode:
The event could also, perhaps, provide the mechanism to allow the veto to be communicated:
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: