Added a preliminary "State Machine" set of classes, which (if it works) will need to be factored out into a library. However, at the start, it will be easier and simpler to place these classes in-situ and work with them there..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The state machine has "tween" states -- that is -- states talking about the legality of moving to another state. For example: In the SM_STANDARD_MACHINE state of "Viewing" there are several other "tween" states:
is_editable -- Can we transit to "Editing"?
is_deletable -- Can we transit to "Deleting"?
is_voidable -- Can we transit to "Voiding"?
The above implies that state: SM_STATE is more -- namely -- current_state: ARRAYED_LIST [SM_STATE], where the contents are the primary state and its transit conditionals (e.g. tweens).
These state transitional conditions will need to be checked to ensure it is legal to make the particular transit. On the GUI, this might work out to be enabling and disabling of various controls that are gateways triggers to state transitions.
The terminal have special tweens:
is_reversible -- Can we reverse the Delete or Void and return to Viewing?
This last bit implies an Undo/Redo mechanism that needs to store the delta-contents of the various features of the class. For primitives (e.g. INTEGER, STRING, BOOLEAN, etc) this is not a tough thing to do. However, for complex objects (possibly with their own states), the matter is much more complex. Additionally, there may be limits as some object references may defy any attempt at Undo/Redo based on the logical complexity of controlling it internally in code, not to mention what it might do to the user GUI. The simpler and safer thing for both programmer and user may be to simply say, "There is no Undo or Redo!"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Added a preliminary "State Machine" set of classes, which (if it works) will need to be factored out into a library. However, at the start, it will be easier and simpler to place these classes in-situ and work with them there..
re: State Machine
The state machine has "tween" states -- that is -- states talking about the legality of moving to another state. For example: In the SM_STANDARD_MACHINE state of "Viewing" there are several other "tween" states:
The above implies that state: SM_STATE is more -- namely -- current_state: ARRAYED_LIST [SM_STATE], where the contents are the primary state and its transit conditionals (e.g. tweens).
These state transitional conditions will need to be checked to ensure it is legal to make the particular transit. On the GUI, this might work out to be enabling and disabling of various controls that are gateways triggers to state transitions.
The terminal have special tweens:
is_reversible -- Can we reverse the Delete or Void and return to Viewing?
This last bit implies an Undo/Redo mechanism that needs to store the delta-contents of the various features of the class. For primitives (e.g. INTEGER, STRING, BOOLEAN, etc) this is not a tough thing to do. However, for complex objects (possibly with their own states), the matter is much more complex. Additionally, there may be limits as some object references may defy any attempt at Undo/Redo based on the logical complexity of controlling it internally in code, not to mention what it might do to the user GUI. The simpler and safer thing for both programmer and user may be to simply say, "There is no Undo or Redo!"