Changes between Version 22 and Version 23 of GROUP_CHANGES_R0


Ignore:
Timestamp:
06/09/09 16:10:58 (16 years ago)
Author:
gogov
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • GROUP_CHANGES_R0

    v22 v23  
    6161  * 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). 
    6262  * 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. 
     63  * All of the Resources need 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. 
    6464 
    6565After all these ideas we can list all of the primitive Changes that will be serializable and thus a GroupChange will simply represent a list of such primitive Changes: 
    … …  
    7070 * Create a Resource : CreateResourceChange (will be designed in the next revision). 
    7171 * Destroy a Resource : DestroyResourceChange (will be designed in the next revision). 
    72  * Attach a ProObject to ResourceSpace : CreateProObjectChange. (may be a better name is AttachChange or AttachProObjectChange). 
    73  * Detach a ProObject from a ResourceSpace : DestroyProObjectChange. (may be better name is DetachChange or DetachProObjectChange). 
     72 * Attach a ProObject to ResourceSpace : CreateProObjectChange. (maybe a better name is AttachChange or AttachProObjectChange). 
     73 * Detach a ProObject from a ResourceSpace : DestroyProObjectChange. (maybe better name is DetachChange or DetachProObjectChange). 
    7474 * Undo a change : UndoChange. 
    7575 * Redo a change : RedoChange. 
    … …  
    7979 * ProObject related Changes: 
    8080  * 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. 
     81   * BaseProListChange - there are three such changes: ADD, REMOVE and SET, and they are primitive Changes for the BaseProLists. 
    8282   * CountChange - Used for testing of AutoTracker. 
    8383   * StatusChange - changes that track the status of the properties: 
    … …  
    8888  * 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>. 
    8989  * 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. 
     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 ProObjects because it is the beginning of a Resource's lifetime. 
    9191  * The destruction of a Resource is analogical. 
    9292 * Special Changes: 
    … …  
    9797All these comments clarify the model of the Changes. Now the logic that will be used for their management will be introduced. First this is the UML diagram:[[BR]] 
    9898[[Image(source:branches/private/meddle/sophie2-platform/modules/org.sophie2.base.model.resources/doc/ChangesLogic.jpg)]][[BR]] 
    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 : 
     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 : 
    100100  * 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. 
    101101  * ResourceChangeManager: 
    102102   * Every Resource will have its own ResourceChangeManager. It will be responsible for storing and grouping of the changes in its Resource's ResourceSpace. 
    103103   * 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. 
     104   * The Changes : CreateProObjectChange and DestroyProObjectChange will be handled here. When a new ProObject and its tree of 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. 
    105105   * 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. 
     106    * sync(newChanges : List<Change>) : List<Change> that for now adds the new changes to History of the Resource and returns the Changes which were actually added to the History. In the future, the returned ones will be these from the server. 
    107107    * changeList : ProList<Change> : used to get the content of the History. 
    108108   * 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. 
     109   * The manager will be constructed with a Resource as argument, because it's contained in a ResourceSpace. 
    110110 * GlobalResourceChangeManager : It will be used for grouping of the user Changes from more than one ResourceSpaces. 
    111111  * 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. 
    … …  
    121121  * For now it is only a skeleton that will be implemented in the next revisions, but it will be able to work with skipping. 
    122122  * It will be able to: 
    123    * Retrieve the undo and redo Changes from a Change. 
    124    * To check if is possible to undo or to redo. 
    125    * To execute (register) Undo and Redo. 
     123   * Create the undo and redo Changes from a Change. 
     124   * To check if is possible to undo or to redo a given Change. 
     125   * To execute (register) undo and redo acctions. 
    126126 
    127127That's all for the logic... Now for the visible part: 
    … …  
    129129 * An AllChangesPalette will be added which will list all the Changes for the current Book, globally grouped. 
    130130   * For now there will be no interactions. 
    131    * Most of the Canges won't be grouped nicely, because of bad AutoChanges and the lack of the Resource creation/destruction Changes. 
     131   * Most of the Changes won't be grouped nicely, because of bad AutoChanges and the lack of the Resource creation/destruction Changes. 
    132132   * The palette will use the GlobalResourceChangeManager.getAllChangesForResource(resource : Resource) method to get all of its changes, globally grouped. 
    133133