Analysis
Overview
This task is the firs task of the GROUP_RESOURCE_MODEL_REDESIGN_R0. Task`s goal is to present working implementation of the new model with MemAccesses and keys and changes logic.
Task requirements
- Complete and stable design of the mem accesses hierarchy.
- Implementation of immutable resource model with correct manipulations.
- Providing logic for different keys getting.
- Providing logic for creatuons of changes, applying changes and resource revisions.
Task result
The result will be source code and documentation of aspects of the new designs that were too specific to be part of the major redesign documentation.
Implementation idea
- Read the GROUP_RESOURCE_MODEL_REDESIGN_R0
Related
GROUP_RESOURCE_MODEL_REDESIGN_R0
GROUP_FILE_ACCESSES_PERSISTENCE_R0
How to demo
Show the new hierarchy and demonstrate that all of the tests work.
Design
Read the major design of GROUP_RESOURCE_MODEL_REDESIGN_R0. In this tasks design are explained only the unspecified things of the first.
ResourceModel
The model will be constructed by immutable nodes that can either have value or children, but not both. Every 'value' node will hold the value of specific property that can be accessed by specific key. The 'children' nodes will hold maps of names and corresponding nodes so basically it is an immutable tree structure.
The path in this tree structure will be going through nodes that correspond to parts of the keys id and getting a keys value is just finding the right value node and getting its value. For example if you are looking for the value of the border color of 'page A' you should look in the tree nodes as follows : root(“”)->children->PageA->border->color. All nodes except the last one are children nodes and the last node will be value node with the ImmColor as its value.
Since all nodes have only final values the modifications on this model will return new instances of the model with all modifications applied. Furthermore it will be too heavy to apply every change on its own and copy the model for every alteration so the modify method should take as argument a Map of keys to be changed and their new values.
The model will need only correct changes so the ModelChangers should take care of producing some times more than one write so that would be easier for developers to write AutoActions.
Accesses
The mem and file accesses would have basically the same logic except that file accesses should present additional logic for persistence. For this abstracts common parent classes should be created:
LocalRootAccess – Keeps an list of all created accesses and when asked to open() an top access, looks in it for already created one to the given location (ref). Provides abstract method createTop() to be implemented of the concrete Mem and File RootAccesses.
LocalTopAccess – Provide abstract methods createInner() to be implemented by the concrete Mem and File TopAccesses. It does not memorize the created accesses because they don`t have a state. When asked for an inner access it creates a new one that delegates to it.
LocalInnerAccess – Delegating logic to its top access.
There are tests for most of the functionality – [4717]
Implementation
Since the task needed a prototype before implementation and then it was extended to the actual implementation the design code and implementation code are commited in one changeset - [4717].
There was also a slight alteration in the design of the AutoAction base class to make it easier for developers to change the model. There was added functionality for the AutoAction classes to create ModelChanges by apssing their constructors a desctiption and isSignificant flag. Also we added an 'register' method that extracts the fields from the auto action object and creates and registers the ModelChnage for this auto action to a given ResourceAccess - [4785].
Testing
(Place the testing results here.)
Comments
(Write comments for this or later revisions here.)
