| | 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. |
