This MR creates a basic FSM framework that is more generic and thus can be used by an XDAQ application to create a unique FSM structure. This MR is mainly taking the existing FSM classes, namely
GEMFSMApplication and gutting them of references to specific states and combining them. Several helper functions are also added for permission reasons as well as to further genericize the code base. For future MRs, the goal would be to switch to this framework in conjunction with making proper FSM diagrams to show the states and transitions for all FSM applications.
The naming convention for this MR is very uninspired (
GEMGenericFSMApp) and better names would be appreciated!
In part of the simplification, the soap commands were removed (no more talking between the FSM classes, there is only one) and combining functions that were separate before. A big example of this is
xgiChangeState. In the old code, an
xgi function had to be made for every transition command in the FSM which did roughly the same except forward to the FSM a different name for a command. Now,
xgiChangeState takes the command needed from the webpage and starts the
transitionDriver with that command found.
This leads to a possible issue. In simplifying the code, many exceptions aren't needed (e.g. no more soap, so that can be removed), but new error handling should probably be added for safety. This can be handled in this MR or possible another future MR.
How Has This Been Tested?
This MR was made in conjunction to MR !89 (merged) so the testing was done on the monitor suite.
Types of changes
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
My code follows the code style of this project.
My change requires a change to the documentation.
I have updated the documentation accordingly.
I have read the CONTRIBUTING document.
I have added tests to cover my changes.
All new and existing tests passed.