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

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.
• 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 to 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 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.
• Think of the primitive changes connected to Resource creation and destruction, also entering of a pro object into a ResourceSpace and leaving from it.
• Think of use cases connected to server communication and persistence.

Related

GROUP_RESOURCE_R0
GROUP_PERSISTENCE_R0

How to demo

• Unit tests.
• Demonstration:
  • Run the Sophie 2 author application.
  • Create a new book.
  • Insert a text frame.
  • See in the changes palette the change to this actions for the book...

Design

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.

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 that on the pro-objects will be trackable and will be Changes.
  • The Undo and Redo actions will have changes, because they can be skipped, unskipped.
  • Skip and Unskip have to be Changes to because they are also undo-able redo-able, skip-able and unskip-able.
• The changes will use the old GroupChange for grouping.
  • Groups can be created from the developer using the AutoChanges.
  • All AutoChanges will have 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.).
• About resources. Having in mind that Resources will be buildable from a list of Changes and will be transferable through the net to the server and back, we can look at the resources as a sequence of changes that describes their life time so:
  • There will be changes for creating and destroying resource, as beginning and ending of it's lifetime. (Will be implemented with the serialization in some of the next revisions).
  • There will be changes for entering of a pro object in a given resource space and exiting of a pro object from a given resource space.
  • All of the resources have 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 this ideas we can list all of the primitive changes that will be serializable and all the grouped changes will be set of them:

• Set a value to a non list property : ValueChange.
• Set an element to a given index of a pro-list : BaseProListChange.SET
• Add an element to a pro-list : BaseProListChange.ADD
• Remove an element from a pro-list : BaseProListChange.REMOVE
• Create a Resource : CreateResourceChange (will be designed in the next revision).
• Destroy a Resource : DestroyResourceChange (will be designed in the next revision).
• Create a pro-object in a ResourceSpace (Attach) : CreateProObjectChange. (may be better name is AttachChange or AttachProObjectChange).
• Destroy a pro-object that is an a ResourceSpace (Detach) : DestroyProObjectChange. (may be 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:

• Pro-object related changes:
  • There are some changes that are not in the UML diagram, they are connected with the pro objects only and are already implemented:
  • This changes are all descendants of the ProChange, and more accurately BaseProChanges:
    • BaseProListChange - there are three such changes ADD, REMOVE and SET, they are primitive changes for the pro-lists.
    • CountChange - Used for testing of the AutoTracker.
    • StatusChange - changes that track the status of the properties:
      • InitChanges - used for initializing of the properties they are not primitive changes, because when to a property a value is set they will be triggered automatically.

Implementation

^{(Describe and link the implementation results here (from the wiki or the repository).)}

Testing

^{(Place the testing results here.)}

Comments

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