Project

General

Profile

Dynamic Properties in Client

Dynamic properties are not fully implemented in the client side. The reason is because they were not part of the initial design so that the "dynamic" feature is not well supported.

Data Structures

There are two main layers in the client:
  • NomadCommandSystem
  • NomadGUI
The main class in NomadCommandSystem for managing dynamic properties is PropertyManager which has the following members:
  • Map<String, Map<String, XMLDynamicPropertyDescriptor>> dynamicPropertiesByControllerType;
    • key = controller type
    • value = Map(key = generic property name value = DynamicPropertyDescriptor)
    • the generic property name is the name without .i index.
  • Map<Integer, HashMap<String, DynamicProperty>> dynamicPropertyMap;
    • key = Servant id
    • value = Map(key = real dynamic property name value = DynamicProperty)
    • the DynamicProperty has the list of real property ids (size is the size of the dynamic property)
The dynamicPropertiesByControllerType map:
  • contains the descriptors
  • is initialized at the startup
The dynamicPropertyMap map:
  • contains the real properties
  • can be updated at runtime by synchronizing nomad server
The main class in NomadGUI for managing dynamic properties is ControllerPlugin which has the following members:
  • List<String> dynamicProperties;
    • contains role.genericPropertyName (populated while parsing config file)
  • Map<String, Property> realDynamicProperties;
    • key = role.realPropertyName value = Property
The dynamicProperties map is the equivalent of dynamicPropertiesByControllerType and realDynamicProperties is the equivalent of dynamicPropertyMap.
The realDynamicProperties map is updated by:
  • updateProperties
  • DynamicComposite.create after propertyChanged event

The update by DynamicComposite should be split into ControllerPlugin for the new properties. For future dynamic properties with dimension 2, it would be easier.

Use Cases

In the server with the DynamicProperty<> class template, it is now easier to code "real" dynamic properties i.e. properties with size changing at runtime. However some use cases are still not possible:

Settings view: changing size dynamically

  • server is updating the properties
  • client is synchrone
  • after propertyChanged event, client properties can be updated
  • DynamicComposite widget supports it well
  • Java specific code can also be written with dynamic properties dim. 2

Settings view: load a saved config

  • when the size of the dynamic properties is changed during the loading, the update is ok because a piece of code was added to force the synchronization
  • implemented in SettingsControllerSetupPlugin.load
  • the method Controller.updateDynamicProperties is called to update PropertyManager
  • the method updateProperties is called to update ControllerPlugin from PropertyManager
  • not that the additional code is slowing down the execution of the loading because there are calls to the server after each non-dynamic properties set value

Command box: load a saved config

  • if the size of a dynamic property in the loaded config is greater than the size of the real dynamic property, an error occurs
  • it does not work because the client cannot use properties that do not exist on the server side

Command box: DynamicComposite

  • same problem than for loading a saved config

The concrete solution for the two last use cases is to have not "real" dynamic properties but dynamic properties pre-allocated in the server. However we loose the dynamic feature because a maximum size must be provided.

New Model

The best solution is to design a new model in the client to manage the dynamic properties:
  • have a real model of dynamic properties based on the generic name
  • possible "virtual" properties (that do not exist yet in the server)
    • how to manage the fact that they cannot have an id?
    • dynamic property id + index?
  • minimize the copy of data structures
    • do not duplicate the maps in ControllerPlugin and PropertyManager
    • synchronization is more difficult

Appendix

The PropertyManager, PropertyDatabase and PropertyFactory are related:
  • The PropertyDatabase is populated by all the properties of the server (contains Property descriptors)
  • The PropertyManager uses the PropertyFactory to create Property objects
    • The Property objects are created from the Properties.xml file but also on demand when it does not exist in the PropertyManager but exists in the PropertyDatabase

Notice that the container id attribute of the Property is not very useful (at least for command box)