[[BackLinksMenu]]

[[TicketQuery(summary=PRO_CHANGE_COMMONS_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|)]]

= 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:
  * [wiki:PRO_CHANGE_PRIMITIVES_R0]
  * [wiki:PRO_CHANGE_TRANSACTION_SAFETY_R0]
  * [wiki:PRO_CHANGE_COMPOSING_R0]
  * [wiki:PRO_CHANGE_MANAGER_R0]
 * 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.
 * 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 ==

[wiki:PRO_CHANGE_PRIMITIVES_R0] [[BR]]
[wiki:PRO_CHANGE_UNDO_MANAGER_R0] [[BR]]
[wiki:PRO_CHANGE_TRANSACTION_SAFETY_R0] [[BR]]
[wiki:PRO_CHANGE_COMPOSING_R0] [[BR]]
[wiki:PRO_CHANGE_MANAGER_R0] [[BR]]

== 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)