Interfaces of the data value and data module

Hi,

as promised yesterday today I'll show you the interface to the data value and the data module. In fact, as I stated yesterday, the data value interface is quite small since it only has to identify the type and to provide basic getter and setter functions.

I was thinking about the most flexible way of usage for the interface. Since it is this tidy and tiny, the actual data getter and setter must be simple, too. I finally decided to make usage of strings (Note: ScxmlString is actually a typedef of std::string). The reason is simple: Everyone can handle strings with too much hassle and almost every type of data can be described using a string. An integer is as easy to put into a string as is a float. An array of numbers can be put into a string used a separator.

Furthermore, as I said yesterday, the datamodel itself is 90% linked to the script module (since the script module would be responsible for the expression parsing). This implies that the developer who's implementing the script module interface, would also make sure that the implementations of the different types of data values (integer, strings, floats, even objects) can easily be handled by the script module. This means, that the derived class may include access functions that bypass the get/set functions that make usage of strings. A derived integer class easily can implement a get and set function that makes usage of an integer. The script module only has to determine the data value type and cast the interface accordingly.

Thus, the interface of the data value in its basic form looks like this:

class IDataValue
{
 /** \brief Identifies the type of the data.
 *
 * \return a string containing the identifier.
 */
 virtual const ScxmlString& type() = 0;

 /** \brief Access the data.
 *
 * \return a string containing the data value.
 */
 virtual const ScxmlString& get() = 0;

 /** \brief Set the data.
 *
 * \param a string containing the data value.
 */
 virtual void    set(const ScxmlString& _value ) = 0;
};

My first draft of the data module interface looks as simple as the interface for the data value. Currently only 3 functions are defined: a function to set data, a function to get data and a function to remove data.

Here it is:

class IDataModule
{
 /** \brief Get data as a string from the data module.
 *
 * \return true, if the named date exists within the data module. False, if not.
 * \param _name  Name of the data to fetch.
 * \param _out  This variable will store the fetch result.
 */
 virtual IDataValue*  getData(const ScxmlString &_name) = 0;

 /** \brief Set data.
 *
 * Data that is set in this way will be set to the data module.
 *
 * \return true, if the data could be set; false otherwise.
 * \param _name  Name of the data. This name must be unique. If the name is not unique, it will replace the data value that has been stored using that name before.
 * \param _val  Content of the data.
 */
 virtual bool  setData(const ScxmlString &_name, const IDataValue*_val ) = 0;

 /** \brief Remove a data entry.
 *
 * The named data will be removed from the data module.
 *
 * \return true, if the data could be removed. false otherwise.
 * \param _name Name of the data.
 */
 virtual bool  removeData(const ScxmlString &_name) = 0;
};

These 3 function would enable the developer to manage a set of data values within the data module. The identifiers (names) must be unique but that's part of the script module (or the implementation that makes usage of the datamodel interface).

Nevertheless, the interface for the data module is not complete. At least, that is my opinion ;) On monday or latest tuesday I'll tell you what is still missing and how that stuff is looking like.

Until then: Have fun,
Stefan