New Generic FSM Base Class
Description
This MR is a redo of !100 (closed) because of problems with the commits as well as the basic structure of the added class. Please refer to that MR for some of the info not included here.
This version makes a couple of large changes from !100 (closed):
- The FSM in the
GEMGenericFSMApplication
class is now synchronous to avoid the twice ansync issue brought up - The State adding process was simplified: adding of states and transitions is taken care of by a single function. The inputs are now just the start state, transition state, end state, a function run at the transition, and names giving for the changing of state start->transition as well as transition->end. The previously large
GEMFSM
fsm structure would be greatly simplified and probably easier to read - The code was further genericized: to avoid templating code/issues that arise from generic base functions having to deal with child only variables, the workLoop now only calls a single function and the function dynamically finds the appropriate transition function that is part of the child class. With this setup, specific FSM structures could be made as Base classes for the specific XDAQ children leading to hopefully simpler code
Error handling is probably not done exactly correctly (it was copied from the old code), so this may be a point for many comments
Related Issue
Closes #158 (closed) Closes #49 (closed)
How Has This Been Tested?
There is a test class that has been added in the location gemmonitor/src/testApp.cpp
and gemmonitor/src/testWeb.cpp
as well as the corresponding header files. The class has an FSM structure graphed in gemmonitor/interface/testApp.h
where each transition just prints text saying the command was called. There is also an accompanying javascript file gemmonitor/html/scripts/test.js
which gives an example of the javascript that would be used to create the buttons and website FSM structure.
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)
Checklist:
-
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.