wiki:GROUP_CHANGES_R1

Version 14 (modified by gogov, 16 years ago) (diff)

--

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.
    • BaseProObject will have two constructors:
      • default - it will assign the DefaultChangeManager to the BaseProObject
      • custom - it will have a ChangeManager argument which will be assigned to the BaseProObject
    • 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 like in BaseProObject,
      • or by simply returning the DefaultChangeManager in the getChangeManager() method.
  • 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,
    • BasePro will provide a default getChangeManager() implementation which returns the DefaultChangeManager,
    • in ll other cases the DefaultChangeManager is used.

UndoManager prototype

*

  • AutoProperty<ChangeManager> will be needed
  • ChangeManager not become BaseProObject, ResourceChangeManager becomes BaseProObject.
  • ChangeManager of all ChangeManagers is the DefaultChangeManager.

Misc refactoring

  • will refactor ResourceRef.getRelativeRef() to directly use the knows ChangeManager and not iterate trough the parents,
  • will rename fullId() to debugId() in Pro,
  • will remove the empty, not needed Property() constructor,
  • will improve java doc and code quality mainly in the ProLib by the way as doing the other refactoring.

Implementation

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

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
      • ...