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.

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.)}