Changes between Version 19 and Version 20 of GROUP_CHANGES_R0
- Timestamp:
- 06/09/09 13:35:19 (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GROUP_CHANGES_R0
v19 v20 6 6 7 7 == Overview == 8 The changes to the pro object have to be tracked and use for undoing and redoing actions, skipping and unskipping actions, synchronizing with the server, getting different revisions, and user visualization of the history of an Pro. The user actions are significant changes to a pro object and they should be visible to for the user and editable by him or her. The insignificant changes will be not. Every change should be composed of a set of primitive changes or should be a primitive change. This primitive changes should be serializable anddefined.8 Changes to ProObjects have to be tracked and used for undoing and redoing actions, skipping and unskipping actions, synchronizing with the server, getting different revisions and user visualization of the history of a Pro. The user actions are significant Changes to a ProObject and they should be visible to for the user and editable by him or her. The insignificant Changes will be not. Every Change should be composed of a set of primitive Changes or should be a primitive Change. This primitive Changes should be serializable and well defined. 9 9 10 10 == Task requirements == 11 * Define the primitive changes and list them in the design section.12 * Provide interfaces for storing and synchronizing the changes of a Resource.13 * Provide a functionality for grouping of primitive changes to the developers.14 * Provide a logic that can group changes from different resources to something that can be shown to the user as one significant change.11 * Define the primitive Changes and list them in the design section. 12 * Provide interfaces for storing and synchronizing the Changes of a Resource. 13 * Provide a functionality for grouping of primitive Changes to the developers. 14 * Provide a logic that can group Changes from different Resources to something that can be shown to the user as one significant Change. 15 15 * Provide interface for redo/undo/skip/unskip (implementation in later revisions). 16 16 * Refactor the old code to work for the requirements above. 17 * Provide a palette the shows the changes tothe currently selected book.17 * Provide a palette the shows the Changes of the currently selected book. 18 18 19 19 == Task result == … … 22 22 == Implementation idea == 23 23 * Use some of the code of the old UndoManager. 24 * Create DefaultChange manager to execute the changes to all the pros...25 * Create special ChangeManager for the Resources, and for the pro object that are in theirspace.24 * Create DefaultChangeManager to execute the changes to all the Pros... 25 * Create special ChangeManager for the Resources, and for the ProObjects in their respective space. 26 26 * Think of an algorithm for global grouping for the user. 27 * Think of the primitive changes connected to Resource creation and destruction, also entering of a pro object into a ResourceSpace and leaving from it.27 * Think of the primitive Changes connected to Resource creation and destruction, also attaching of a ProObject into a ResourceSpace and detaching from it. 28 28 * Think of use cases connected to server communication and persistence. 29 29 30 30 == Related == 31 [wiki:GROUP_RESOURCE_R0][[BR]]32 [wiki:GROUP_PERSISTENCE_R0]31 * [wiki:GROUP_RESOURCE_R0] 32 * [wiki:GROUP_PERSISTENCE_R0] 33 33 34 34 == How to demo == 35 * Unit tests.35 * Run unit tests. 36 36 * Demonstration: 37 37 * Run the Sophie 2 author application. 38 38 * Create a new book. 39 39 * Insert a text frame. 40 * See in the changes palette the change to this actions for the book...40 * See in the Changes palette the Change corresponding to these actions.. 41 41 42 42 = Design = 43 There is implementation changes and events now. There is UndoManager that is used like a change manager and additionally can perform undo-redo. There are a few step that have to be taken into when designing this task:44 * First of all the old UndoManader ha ve to be deprecated and later when not neededremoved (after the undo-redo-skip implementation).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 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). 45 45 * The current changes should be researched and their hierarchy may be will be enlarged. 46 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.