wiki:GROUP_CHANGES_R1
Last modified 16 years ago Last modified on 06/29/09 13:51:02

Error: Macro BackLinksMenu(None) failed
compressed data is corrupt

Error: Macro TicketQuery(summary=GROUP_CHANGES_R1, 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 goal of this task is to do refactoring of the usage of Changes and ChangeManagers (and also respective refactoring in affected code) in order to achieve the following:

  • improved ProLib performance,
  • preparing the ground for implementing the UndoManager (optionally provide a prototype),
  • and optionally, improve and/or fix ProLib tests by the way.

Task requirements

In more detail, the following should be done:

  • About ProLib performance:
    • improve locating of ChangeManagers for Pros:
      • this is expected to give a performance boost overall since currently locating of ChangeManagers for lots of objects is done by iterating through the object's parents list until the ChangeManager of the ResourceSpace the object is associated with is reached and returned. After the refactoring this should take constant time.
      • it is also expected to improve some nasty code's readability and correctness.
      • some additional constraints should be enforced on the possible relations between ProObjects and Resources in order to achieve this refactoring. List them and take them in consideration when implementing.
      • refactor all affected code.
  • About UndoManager:
    • proposal of a possible prototype should be designed and created,
    • or you should list and implement improvements which would ease the implementation of the UndoManager in the next revision.
  • About tests:
    • some ProLib tests should be picked and improved:
      • should be fixed if not working,
      • should have @SuppressWarnings("all") and similar removed and promptly documented and cleaned up from messy code.

Task result

  • possibly, performance improvement,
  • improved code,
  • possibly, UndoManager prototype,
  • some improved tests.

Implementation idea

  • Change BaseProObject's constructor to have an additional ChangeManager parameter and fix affected code as appropriate.

How to demo

  • Show expected performance optimization or at least some proof this optimizes performance.
  • If possible, show the UndoManager prototype.
  • If any progress on this, run improved unit tests.

Design

ProLib performance

  • Each ProObject should be bound to a specific ChangeManager when constructed.
    • The ChangeManager responsible for each Pro should:
      • either be the DefaultChangeManager, in the cases when Changes to the Pro are not expected to be processed in a special way (like the Aspects Changes or in a testing scenario),
      • or the Pro will be associated directly or indirectly with a ProObject and thus the ProObject's ChangeManager will be responsible for processing the Pro's Changes.
    • As a consequence, this would remove the need for attach and detach operations for ProObject to a ResourceSpace because a given ProObject will reside only in one ResourceSpace and respectively will have only one ChangeManager during its lifetime.
    • As another consequence the ProObject interface will have a new method getChangeManager() which returns the ChangeManager responsible for this ProObject.
    • Pro's method locateChangeManager() will be renamed to getChangeManager() because now the ChangeManager isn't being located by some algorithm, it is simply returned.
    • There will be changes to BaseProObject constructors:
      • there'll be a new constructor will have a single ChangeManager argument which will be assigned to the BaseProObject
      • there won't be a default constructor. This is intentional to force people to think what ChangeManager they want to be responsible for their ProObjects.
    • when creating a new ProObject which doesn't extend BaseProObject, it is the implementor's responsibility to provide logic for the ChangeManager responsible for the ProObject:
      • by providing different constructors in analogy with BaseProObject,
      • or by simply returning the DefaultChangeManager in the getChangeManager() method.
    • There will be changes in the Resource-related classes:
      • Resource, ResourceSpace and ResourceChangeManager creating and initalization order will be refactored a little to be able to invoke the BaseProObject constructor with an existing ResourceChangeManager in the Resource constructor
      • Resource.changeManager() will no longer exist (because it is an AutoProperty). Its place will be taken by the normal Java method getChangeManager() (derived from ProObject.getChangeManager()).

  • assigning of ChangeManagers:
    • ProObject will be assigned a ChangeManager at creation,
    • Properties will use the ChangeManager of their owner ProObject,
    • ProBeans will use the ChangeManager of their corresponding ProObject,
    • In other cases there won't be a default implementation of getChangeManager() and use cases will be solved per case.

UndoManager improvements

  • ResourceChangeManager will become BaseProObject so an AutoProperty<ResourceChangeManager> currentManager() can be created, to track the ResourceChangeManager responsible for the currently active Resource.
  • ChangeManager of the ResourceChangeManager will be the DefaultChangeManager.
  • No prototype will be done now besides the changes described above because there won't be enough time.

Misc refactoring

  • will refactor ResourceRef.getRelativeRef() to directly use the known ChangeManager and not iterate trough the parents,
  • will refactor ResourceRef.get() in a similar fashion,
  • will rename fullId() to debugId() in Pro,
  • will remove the empty, not needed Property() constructor,
  • will add a parent Frame argument to FrameProvider.getFrameContent() method so the created FrameContent can have the ChangeManager of the parent and will refactor affected code,
  • will refactor some existing Changes which are used no more or not in the appropriate way (like the ProObjectChanges).
  • will refactor the checks for attaching and detaching a ProObject to a given ResourceSpace because they are no longer needed. This will also lead to a performance improvement.
  • will improve java doc and code quality mainly in the ProLib by the way as doing the other refactoring.
  • if there's enough time, I'll try to update from trunk the new Groups logic and merge my new logic with the Groups logic.

Tests

  • I'll merge meddle's tests from the previous revision of this task and fix them with the new changes.
  • During merging I'll see if new tests are needed and will implement them.
  • Most of the logical changes in I've done in the source are asserted. Also I've added assert to misc places by the way as I refactored stuff.

Implementation

branches/private/gogov/GROUP_GHANGES_R1

Merged to the trunk in [3795].

Testing

(Place the testing results here.)

Comments

  • we should list which Properties we describe as bottom Properties. AFAIK they are:
    • ValueProerties
    • ListValueProperties
    • AutoProperties with custom doSet() predefined
    • const AutoProperties
  • in the next revision we should describe a mechanism for giving ids to ProObjects.
    • the concept of a creator ProObject might be useful