|
static void | loadXmlConfig (const std::string &xml, Configurable *configurable) |
|
static std::string | xmlFromConfigNode (_xmlNode *config) |
|
static _xmlNode * | createCapabilityNode (const std::string &name, const std::string &method, const std::string &desc) |
|
static _xmlNode * | createCapabilitiesNode (const std::string &name, const std::string &desc) |
|
static _xmlNode * | addChild (_xmlNode *parent, _xmlNode *cur) |
|
static _xmlNode * | createParameterNode (const std::string &name, const std::string &hint, const std::string &value) |
|
static _xmlNode * | createParameterNode (const std::string &name, const std::string &hint, int value) |
|
static _xmlNode * | createParameterNode (const std::string &name, const std::string &hint, double value) |
|
static std::string | getParameterStringValue (const _xmlDoc *doc, const std::string &capabilityName, const std::string ¶meterName) |
|
static int | getParameterIntValue (const _xmlDoc *doc, const std::string &capabilityName, const std::string ¶meterName) |
|
static double | getParameterDoubleValue (const _xmlDoc *doc, const std::string &capabilityName, const std::string ¶meterName) |
|
The RoadRunner configuration system allows a collection of potentially disparate objects to have all of thier configuration parameters collected and assembled into a single xml document.
The hierarchy of Configurable maintians no additional state other than the local configuration parameters of each terminal node and the parent - child relationships. The xml document / nodes exists only for the lifetime of the createConfigNode / loadConfig calls. No xml objects should ever be maintined outside these method calls.
There are two method in the Configurable interface, one returns a configuration as an xml node the other allows the object to load or read its configuration from an xml document.
Classes that implment this interface must return either a capabilities, capability or parameter node. The static addChild function will automatically determine what type the child and parents are and add it in the appropriate location. So for example, say the both the parent and child nodes are 'cababities', in this case, the list of 'cabability' elements is pulled from the child and appended to the parent's capabitiles node as child nodes. This situation is encountered when a PluginManager is used. RoadRunner does not require nor is even aware of a PluginManager. RoadRunner considers itself a top level object thus returns a 'capabilities' node. The PluginManager contains a RoadRunner object, so when the PluginManager creates a 'cababilities' node, asks all of its plugins for a config, these are typically a 'cabability' which are added to the 'cababities' node that the PluginManager created. The PluginManager also asks RoadRunner for its capabilities, so in this case, RoadRunner's set of cabability nodes are automatically appended to the PluginManager's cababity nodes and a single combined document is returned.
Configurable is designed as a pure interface, one should NEVER create or delete a Configurable object directy.
This being said, there are a number of STATIC methods on this class to perform various configurable activities. As these are static, the do not affect the binary layout of this interface. They could also have been declared as pure functions, but were put here to make it clear that they perform Configurable activities.