Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro TicketQuery(summary=GROUP_CHANGES_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|) failed

current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

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.

Task requirements

• Define the primitive Changes and list them in the design section.
• Provide interfaces for storing and synchronizing the Changes of a Resource.
• Provide a functionality for grouping of primitive Changes to the developers.
• Provide a logic that can group Changes from different Resources to something that can be shown to the user as one significant Change.
• Provide interface for redo/undo/skip/unskip (implementation in later revisions).
• Refactor the old code to work for the requirements above.
• Provide a palette the shows the Changes of the currently selected book.

Task result

The task result will be source code and palette with the changes to the currently selected book.

Implementation idea

• Use some of the code of the old UndoManager.
• Create DefaultChangeManager to execute the changes to all the Pros...
• Create special ChangeManager for the Resources, and for the ProObjects in their respective space.
• Think of an algorithm for global grouping for the user.
• Think of the primitive Changes connected to Resource creation and destruction, also attaching of a ProObject into a ResourceSpace and detaching from it.
• Think of use cases connected to server communication and persistence.

Related

• GROUP_RESOURCE_R0
• GROUP_PERSISTENCE_R0

How to demo

• Run unit tests.
• Demonstration:
  • Run the Sophie 2 author application.
  • Create a new book.
  • Insert a text frame.
  • See in the Changes palette the Change corresponding to these actions..

Design

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 consideration when designing this task:

• 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 is done).
• The existing Changes should be explored and their hierarchy may be expanded.
• Resources are the most important part of the Changes design, because their state will be saved or transfered from the client to the server and vice versa.
• ProObjects should work with Changes but if they are not part of a ResourceSpace, their respective Changes should not be saved anywhere.
• The grouping for the user needs to have a prototype implementation.

That is a diagram of some of the changes that are used now and some that I will add:

• In the new design of the Changes:
  • All the actions and operations that are performed on ProObjects will be trackable and will be Changes.
  • The Undo and Redo actions will be Changes, because they can be skipped and unskipped.
  • Skip and unskip operations have to be Changes to because they are also undoable redoable, skippable and unskippable.
• Changes will use the existing GroupChange class for grouping.
  • Groups can be created from the developer using AutoChanges.
  • All AutoChanges need to have descriptions, so they will be constructed with description and the description will be asserted to be not null or empty.
  • The old DummyChange can be used for closing groups if there is no present closing change. (Think of a better name for the next revision.).
• I have the following comments about Resources - having in mind that Resources will be buildable from a list of Changes and will be transferable over the net to the server and back, we can look at Resources as a sequence of Changes that describes their lifetime so:
  • There will be Changes for creating and destroying a Resource respectively for the beginning and ending of their lifetime. (Will be implemented with serialization in some of the next revisions).
  • There will be Changes for attaching a given ProObject to a given ResourceSpace and detaching a ProObject from a given ResourceSpace.
  • All of the Resources need to have their own History, and that History will include the Changes of all the objects in their own ResourceSpace => it will be part of the ResourceSpace.

After all these ideas we can list all of the primitive Changes that will be serializable and thus a GroupChange will simply represent a list of such primitive Changes:

• Set a value to a non-list property : ValueChange.
• Set an element to a given index of a BaseProList : BaseProListChange.SET
• Add an element to a BaseProList : BaseProListChange.ADD
• Remove an element from a BaseProList : BaseProListChange.REMOVE
• Create a Resource : CreateResourceChange (will be designed in the next revision).
• Destroy a Resource : DestroyResourceChange (will be designed in the next revision).
• Attach a ProObject to ResourceSpace : CreateProObjectChange. (maybe a better name is AttachChange or AttachProObjectChange).
• Detach a ProObject from a ResourceSpace : DestroyProObjectChange. (maybe better name is DetachChange or DetachProObjectChange).
• Undo a change : UndoChange.
• Redo a change : RedoChange.
• Skip a change : SkipChange. The Unskip action is skip of a skip so this change will work for it.

Some ideas for the old Changes and the new Changes:

• ProObject related Changes:
  • There are some Changes that are not in the UML diagram, they are connected with the ProObjects only and are already implemented. These Changes are all descendants of ProChange, and more accurately BaseProChange:
    • BaseProListChange - there are three such changes: ADD, REMOVE and SET, and they are primitive Changes for the BaseProLists.
    • CountChange - Used for testing of AutoTracker.
    • StatusChange - changes that track the status of the properties:
      • InitChanges - used for initializing of the properties. They are not primitive Changes, because when a value is set to a property they will be triggered automatically.
      • ValueChange - a primitive Change for setting values to properties of a ProObject.
  • ProObjectChange - this Change is not used so maybe it will be deleted in the next revisions...
• Changes related to Resources:
  • When creating a ProObject in a ResourceSpace two things are important: the id of the ProObject assigned by its container ResourceSpace and the type of the ProObject, so the constructor of this Change will take proObjectId:String and proObjectType:Class<T extends ProObject>.
  • When destroying a ProObject, only its id will be important in order to know what we have destroyed. So the DestroyProObjectChange will be constructed only by id.
  • When creating a Resource, we will need the id of the Resource and its type too but the Change must be different than this of the ProObjects because it is the beginning of a Resource's lifetime.
  • The destruction of a Resource is analogical.
• Special Changes:
  • The UndoChange undoes a Change so it will be constructed with a Change.
  • The RedoChange redoes an undo, so it will be constructed with an UndoChange.
  • The SkipChange behavior is unclear for now, but may be it will be constructed with a Change to skip.

All these comments clarify the model of the Changes. Now the logic that will be used for their management will be introduced. First this is the UML diagram:

• ChangeManager : The old UndoManager will be deprecated, and will be removed from everywhere it's used, but will be saved for now until the undo/redo implementation. A ChangeManager will replace it. All the Changes will be registered in a ChangeManager, which will be an interface with only one method, register(), which takes a Change to register as an argument. What will be done with the Change when it is registered depends of the implementation. For now there will be two implementations :
  • DefaultChangeManager: All the ProObjects by default will register their Changes in it, and only one instance of it will be needed for all of the changes so it will be singleton. Other thing is that the Changes that are not in a ResourceSpace will be not stored, because only the state of the Resource will be important for the server and the persistence... So on registration, the Changes will be just executed.
  • ResourceChangeManager:
    • Every Resource will have its own ResourceChangeManager. It will be responsible for storing and grouping of the changes in its Resource's ResourceSpace.
    • The old logic for grouping from the UndoManager will be used for closing and opening groups and Changes will be grouped on registration.
    • The Changes : CreateProObjectChange and DestroyProObjectChange will be handled here. When a new ProObject and its tree of owned ProObjects are attached to a ResourceSpace, the creation and destruction of all the values of the properties of the ProObjects will be registered as Changes in the History of the Resource.
    • The ResourceChangeManager will have a History, which for now will store all the Changes that the manager gives it as a list but in future it will be used for synchronization with the server, so it will have to visible methods :
      • sync(newChanges : List<Change>) : List<Change> that for now adds the new changes to History of the Resource and returns the Changes which were actually added to the History. In the future, the returned ones will be these from the server.
      • changeList : ProList<Change> : used to get the content of the History.
    • The UndoChange and RedoChange for now will be part of the ResourceChangeManager, because they are connected with the manager the Changes they undo and respectively redo, and automatically will register themselves in it. Maybe in the future the SkipChange will be created in the same way.
    • The manager will be constructed with a Resource as argument, because it's contained in a ResourceSpace.
• GlobalResourceChangeManager : It will be used for grouping of the user Changes from more than one ResourceSpaces.
  • Important thing is that all the Changes will be packed into groups, to have global grouping, so the ResourceChangeManagers will group single Changes too. That is not bad, because when serializing we will ungroup all the groups anyway.
  • It will be one for all the Resources, so it will be singleton, it will group the Changes for the current book hierarchy, to be nice for the user. Good AutoChanges must be written from the developers...
  • It will work in this way:
    • If global group must be opened (for every new set of Changes or Change it will open such a global group), it opens one with root Change which is the first Change of the new set. The method shouldOpenGlobalGroup() is used to check that. If there is already a root Change for the global group, it will return false, otherwise true.
    • If there is already opened global group, it will add the incoming Change to it. For that purpose, the method hasOpenedGroup() will be used.
    • If global group must be closed (the Change that opened the group is closing itself), all the subgroups will be closed and the global group will be closed, so the root Change of the manager will be null. That's the purpose of the willCloseGroup() method.
    • All the Changes grouped globally will be retrievable through the getAllChangesForResource() method.
  • All the global groups are virtual, they are not saved in the History of the Resources and are used only for displaying the list of the Changes to the users nicely.
• ResourceUndoManager - the new undo manager
  • It will be singleton, because it will be used only from the currently selected Resource and it doesn't need to know it at all, only the Changes that will be undone, redone, skipped.
  • For now it is only a skeleton that will be implemented in the next revisions, but it will be able to work with skipping.
  • It will be able to:
    • Create the undo and redo Changes from a Change.
    • To check if is possible to undo or to redo a given Change.
    • To execute (register) undo and redo acctions.

That's all for the logic... Now for the visible part:

• The edit menu items will be modified to use the new ResourceUndoManager.
• An AllChangesPalette will be added which will list all the Changes for the current Book, globally grouped.
  • For now there will be no interactions.
  • Most of the Changes won't be grouped nicely, because of bad AutoChanges and the lack of the Resource creation/destruction Changes.
  • The palette will use the GlobalResourceChangeManager.getAllChangesForResource(resource : Resource) method to get all of its changes, globally grouped.

For now, that will be the visible part. The next step is to make the undo/redo work, after that skipping (may be interacting with the Changes palette). The primitive Changes must be serializable to work with client-server communication and saving the History of a Resource. The Changes for creation and destruction of Resources must be designed and all the grouping of Changes (AutoChanges) have to be refactored. After that we can work on the visual part :)

There are tests for the new logic:

• DefaultChangeManagerTest
• ResourceChangeManagerTest
• GroupResourceChangeManagerTest

Revisions for the design related code:

• [2946]
• [2965]
• [3083]
• [3088]
• [3168]
• [3169]

Implementation

• Commited to the trunk long ago.

Testing

^{(Place the testing results here.)}

Comments

^{(Write comments for this or later revisions here.)}