The parameter container factories
Each library, which contain parameter container classes, must also contain a parameter container factory. They are all derived from
HContFact.
They are created when the library is loaded into ROOT and added to the list of container factories in the runtime database.
Each factory contains the list of parameter container names and possible contexts, for which it is responsible.
Functionality
- They allow to create the parameter containers via a function call:
HParSet* getContainer(const char* containerName);
- For each parameter container they know the possible contexts and they take care for the name of the container when it is created.
Having different names, they can be read and written from/to the same ROOT file without the need to change the version management.
Naming convention:
- If no context was specified before, the parameter container is created with its default context and the name is the standard name.
- For non-default contexts, the name of the parameter container is concatenated as "standard container name" + "_" + "context name"
- Different, but somehow related containers may share the same context.
Setting this context once guarantees, that all these containers are initialized consistently. For example share all geometry containers the same context.
Examples for container factories:
HMdcContFact
HRichContFact (contains parameter containers with more than one contex)
Usage
The user typically does not access the container factory directly in the macro, but calls functions in the runtime database
Bool_t HRuntimeDb::addParamContext(const char* context)
This function sets via the context of all parameter containers, which accept this context. If a parameter container is created later by these factories, it will be created with this context.
HParSet* HRuntimeDb::getContainer(Text_t* standardContainerName)
The function loops over all container factories to find the factory responsible for the parameter container with the specified name. The factory then checks, if a special context is set, eventually concatenates the name and then checks, if a container with this name eventually exists already in the runtime database. If not, it creates the container and adds it in the runtime database.
The function returns a pointer to the container, with must be casted to the special container type, or NULL, if not created.
The Pid parameter containers use different contexts for different algorithms (Kickplane, Runge Kutta). But the default context is only a dummy string not known to Oracle. The usable contexts are not in the Pid container factory. Therefore the context must be set explicitly in the parameter container after creation. The name in a parameter ROOT file is always the standard name.
The contexts in the different parameter containers belong to a certain algorithm have individual names, and do not share the same context.
--
IlseKoenig - 23 Jun 2007