Dear All,
Here is a request regarding statemachine management within MITK and more precisely GlobalInteraction.
In the current MITK implementation, the GlobalInteraction singleton as a statemachinefactory as static data member. All statemachines are parsed from this statemachine factory and stored in an associated map.
We want to use the MITK statemachine for procedure workflow navigation/control. Each procedure will have an associated XML file based on an XML schema. From the parsing of this procedure XML file, a statemachine for navigation/control of the procedure execution will be built.
- This statemachine will be associated to navigation event (in our case voice commands).
- Each step of this procedure will also be linked with other infos such as an associated perspective and some associated views ...
- This procedure is not associated to a DataNode.
- We have our own software infrastructure (e.g. svn, CMake macros ...) and we used MITK as a library.
Our primary considered approach:
- procedures are statemachines
- procedure steps are extended statemachine states
- procedures are described as individual XML files
- we have our own statemachine factory with our own parsing
However, with the current implementation, we have to parse the procedure XML twice:
- with our parser to get access to the extended state (procedure step description)
- with the standard statemachine factory from global interaction so that our statemachine (procedure) is registered (i.e. added in the statemachine map).
In order to avoid this double parsing, maybe it would help to:
- either handle statemachine factories as a vector in the GlobalInteraction: that way, externaly derived statemachine factory can be pushed in the GlobalInteraction.
- or provide some API to push externally parsed statemachines in the statemachine map in the statemachine factory from global interaction.
Moreover, we have to ensure coherency between the mitk statemachine and our procedure. This can be realized through overloading of the ExecuteAction and ExecuteOperation but it might make sense to extend it with some associated pre and pos processing functions to increase the versatility.
Do these features make sense?
Best regards,
Tangi