| 43 | | There is implementation changes and events now. There is an UndoManager that is used like a ChangeManager and additionally can perform undo-redo. There are a few step that have to be taken into |
| 44 | | * First of all the old UndoManader has to be deprecated and later, when not needed, it should be removed (after the undo-redo-skip implementation |
| 45 | | * The current changes should be researched and their hierarchy may be will be enlarged. |
| 46 | | * The resources are the most important part of the changes design, because their state will be saved or transfered to the server and back. |
| 47 | | * The ProObjects should work with changes but if they are not part of a resource space, the changes should not be stored. |
| 48 | | * The grouping for the user have to have prototype. |
| | 43 | There is implementation changes and events now. There is an UndoManager that is used like a ChangeManager and additionally can perform undo-redo. There are a few step that have to be taken into consideration when designing this task: |
| | 44 | * First of all the old UndoManader has to be deprecated and later, when not needed, it should be removed (after the undo-redo-skip implementation is done). |
| | 45 | * The existing Changes should be explored and their hierarchy may be expanded. |
| | 46 | * Resources are the most important part of the Changes design, because their state will be saved or transfered from the client to the server and vice versa. |
| | 47 | * ProObjects should work with Changes but if they are not part of a ResourceSpace, their respective Changes should not be saved anywhere. |
| | 48 | * The grouping for the user needs to have a prototype implementation. |
| 52 | | * In the new design of the changes: |
| 53 | | * All the actions that on the pro-objects will be trackable and will be Changes. |
| 54 | | * The Undo and Redo actions will have changes, because they can be skipped, unskipped. |
| 55 | | * Skip and Unskip have to be Changes to because they are also undo-able redo-able, skip-able and unskip-able. |
| 56 | | * The changes will use the old GroupChange for grouping. |
| 57 | | * Groups can be created from the developer using the AutoChanges. |
| 58 | | * All AutoChanges will have to have descriptions, so they will be constructed with description and the description will be asserted to be not null or empty. |
| | 52 | * In the new design of the Changes: |
| | 53 | * All the actions and operations that are performed on ProObjects will be trackable and will be Changes. |
| | 54 | * The Undo and Redo actions will have Changes, because they can be skipped and unskipped. |
| | 55 | * Skip and unskip operations have to be Changes to because they are also undoable redoable, skippable and unskippable. |
| | 56 | * Changes will use the existing GroupChange class for grouping. |
| | 57 | * Groups can be created from the developer using AutoChanges. |
| | 58 | * All AutoChanges need to have descriptions, so they will be constructed with description and the description will be asserted to be not null or empty. |
| 60 | | * About resources. Having in mind that Resources will be buildable from a list of Changes and will be transferable through the net to the server and back, we can look at the resources as a sequence of changes that describes their life time so: |
| 61 | | * There will be changes for creating and destroying resource, as beginning and ending of it's lifetime. (Will be implemented with the serialization in some of the next revisions). |
| 62 | | * There will be changes for entering of a pro object in a given resource space and exiting of a pro object from a given resource space. |
| 63 | | * All of the resources have to have their own history, and that history will include the changes of all the objects in their own ResourceSpace => it will be part of the ResourceSpace. |
| | 60 | * I have the following comments about Resources - having in mind that Resources will be buildable from a list of Changes and will be transferable over the net to the server and back, we can look at Resources as a sequence of Changes that describes their lifetime so: |
| | 61 | * There will be Changes for creating and destroying a Resource respectively for the beginning and ending of their lifetime. (Will be implemented with serialization in some of the next revisions). |
| | 62 | * There will be Changes for attaching a given ProObject to a given ResourceSpace and detaching a ProObject from a given ResourceSpace. |
| | 63 | * All of the Resources need to have their own History, and that Gistory will include the Changes of all the objects in their own ResourceSpace => it will be part of the ResourceSpace. |
| 78 | | Some ideas for the old changes and the new changes: |
| 79 | | * Pro-object related changes: |
| 80 | | * There are some changes that are not in the UML diagram, they are connected with the pro objects only and are already implemented: |
| 81 | | * This changes are all descendants of the ProChange, and more accurately BaseProChanges: |
| 82 | | * BaseProListChange - there are three such changes ADD, REMOVE and SET, they are primitive changes for the pro-lists. |
| 83 | | * CountChange - Used for testing of the AutoTracker. |
| | 78 | Some ideas for the old Changes and the new Changes: |
| | 79 | * ProObject related Changes: |
| | 80 | * There are some Changes that are not in the UML diagram, they are connected with the ProObjects only and are already implemented. These Changes are all descendants of ProChange, and more accurately BaseProChange: |
| | 81 | * BaseProListChange - there are three such changes: ADD, REMOVE and SET, and they are primitive changes for the BaseProLists. |
| | 82 | * CountChange - Used for testing of AutoTracker. |
| 85 | | * InitChanges - used for initializing of the properties they are not primitive changes, because when to a property a value is set they will be triggered automatically. |
| 86 | | * ValueChange - a primitive change for setting properties to a pro-object. |
| 87 | | * ProObjectChange - this change is not used so maybe it will be deleted in the next revisions... |
| 88 | | * Changes connected to the Resources: |
| 89 | | * When creating a pro-object in a ResourceSpace two thing are important, the id of the pro-object given by the resource space and the type of the pro-object, so the constructor of this change will take proObjectId:String and proObjectType:Class<T extends ProObject>. |
| 90 | | * When destroying the pro-object only it's id will be important to know what we have destroyed. So the DestroyProObjectChange will be constructed only by id. |
| 91 | | * When creating a resource we will need the id of the resource and it's type too but the change must be different than this of the pro-objects because it is the beginning of a Resource's lifetime. |
| 92 | | * The destruction of a resource is analogical. |
| 93 | | * Special changes |
| | 84 | * InitChanges - used for initializing of the properties. They are not primitive Changes, because when a value is set to a property they will be triggered automatically. |
| | 85 | * ValueChange - a primitive Change for setting values to properties of a ProObject. |
| | 86 | * ProObjectChange - this Change is not used so maybe it will be deleted in the next revisions... |
| | 87 | * Changes related to Resources: |
| | 88 | * When creating a ProObject in a ResourceSpace two things are important: the id of the ProObject assigned by its container ResourceSpace and the type of the ProObject, so the constructor of this Change will take proObjectId:String and proObjectType:Class<T extends ProObject>. |
| | 89 | * When destroying a ProObject, only its id will be important in order to know what we have destroyed. So the DestroyProObjectChange will be constructed only by id. |
| | 90 | * When creating a Resource, we will need the id of the Resource and its type too but the Change must be different than this of the pro-objects because it is the beginning of a Resource's lifetime. |
| | 91 | * The destruction of a Resource is analogical. |
| | 92 | * Special Changes: |
| 100 | | * ChangeManager : The old Undomanager will be deprecated, and will be removed from everywhere it's used, but will be saved for now until the undo/redo implementation. In it's place there will be only a ChangeManager. All the changes will be registered in a ChangeManager, it will have only one method - register that takes a Change to register. What will be done with the Change when registered depends of the implementation. For now there will be two implementations : |
| 101 | | * DefaultChangeManager - All the pro-objects by default will register their changes in it, and only one instance of it will be needed for all of the changes so it will be singleton. Other thing is that the changes that are not in a ResourceSpace will be not stored, because only the state of the resource will be important for the server and the persistence... So on registration, the Changes will be just executed. |
| 102 | | * ResourceChangeManager. |
| 103 | | * Every Resource will have it's own ResourceChangeManager. It will be responsible for storing and grouping of the changes in it's Resource's ResourceSpace. |
| 104 | | * The old logic for grouping from the UndoManager will be used for closing and opening groups, the Changes will be grouped on registration. |
| 105 | | * The changes : CreateProObjectChange and DestroyProObjectChange will be handled here and all the values of the properties of the new pro-object and it's sub-pro-objects when attached will be registered as Changes in the history of the resource. |
| 106 | | * The ResourceChangeManager will have History, for now it will store all the changes that the manager gives it as a list but in future it will be used for synchronization with the server, so it will have to visible methods : |
| 107 | | * sync(newChanges : List<Change>) : List<Change> that for now adds the new changes to History and returns the added, in future the returned ones will be these from the server. |
| 108 | | * changeList : ProList<Change> : used to get the ciontent of the history. |
| 109 | | * The UndoChange and RedoChange for now will be part of the ResourceChangeManager, because they are connected with the manager of their changes and automatically will register themselves in it. may be in the future the SkipChange will be the same. |
| 110 | | * The manager will construct itself with a Resource, it's Resource. |
| 111 | | * GlobalResourceChangeManager : It will be used for grouping for the user changes from more than one ResourceSpaces. |
| 112 | | * Important thing is that all the changes will be packed into groups, to have Global grouping, so the ResourceChangeManagers will group single changes too. That is not bad, because when serializing we will ungroup all the groups anyway. |
| 113 | | * It will be one for all the Resources, so it will be singleton, it will group the changes for the current book hierarchy, to be nice for the user. Good AutoChanges must be written from the developers... |
| | 99 | * ChangeManager : The old Undomanager will be deprecated, and will be removed from everywhere it's used, but will be saved for now until the undo/redo implementation. A ChangeManager will replace it. All the Changes will be registered in a ChangeManager, which will be an interface with only one method, register(), which takes a Change to register as an argument. What will be done with the Change when it is registered depends of the implementation. For now there will be two implementations : |
| | 100 | * DefaultChangeManager: All the ProObjects by default will register their Changes in it, and only one instance of it will be needed for all of the changes so it will be singleton. Other thing is that the Changes that are not in a ResourceSpace will be not stored, because only the state of the Resource will be important for the server and the persistence... So on registration, the Changes will be just executed. |
| | 101 | * ResourceChangeManager: |
| | 102 | * Every Resource will have its own ResourceChangeManager. It will be responsible for storing and grouping of the changes in its Resource's ResourceSpace. |
| | 103 | * The old logic for grouping from the UndoManager will be used for closing and opening groups and Changes will be grouped on registration. |
| | 104 | * The Changes : CreateProObjectChange and DestroyProObjectChange will be handled here. When a new ProObject and its owned ProObjects are attached to a ResourceSpace, the creation and destruction of all the values of the properties of the ProObjects will be registered as Changes in the History of the Resource. |
| | 105 | * The ResourceChangeManager will have a History, which for now will store all the Changes that the manager gives it as a list but in future it will be used for synchronization with the server, so it will have to visible methods : |
| | 106 | * sync(newChanges : List<Change>) : List<Change> that for now adds the new changes to History of the Resource and returns the Cnanges which were actually added to the History. In the future, the returned ones will be these from the server. |
| | 107 | * changeList : ProList<Change> : used to get the content of the History. |
| | 108 | * The UndoChange and RedoChange for now will be part of the ResourceChangeManager, because they are connected with the manager the Changes they undo and respectively redo, and automatically will register themselves in it. Maybe in the future the SkipChange will be created in the same way. |
| | 109 | * The manager will be constructed with a Resource as argument, because it's contained in ResourceSpace. |
| | 110 | * GlobalResourceChangeManager : It will be used for grouping of the user Changes from more than one ResourceSpaces. |
| | 111 | * Important thing is that all the Changes will be packed into groups, to have global grouping, so the ResourceChangeManagers will group single Changes too. That is not bad, because when serializing we will ungroup all the groups anyway. |
| | 112 | * It will be one for all the Resources, so it will be singleton, it will group the Changes for the current book hierarchy, to be nice for the user. Good AutoChanges must be written from the developers... |
| 115 | | * If global group must be opened (For every new set of changes or change it will open such a global group) it opens one with root Change the first change of the new set. The method shouldOpenGlobalGroup is used to check that. If there is already a root Change for the global group it will return false, otherwise true. |
| 116 | | * If there is already opened global group it will add the incoming change to it, for that will be used hasOpenedGroup. |
| 117 | | * If global group must be closed (The change that opened the group is closing itself) all the sub groups will be closed and the global group will be closed, so the root Change of the manager will be null. That's the purpose of the willCloseGroup method. |
| 118 | | * All the changes grouped globally will be retrievable through the getAllChangesForResource method. |
| 119 | | * All the global groups are virtual, they are not saved in the History of the Resources and are used only for displaying the list of the changes to the users nicely. |
| | 114 | * If global group must be opened (for every new set of Changes or Change it will open such a global group), it opens one with root Change which is the first Change of the new set. The method shouldOpenGlobalGroup() is used to check that. If there is already a root Change for the global group, it will return false, otherwise true. |
| | 115 | * If there is already opened global group, it will add the incoming Change to it. For that purpose, the method hasOpenedGroup() will be used. |
| | 116 | * If global group must be closed (the Change that opened the group is closing itself), all the subgroups will be closed and the global group will be closed, so the root Change of the manager will be null. That's the purpose of the willCloseGroup() method. |
| | 117 | * All the Changes grouped globally will be retrievable through the getAllChangesForResource() method. |
| | 118 | * All the global groups are virtual, they are not saved in the History of the Resources and are used only for displaying the list of the Changes to the users nicely. |
