SYSTEM/Split manager class

[djoproject]

TODO starting hash will disappear and other update will be applied in the manager (see #111), but probably a link to original parameter will remain because of the reset commands. Update this issue as soon as it is decided.

Description

At the beginning, only the parameters needed the manager, but now, commands and addons will be stored into a manager:

• addons only need local/global
• commands need local/global and addon origin
• parameters need local/global, adon origin and origin hash

The idea is to split the manager class into four classes that inherit from each other:

• AbstractManager(object): list of methods implemented by a manager
• AddonManager(AbstractManager): manage local/global
• CommandManager(AddonManager): track addon origin
• ParameterManager(CommandManager): manage origin hash

TODO

• define the methods to implements
• then ?

Depends upon

• 111

Dependency for

• 108

• 90

[djoproject]

0 New approach: split in services

One and only one kind of node, no more node inheritance. This node will hold a list of services and nothing more, no value. Each service must be as much independent as possible from the others.

There are currently 3 services:

• basic: manage a single global value.
• scope: manage local values.
• origin: manage value attached to a loader and maybe having an original value coming from this loader.

More services could appear in the future without needing a new refactoring of the manager classes. A node without any service has no purpose and must disappear.

To combine services, just create a class inheriting from the needed managers. It must be as simple as that.

1 The abstract manager, the service node and the abstract service

1.1 Abstract Manager Class

1.1.1 Fields list

• mltries: a multi level tries to store the service node

  1.1.2 Methods list

• hasNode(key): return True if the node exists, false otherwise
• getNode(key): return the node if it exists, raise otherwise
• createNode(key): create the node if it does not exist, do nothing otherwise. Return the node.
• cleanNode(key): remove the node from the mltries if possible

1.2 Service Node class

1.2.1 Fields list

• services: a dict that contains all of the services

  1.2.2 Methods list

• hasService(key): return True if the key is in the dict, False otherwise
• getService(key): return the service if it exists, raise otherwise
• setService(key, value): set the service if it does not exist, raise otherwise
• removeService(key): remove the service if it exists, do nothing otherwise

1.3 Abstract Service Class

1.3.1 Fields list

*

1.3.2 Methods list

• isRemovable(): if the service consider itself useless and can be removed, return True, False otherwise

2 Basic service

2.1 The basic manager class

2.1.1 Fields list

• 2.1.2 Methods list

• setParameter(key, parameter):
• getParameter(key):
• unsetParameter(key):
• hasParameter(key):

2.2 The basic service class

2.2.1 Fields list

• value

  2.2.2 Methods list

• setValue(value):
• getValue(): No need of hasValue method, the presence of the service in the services list will answer this question

3 Scope service

3.1 The scope manager class

3.1.1 Fields list

*

3.1.2 Methods list

*

3.2 the scope service class

3.2.1 Fields list

• values: a dict of values

  3.2.2 Methods list

• setLocalValue(key, value):
• getLocalValue(key):
• hasLocalValue(key):

  3.3 Problems with this design

  3.3.1 the scope service must chose to store either in basic, either in local, and so is linked to basic manager. It is the same for getParameter.

4 Origin service

4.1 The origin manager class

4.1.1 Fields list

• groups: a dict of all the added group, key is the name, value is composed with the group_manager, a set with the nodes used or created at during the addGroup call, and a set with the nodes associated to the group used/created during the setParameterOrigin call.

  4.1.2 Methods list

• addGroup(group_name, group_manager): add every parameter stored into the group manager and freeze them, this group manager must be an instance of the basic manager. If at least one parameter already exist and is attached to another group and is frozen, raise and do not add any of the parameters from the group. None value is not accepted for group_name.
• removeGroup(group_name): remove every parameters from the manager, remove every origin service object for this group, clean every node associated, then return a dict of the parameters that still existed at the time of the remove
• setParameterOrigin(key, group_name): set or update the group origin name for a parameter. If a group name already exists and is frozen for this node, raise.
• getParameterOrigin(key): return the

4.2 The origin service class

4.2.1 Fields list

• group_name: the groupe name associated to this parameter
• frozen: boolean, default value is False. If the parameter didn't exist in group_manager, this parameter won't be frozen and could change of group_name

  4.2.2 Methods list

• setOrigin(group_name): set the origin group name for this node, raise if frozen is set to True, None value is not accepted
• getOrigin(): return the group_name
• freeze(): set the boolean frozen to True. There is no hasOrigin method, if the service does not exist on the node, the node has no origin.

4.3 Problems with this design

4.3.1 parameters added without any origin, need a default group ? how to track them?

4.3.2 origin is not independent, because it adds the parameter either in basic service, either in scope service

4.3.3 if it is possible to add a group in local or in global scope, need to know where it was added before to call the removeGroup. And also need to manage the case whene removeGroup is called with another local key than the key used for the addGroup