Skip to end of metadata
Go to start of metadata

Relates to:

Key requirements

  • Support for arbitary configurations from custom plugins
    • A Configurable interface, which as on it a property UUID that is guaranteed to uniquely identify the thing being configured.
  • Auto-save on change (i.e. don't need to keep telling it to save whenever a configuration option is changed).
  • Support bundled default configurations. (e.g. a set of colour schemes).

Underlying API to use

Those looked at are:

  • Apache commons configuration
    • text based key but retrievable as ints/strings etc. Can also retrieve as arrays so one key can have multiple values. Can reference property file from another which will be loaded when the file referencing it is loaded. No need for streams, load/save methods take care of this. Can autosave/hot reload.
  • JFig
    • XML based. Nested properties. Bit light on documentation. Can get strings, integers etc. Have to implement interfaces to get the initial config file, seems a bit involved for a simple config file.
  • Java Properties
    • simple hash table, everything is a string with key/value pair. Stream based for reading and writing.

Following on from some investigation, the  Apache commons configuration API is looking like the preferred API to use. 

Scratch design

  • The configuration UI and the Configurable have now been de-coupled with the use of an additional SPI.

Objects which can be configured and wish to remember their configuration state must implement the Configurable interface. They have a unique identifier, we have chosen a UUID, which is fixed for a particular instance. They also have a Map containing kay value pairs for the actual configuration item, these can be any type of Object (although in reality only ones which the Apache commons config PropertyConfigration can handle - Strings, Integers, Floats, boolean etc and arrays of them). To persist the config values you get an instance of the ConfigurationManager, set the baseConfigLocation and call its store method passing in the Configurable. This uses commons config to write out the config Map. To load values you call the load method and this returns the Map. The values are stored in a file called UUID.confid.

The ColourManager will return a value from the Map when passed a Colourable object into its getPreferredColour method.  The value in the map should be an Array of Strings.  These are the RGB values.  So, when you ask to return the preferred colour for a colourable object it will return a Color object based on these RGB values.

So, the process is.  Get an instance of the ColourManager.   Get it's propertyMap (TBD what to do about default colours so we can revert back to them).  Into this Map put the canonical name of the Colourable object and the Array containing it's RGB values.  Get an instance of the ConfigurationManager and store this ColourManager.