Changes between Version 3 and Version 6 of GROUP_CHANGES_R0

Timestamp:

05/27/09 17:23:52 (16 years ago)

Author:

meddle

Comment:

--

GROUP_CHANGES_R0

@@ -6 +6 @@
 
 == Overview ==
-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 object. 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 and defined.
+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 and defined.
+
 == Task requirements ==
  * Define the primitive changes and list them in the design section. 
@@ -21 +22 @@
 == Implementation idea ==
  * Use some of the code of the old UndoManager.
+ * Create DefaultChange manager to execute the changes to all the pros...
  * Create special ChangeManager for the Resources, and for the pro object that are in their space.
  * Think of an algorithm for global grouping for the user.
@@ -27 +29 @@
 
 == Related ==
-[wiki:GROUP_RESOURCES_R0]
+[wiki:GROUP_RESOURCE_R0][[BR]]
 [wiki:GROUP_PERSISTENCE_R0]
 
@@ -39 +41 @@
 
 = Design =
-^(Describe your design here.)^
+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:
+ * First of all the old UndoManader have to be deprecated and later when not needed removed (after the undo-redo-skip implementation).
+ * The current changes should be researched and their hierarchy may be will be enlarged.
+ * The resources are the most important part of the changes design, because their state will be saved or transfered to the server and back.
+ * The ProObjects should work with changes but if they are not part of a resource space, the changes should not be stored.
+ * The grouping for the user have to have prototype.
+
+So when thinking
 
 = Implementation =