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

["Dan Haywood (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ISIS-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Haywood resolved ISIS-831.
------------------------------

    Resolution: Fixed

in addition, added an EXECUTING phase.

> Extend (custom) EventBus vetoing logic so that can also encompass hide, disable, validate.
> ------------------------------------------------------------------------------------------
>
>                 Key: ISIS-831
>                 URL: https://issues.apache.org/jira/browse/ISIS-831
>             Project: Isis
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: core-1.5.0
>            Reporter: Dan Haywood
>            Assignee: Dan Haywood
>             Fix For: core-1.6.0
>
>
> 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:
> {code:java}
> public enum Mode {
>     HIDE, DISABLE, VALIDATE, EXECUTE
> }
> {code}
> and then:
> {code:java}
> public abstract class ActionInteractionEvent {
>     Mode getMode();
>    ...
> }
> {code}
> and some custom subclass:
> {code:java}
> public class MyActionInteractionEvent extends ActionInteractionEvent { ... }
> {code}
> The framework would then raise the (same) event multiple times for each action.    The subscriber would switch on the mode:
> {code:java}
> @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
>     }
> }
> {code}
> The event could also, perhaps, provide the mechanism to allow the veto to be communicated:
> {code:java}
> public abstract class ActionInteractionEvent {
>     Mode getMode();
>     void vetoHide();
>     void vetoDisable(String reason);
>     void vetoValidate(String reason);
>     ...
> }
> {code}
> thus:
> {code:java}
> @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:
>            ...
>     }
> }
> {code}
> 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:
> {code:java}
> public abstract class ActionInteractionEvent {
>     ...
>     void put(Class subscriber, String key, Object val);
>     Object get(Class subscriber, String key)
>     ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)