A Parameter Pot (PP) contains parameter informations in a wide sense.
Provide a simple way to hold parameters.
Provide a way to access the parameters held by the Parameter Pot (PP) through a Data Drain (DD) or Data Source (DS).
Allow cascading of Parameter Pot (PP) to let pass parameters from the linked Data Source (DS)
Make parameters persistent between different times of program execution.
A Parameter Pot (PP) is a Aggregation of a Data Source (DS) and a Data Drain (DD) plus a data structure to hold the parameters. This structure was chosen because of limits in the used programming languge (no multiple inheritance).
By using Get_Data_Source and Get_Data_Drain it is possible to get an implementation of the Data Source (DS) and Data Drain (DD) interface, which enables the use of a Parameter Pot (PP) in the FET pattern structure.
The Link_Data_Source method provides a way of linking another Data Source (DS) to this Parameter Pot (PP). If a parameter for a given key cannot be found in the Parameter Pot (PP), the request will be delegated to the linked Data Source (DS).
If "Distribute" is called (see The FET pattern: data source, data gate, data drain,the Section called The FET pattern: data source, data gate, data drain in Chapter 9), and a parameter pot is used as Data Source (DS), all parameters in the linked Data Source (DS) are also given to the Data Drain (DD)`s.
Parameters are stored in simple key-value-pairs.
Setting and getting of parameter are done via the Set- and Get- Methods. Because Ada does not support multiple inheritance or something like Interfaces in Java, which would have allowed to handle all possible Parameter Types in the same way, we used aggregation to build a hierarchy of classes. These classes derive from a abstract class Pot_Element and every subclass encapsulates a Class, which you want to put into a Parameter_Pot. This allows us easy an easy extension of supplied classes, because for every new class, you want to put into a Parameter_Pot, simply derive a new subclass of Pot_Element, and overwrite the relevant methods, instead of changing the implementation of the Parameter_Pot.
These subclasses also handle the serialization of their encapsulated object in a XML-Structure (based on the GLib.XML library).
So if you want to put an object of some class into a Parameter_Pot, create a subclass of Pot_Element appropriate to object, and put this Pot_Element into the Parameter_Pot. If you want to extract an object, you have to do the same backwards (but take care: You have to do a downcast to get at your object!).
For some kinds of often used Classes (like Strings and Booleans), a Parameter_Pot has built-in methods to handle these. But internally, they are also implemented by Pot_Elements.
Here a small draft, how deserialization works:
The structure of XML-file, written by a Parameter_Pot is quite simple: A pair of "Parameter_Pot" tags enclose a list of "Pot_Element" tags. Every Pot_Element itself can be split up into a key and a value, where the value can be any kind of object, for which you have implemented a Parameter_Pot.
For every Pot_Element there is a function called Get_Element_ID. This functions returns statically the name of its Pot_Element, which is the tag used for serializing it.
So register every Pot_Element with a key (the return value of Get_Element_ID) and a Deserializer-Object, which builds a Parameter_Pot on a XML-Structure. An then iterate through your file, look up the tags and, if available, call the respective Deserialize function of the Deserializer-Object. The resulting pot element is then put into the pot.
Be careful: If you serialize parts of your graph-system (e.g. the RFG), make sure, that after Deserializatino you do not have 2 or more references to a single object of your graph-system, if the graph-system does not have mechanisms to cope with these multiple instances.
The deserializer class (for every parameter pot class there is a specified class) can be extended to access information, which is not provided by the XML structures (eg data from the graph system). Simply extend your subclass of the "Deserialize" class with the needed structures, and fill these structures by the paramters of the "Init" function. "Init" is not inherited, so you can extend it as you want.
Each Deserializer is registerd to a pot builder by calling the Init function of a Pot_Element. This call creates a deserializer-object and initializes it with his needed parameters.