GlobalObjects
|
In order for GlobalObjects to work, some preparations have to be made. All the necessary files and settings that GlobalObjects needs to be able to save, read and delete objects are addressed here. This can be done by the GlobalObjects tool GloDeveloper. The GloDeveloper is the application with which GlobalObjects object databases are created and all necessary header and source files for classes of persistent objects are created or maintained.
GloDeveloper is a typical MDI application. The objects to be edited independently, such as classes, are edited in separate document windows, only dependent objects, such as attributes, are edited in dialogs.
GloDeveloper after the first start.
Note: The GloDeveloper can be started by passing a project file (e.g.: GloDeveloper.exe "D:\Projekte\GlobalObects xx.xx\GloExamples\Bases\FirstGloProject.prj"
), which is then read in.
Object databases are created in projects. GloDeveloper can manage several object databases in one project. This is helpful, for example, if a class is to appear in several object databases; you can copy or move it from one object database to another.
In this example, the object database respectively the GlobalObjects schema should be created in the directory "D:/Projekte/GlobalObects xx.xx/GloExamples/Bases/"
.
After starting GloDeveloper a project can be created. A description can also be written.
The new project is saved under the name "FirstGloProject".
The output looks something like this:
Now we can create an object database (respectively a GlobalObjects schema).
The name of the object database is FirstGloBase.
The GlobalObjects schema is stored in the directory "D:/Projekte/GlobalObects xx.xx/GloExamples/Bases/"
.
In the data subdirectory "D:/Projekte/GlobalObects xx.xx/GloExamples/Bases/FirstGloBase"
the data will be saved later.
The header and source files to be generated for the individual classes are stored in the directories "D:/Projekte/GlobalObects xx.xx/GloExamples/Bases/include/"
and "D:/Projekte/GlobalObects xx.xx/GloExamples/Bases/source/"
.
When the dialog is confirmed with [OK], the database is created with the base class glo::Persistent.
Now the first persistent class can be created.
The class gets the name FirstClass. When the input field "Class name" is left for the first time after entering a name, this name is taken as "Object file name" and "Header file name"; we leave it at these names (but could be overwritten). This class was automatically created as a subclass of glo::Persistent.
A persistent attribute, which gets the name FirstAttribute, is created via a dialog. When the "Attribute name" input field is left for the first time after entering a name, this name is taken over as the "Object file field name" (but could be overwritten). Additionally the attribute gets a description.
The new class is not yet in the GlobalObjects schema. This can be achieved with the [Accept] or [OK] button.
The new class is displayed in the project catalog.
The database respectively database schema can be saved now or later.
The output looks something like this:
To generate all required files, the menu Create / Create all files of the selected object must be visible. A right mouse click in the project catalog is sufficient for this. To generate all files for the object database, the entry FirstGloBase or the entry Classes below it must be selected.
The output shows what has been done. When the creation of the files is triggered for the first time, the output looks something like this:
In the following the resulting files of the project "FirstGloProject" are shown and their meaning is described.
The project file "FirstGloProject.prj"
created by GloDeveloper can be reloaded by GloDeveloper for further processing. It should not be edited directly by the user.
This is how the FirstGloProject.prj looks like.
GlobalObjects needs a GlobalObjects schema file for each object database to build C++ objects from object files and object files from C++ objects. The file "FirstGloBase.ini"
, created by GloDeveloper, is listed here for completeness and should not be edited by the user.
Further information about the GlobalObjects schema file.
In order for GlobalObjects to create objects from the object database, an object creator class is required that knows which objects correspond to a class ID and can instantiate them. The file "FirstBaseObjCreator.h"
generated by GloDeveloper in the specified header directory is integrated into the own project and should not be edited directly by the user. All persistent classes are included by the object creator.
Example of the FirstBaseObjCreator.h.
The header file "FirstClass.h"
of the persistent class FirstClass generated by GloDeveloper in the specified header directory can be changed and extended by the user as far as possible. The only area needed by GloDeveloper is the one between the entries "private persistent:" and "private transient:". If the comments starting with "//@@glo" are removed, GloDeveloper will not update these areas anymore. It is recommended not to remove these comments.
Please add a Get- and Set-Method as shown below to be able to read and set the attribute "FirstClass.FirstAttribute"
in the following program. This area is not "touched" by GloDeveloper when changes are made.
The source file "glo_FirstClass.cpp"
of the persistent class FirstClass generated by GloDeveloper in the specified source directory must be included in the software project. It contains instructions for GlobalObjects and should not be edited by the user.
Example of the glo_FirstClass.cpp
In order that the application to be created knows where the object database can be found, a "DB.ini"
with the following content must be created in the directory of the application
If the GloServer is to be tried out, the "DB.ini"
should be in the directory of the GloServer and look like this
For each persistent class, GloDeveloper creates an object file in which the values of the individual attributes are written.
The following section describes how objects of the persistent class FirstClass are stored in the object databases and read from them again.
Prerequisites:
"$(EUCPPDIR)/GlobalObjects/include"
, "$(EUCPPDIR)/EuTools/include"
, "$(EUCPPDIR)/PtlContainer/include"
and "D:/Projekte/GlobalObects xx.xx/GloExamples/Bases/include"
must be included. "EUCPPDIR"
holds the path to the directory "Src"
, see also GlobalObjects Environment variables and Setup GlobalObjects C++ header. GLOAvXXXXXXXX.dll
must be included. See also Setup Biblioteken (LIBs und DLLs). There are two commented example Main.cpp files available.
Important are the following lines, which are explained here again:
In order to be able to read or write and modify objects from GlobalObjects, a glo::Base with a corresponding object creator must be instantiated. See also description of the constructor of glo::Base.
respectively
It is not yet possible to work with the object database, therefore you have to connect and open it. This is summarized in the method glo::Base::openBaseComfortably (...).
The return value (int t_iErr) should be evaluated.
To iterate through the set of persistent objects of a type the glo::TAllSet is the right class. The AllSet is instantiated with the template parameter of the desired class and with the opened object database as parameter.
The following line loads the first stored object in the transferred parameter "t_spShowPersObject"
from the object database.
The loaded object is as expected with its values in memory!
Now we come to the registration and saving of a persistent object. First of all a persistent object is instantiated. Since a persistent object can only be removed from memory using glo::BasePersistent::forget(), a corresponding "deleter" is passed:
The values in the object can be set. Before the object can be saved, it must be given a unique object ID (see also glo::ObjID). This is done by logging on to the object database. A persistent object has to be logged on to the object database only once, before it is saved for the first time. Afterwards it keeps its unique object ID.
If all goes well, the object can be stored.
Finally, the object database must be closed because, among other things, the current indexes are written.