Manages a set of configuration classes.
The ConfigManager is responsible for handling a set of configuration classes. For flexibility (for the case an executable is called from another one), this class is not implemented as a singleton, but a factory method is provided, which returns the manager instances based on an ID.
Each manager instance is responsible for managing a set of configurations, which can be registered by using the registerConfiguration() method. When this method is used, all the dependencies of the configuration being registered are also registered automatically.
A manager can be under the following states, which describe how it can be used:
- Registration phase: This is the state a ConfigManager instance is in right after creation. During this phase configuration types can be added by using the registerConfiguration() method.
- Waiting for initialization phase: A manager goes in this state after a call to the closeRegistration() method. From this state on, the registerConfiguration() method cannot be used any more. The closeRegistration() returns a boost options_description which describes the options for all the managed configurations (it can be called more than once).
- Initialization phase: The initialization phase starts by calling the initialize() method. This method gets as arguments the user parameters to initialize the configurations with. During this phase, the manager performs three actions. First, it calls the preInitialize() method of all its managed configurations, in arbitrary order. Second, it calls the initialize() method of the managed configurations, in such order so all dependencies of a configuration have already been initialized before its method is called. Finally, it calls the postInitialize() methods, again in arbitrary order.
- Initialized phase: When all the managed configurations have been initialized (as described above) the manager enters the initialized state. At this phase, the user can use the getConfiguration() method for retrieving the information he needs.
Definition at line 81 of file ConfigManager.h.
po::options_description Euclid::Configuration::ConfigManager::closeRegistration |
( |
| ) |
|
void Euclid::Configuration::ConfigManager::initialize |
( |
const std::map< std::string, boost::program_options::variable_value > & |
user_values | ) |
|
Initialize the manager.
This method gets as arguments the user parameters to initialize the configurations with. During the initialization phase, the manager performs three actions. First, it calls the preInitialize() method of all its managed configurations, in arbitrary order. Second, it calls the initialize() method of the managed configurations, in such order so all dependencies of a configuration have already been initialized before its method is called. Finally, it calls the postInitialize() methods, again in arbitrary order.
When this method returns, all the configurations are in FINAL state and the manager in INITIALIZED state.
- Parameters
-
user_values | The user values to initialize the configurations with |
Definition at line 157 of file ConfigManager.cpp.
References Elements::Logging::debug(), Euclid::Configuration::Configuration::FINAL, INITIALIZED, Euclid::Configuration::logger, m_config_dictionary, m_dependency_map, m_state, Euclid::Configuration::Configuration::PRE_INITIALIZED, and Euclid::Configuration::recursiveInitialization().
template<typename T1 , typename T2 >
void Euclid::Configuration::ConfigManager::registerDependency |
( |
| ) |
|
Registers a dependency between two configurations.
This method can be used to define extra dependencies between configurations than the ones defined by the configurations themselves. Calling this method does not register the related configurations. If any of the related configurations is not registered during the registration phase, the dependency is ignored.
The meaning of the template parameters is that the T1 depends on T2.
- Template Parameters
-
- Exceptions
-