In the Push, the Pull and all other Adapter Actions components there is some logic that has been implemented inside the UI. This logic resides in the PushCaller, PullCaller, etc. classes, and it has always been "improper".
The reason behind this is that we had to ensure that some setup was always done prior to calling the action method.
In particular:
The UI PushCaller makes sure a new Default ActionConfig is always instantiated
The UI PullCaller does the same, plus it ensures that a cast from a Type becomes automatically a FilterRequest.
etc.
Suggestions to restore compliance
Instead we can consider the following. Taking the example for the Push action, we can have the UI PushCaller to call another method: something like SetupThenCallPush(). This method can be defined in the Base Adapter to include any needed setup; then it will simply return a call to the normal Push(). The same can be done for all actions.
The advantage of doing this is that the SetupThenCallPush() will be able to do any automatic casting / input transformations before the actual Push is called, without having to affect any Toolkit that uses or overrides the default Push.
We can make it overridable too, so if some of the setups are not useful for a particular Toolkit, or if some messages have to be returned prior to certain setups, we can do it.
Broken rules:
In the Push, the Pull and all other Adapter Actions components there is some logic that has been implemented inside the UI. This logic resides in the
PushCaller,PullCaller, etc. classes, and it has always been "improper". The reason behind this is that we had to ensure that some setup was always done prior to calling the action method. In particular:Typebecomes automatically aFilterRequest.Suggestions to restore compliance
Instead we can consider the following. Taking the example for the Push action, we can have the UI PushCaller to call another method: something like
SetupThenCallPush(). This method can be defined in the Base Adapter to include any needed setup; then it will simply return a call to the normalPush(). The same can be done for all actions.The advantage of doing this is that the
SetupThenCallPush()will be able to do any automatic casting / input transformations before the actual Push is called, without having to affect any Toolkit that uses or overrides the default Push.We can make it overridable too, so if some of the setups are not useful for a particular Toolkit, or if some messages have to be returned prior to certain setups, we can do it.
@al-fisher @IsakNaslundBh