At the Brussels 2018 Sprint I saw an overlap between CiviRules, SQLTasks and the newley form processor designer extension. The overlap is that all three of them have some sort of action handling.
As the Form Processor Designer extension is in the design phase and not yet developed it might be worth to take a route to explore whether it would be possible to have an extension operating as a base for all other extension which uses some sort of actions so that the actions can be reused in different parts of the system.
Have an extension which provides the following:
Some sort of interface class which other extensions could extend and which handle the execution of those actions
A set of actions which could be used in CiviRules, as in SQLTasks as in Form Processor Designer
Problems to tackle
Handle the data input and output mapping in a constistent manner. E.g. civirules works with entities, sql tasks with a database table.
Handle the configuration UI of the task in a consistent manner. E.g civirules works with quickforms, so does sql tasks but in a different way. What we dont want is that this base extension put requirements on the ui for the extensions using this extension.
In addition we dont want that each derivated extension is building UIs for each action in this base extension. So somehow the UI needs to be generated...
Below the class diagram of the base classes for the action.
ideas / notes remarks
Regarding the UI stuff we should probably include a layer which translates the configuration options to a Quickform, Angular or whatever UI system might be used in the extending system.
Tim suggested that a good way to start on this is to put the interface in this extension and that start working on an implementation of it in the form-processor-designer extension. This way I might get some gutfeeling on how things work.
An action has a set of contexts where it could operate in. For exmaple it requires on contact as input, or it requires multiple contacts, or it could be used as an action after searching etc...