Changes between Version 2 and Version 3 of CORE_CHANGES
- Timestamp:
- 03/17/09 16:08:08 (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
CORE_CHANGES
v2 v3 2 2 3 3 == Overview == 4 5 4 An important part of the core layer of Sophie is formed by the ProLib. The ProLib is intended to be used as the bottom layer for most actions in Sophie. [[BR]] 5 One important concept is that when some action happens in Sophie, it is translated into basic ProLib operations. Thus, if all ProLib operations get "logged" some how, then everything which happens in Sophie would also get "logged". [[BR]] 6 Based on this information and automatic undo/redo logic can be implemented at this core ProLib layer, thus providing automatic undo/redo logic for the whole Sophie platform. [[BR]] 7 The way to "log" actions in Sophie are the Changes. [[BR]] 8 For further info on the ProLib see [wiki:PRO_LIB_CORE_TUTORIAL]. 6 9 7 10 == Change == … … 15 18 Each top-level Change is represented as a GroupChange and most likely has side-effect Changes. [[BR]] 16 19 Top-level Changes can be undoed, redoed and skipped by the UndoManager. 20 17 21 * ''Side-effect Changes'' [[BR]] 18 22 Side-effect Changes are Changes which are caused to happen due to a top-level Change. [[BR]] … … 21 25 * ''Significance of Changes'' [[BR]] 22 26 27 * ''Main Changes'' 28 * ''ProChange'' [[BR]] 29 A ProChange is a Change to a single Pro. It is meant to be the lowest level Change in the hierarchy. 23 30 24 * ''Main Changes'' 25 * ''ProChange'' 26 * ''GroupChange'' 27 [wiki:PRO_CHANGE_COMPOSING_R0] 31 * ''GroupChange'' [[BR]] 32 GroupChanges are used to implement composing of simpler Changes in one bigger Change and thus capsulate a complex action in one Change. [[BR]] 33 With their help we can implement hierarchical representation of each action which is to be treated as a Change. 34 Further details at [wiki:PRO_CHANGE_COMPOSING_R0]. 35 28 36 * ''AutoChange'' 37 AutoChanges are meant to be used by the developer when he wants some group of actions to be treated atomically by the UndoManager and thus either all of them get undone, redone or skipped in one transaction. [[BR]] 38 In contrast with other Changes, which are used internally by the ProLib, this Change is used by the developer and simply produces a GroupChange from all the described actions, thus this is the user way of creating a GroupChange. 39 29 40 * ''Special Changes'' 30 41 * ''UndoChange'' [[BR]] 31 42 UndoChange is a Change which wraps an '''undo''' command issued by the UndoManager. [[BR]] 32 43 It cancels the effect of the last Change in the History it's associated with. 44 33 45 * ''RedoChange'' [[BR]] 34 46 RedoChange is a Change which wraps a '''redo''' command issued by the UndoManager. [[BR]] 35 47 It is only valid if the last Change the History it's associated with is an UndoChange in which case it cancels its effect. 48 36 49 * ''SkipChange'' [[BR]] 37 50 SkipChange is a Change which wraps a '''skip''' command issued by the UndoManager. [[BR]] 38 51 It accepts one parameter which is the id of a Change in the History it's associated with and cancels its effect. 52 39 53 * ''CreateChange'' [[BR]] 40 54 Creating ProObjects is an important special event which couldn't be handled in the standard manner and thus is wrapped in a CreateChange. 55 41 56 * ''DestroyChange'' [[BR]] 42 57 Same applies to destroying ProObjects. 58 43 59 * ''UnmanagedChange'' [[BR]] 44 60 UnmanagedChange is a Change which is meant to wrap actions which need special handling of their undo logic. [[BR]] 45 61 Since the Change mechanism in Sophie should handle changes related with ProObjects and Immutables automatically, the UnmanagedChange is designed to handle other actions like writing to the filesystem, for instance. 46 * ''Usage''47 62 48 63 == History ==
