The configuration service is used by the web client for several areas, for example the error page, the contents of several selection lists and the property sheet component.
The configuration service uses an amalgamation approach. An object is given as the context and a lookup is performed to retrieve all the configuration that matches that object.
There are several built-in evaluators that can be used i.e. 'string-compare' and 'object-type'. Other custom evaluators can be plugged in by specifying them at the top of the config file (see example below). All configured evaluators are called and passed the context object. If the evaluator matches that section of config is added to the result.
All sections that match are merged into one result, this allows a fine grained configuration approach, and also allows overriding of configuration data. However, this does mean that configuration is sensitive to the order things are defined in the file, basically, the last item wins.
This 'lookup' algorithm, however, can also be customized and plugged in when a config lookup is performed.
If you just need some configuration for something and don't need the combining of results this can be easily achieved by just using the 'string-compare' evaluator. In the example below there is a section named 'Action Wizards', this can be retrieved and consumed by passing a String object to the config lookup.
The config service can be configured to use multiple config files to avoid having the one mammoth large file. Once read though, the contents of all the files are combined into one in-memory object representation.
The config files can also be sub-sectioned into application areas. This means that if different configuration is required for the same aspect in different parts of the application it can be achieved, for example in the spaces view the property sheet could be configured to display all dublin core properties but in a dashboard view only show one of them.
Finally, custom config elements can be added to the config files and interpreted via a config element reader plug-in. For example if a developer added a new page to their application and they want to dispatch to it according to the aspect they may want a <custom-thing> element. The plugins are registered against the element name. All the well known config elements have built in plug-ins. If an element doesn't have a plug-in associated with it a generic element reader is used.
Property Sheet Configuration
As mentioned above a context object is passed when a config lookup is performed, in the case of property sheet configuration, a Node object is passed. The 'aspect-name' and 'node-type' evaluators are then used to determine whether a particular section of config matches depending on whether the Node has the configured aspect or node type.
For example, one section of config will define what properties should be shown for Node's that have the dublin core aspect and another section of config will define what properties should be shown for Node's with the versionable aspect. When a Node that has both these aspects applied is used as the context of a config lookup the set of properties to show for the object will consist of a combination of dublin core and versioning properties.
The format of the XML is shown in the box below (taken from web-client-config.xml and web-client-config-edit-properties.xml)
The config service currently only supports one occurrence of the same named element in a config section i.e. there can only be only <property-sheet> element. If there is more than one the last defined one wins, this behaviour may change in the future though.