Last modified 16 years ago
Last modified on 01/26/09 17:35:58
Analysis
Overview
Common things about changes that are not put in the other tasks listed in related section.
Task requirements
- consider carefully the relations between classes of the following:
- consider creating a module if necessary - the change manager will take an important role in changes of books on the server as well.
- the module may be needed now.
- the module may appear in later revisions.
- the module may not be needed at all.
- create a wiki page that describes all the relations and class of the PRO_CHANGE things.
- Changes types:
- Change - a simple change.
- GroupChange - a composite change that is constructed of simple changes.
- UnmanagedChange - a change that is supposed to be managed in a special way. Its undo and redo will be implemented as the situation requires. For example - save a book may be a unmanaged change. If the user creates a frame with a movie content (with a media file of over 700Mb), deletes the frame, deletes the media file and requests a undo - the change may become a unmanaged. If the user had not deleted the media file the change would have been a normal change that can be undone.
- Changes types:
- provide class diagrams.
Task result
- a base design of the change part of the pro library.
- a wiki page.
- diagrams of the classes for connected with changes.
Implementation idea
- review the tasks that are connected with PRO_CHANGE.
- view the existing source code.
- provide a relations and operations explanation in a wiki page.
- provide diagrams of the classes needed.
Related
PRO_CHANGE_PRIMITIVES_R0
PRO_CHANGE_UNDO_MANAGER_R0
PRO_CHANGE_TRANSACTION_SAFETY_R0
PRO_CHANGE_COMPOSING_R0
PRO_CHANGE_MANAGER_R0
How to demo
- show the base design, diagrams and the wiki page.
Design
Implementation
Testing
Comments
The following comments could be either part of this task or the R1 revision. --gogov 15:00-26.01.09
- Overall concept should be explained from the end-user point of view
- undoing/redoing
- Some internal terminology needs to be explained:
- Top-level change
- Main/side effect of a change
- A hierarchy of the types of changes should be provided, as well as their functionality and purpose such as:
- Changes form a three of GroupChanges as internal nodes and ProChanges as leaves of the tree
- AutoChanges are meant to be used by the developer (describe how)
- GroupChanges are meant to be used itnernally by the AutoChanges and the overall change mechanism (describe how)
- ProChanges are meant to be leaves of the tree (describe why)
- This scheme should work if Sophie 2 uses properties and immutable objects (describe why)