You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by "Dan Haywood (JIRA)" <ji...@apache.org> on 2014/07/01 00:23:24 UTC

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

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

Dan Haywood updated ISIS-831:
-----------------------------

    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 {
    HIDE, DISABLE, VALIDATE, EXECUTE
}

and then:

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

and some custom subclass:

public class MyActionInvokedEvent extends ActionInvokedEvent { ... }

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

@Subscribe
public void on(MyActionInvokedEvent 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 ActionInvokedEvent {
    Mode getMode();
    void vetoHide();
    void vetoDisable(String reason);
    void vetoValidate(String reason);
    ...
}

thus:

@Subscribe
public void on(MyActionInvokedEvent 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 ActionInvokedEvent {
    ...
    void put(Class subscriber, String key, Object val);
    Object get(Class subscriber, String key)
    ...
}


  was:
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 {
    HIDE, DISABLE, VALIDATE, EXECUTE
}

and then:

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

and some custom subclass:

public class MyActionInvokedEvent extends ActionInvokedEvent { ... }

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

@Subscribe
public void on(MyActionInvokedEvent 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 ActionInvokedEvent {
    Mode getMode();
    void vetoHide();
    void vetoDisable(String reason);
    void vetoValidate(String reason);
    ...
}

thus:

@Subscribe
public void on(MyActionInvokedEvent 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 ActionInvokedEvent {
    ...
    void put(Class subscriber, String key, Object val);
    Object get(Class subscriber, String key)
    ...
}



> 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:
> public enum {
>     HIDE, DISABLE, VALIDATE, EXECUTE
> }
> and then:
> public abstract class ActionInvokedEvent {
>     Mode getMode();
>    ...
> }
> and some custom subclass:
> public class MyActionInvokedEvent extends ActionInvokedEvent { ... }
> The framework would then raise the (same) event multiple times for each action.    The subscriber would switch on the mode:
> @Subscribe
> public void on(MyActionInvokedEvent 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 ActionInvokedEvent {
>     Mode getMode();
>     void vetoHide();
>     void vetoDisable(String reason);
>     void vetoValidate(String reason);
>     ...
> }
> thus:
> @Subscribe
> public void on(MyActionInvokedEvent 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 ActionInvokedEvent {
>     ...
>     void put(Class subscriber, String key, Object val);
>     Object get(Class subscriber, String key)
>     ...
> }



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