| Basics of the construction and functionality of HSOK: The kernel object |
|
| 20 June 2007 | |||||||||||||||||||||
Page 9 of 9 The kernel objectThe classes functioning within the HSOK are coordinated by one, global kernel object which is returned by the HSObjectKernel function. The user can create his own kernel object inheriting from THSObjectKernel class and assigning it to a global UserKernel variable (significant in case of using HSOK in different *.bpl modules). The HSOK kernel is a central repository of resources and services. These are interfaces and edit functions registered in it. Objects providing services through interfaces may be registered in the kernel with the RegisterInterface method and unregistered by UnregisterInterface method. An application can retrieve a needed interface with the GetInterface function. For each THSField descendant you can register in the kernel an edit function of its data, defined as : TEditFunction = function (Field : THSField; Preview : boolean = false) : boolean; An edit function is registered in the kernel with the RegisterEditFunction method. Whenever you call the EditData method of any object, the kernel looks for the edit function registered for this class and runs it. If there is no edit function registered for that class, kernel runs the default edit function specified by a global variable DefEditFunction, if it is set. If not, then with the option $C+ (Assertions) on an exception is raised. This mechanism ensures separating the data management layer from the data presentation layer, while still having the ability to run data edit functions from any place within the application. It gives also other possibilities. You can override method EditData of the class and run the edit method of the ancestor. You can use different edit methods depending on the context of the application. And finally you can create a transport layer providing editing local data on remote machine. But most often this mechanism is used to add to an application forms generated by the Class Editor. These forms register themselves in the HSOK kernel in the initialization section of their own modules, so it is enough to add these modules to the project to use edit forms for corresponding classes. The DefEditFunction variable is used mainly to capture edit method calls for classes that have no registered edit forms and to tunnel these calls to the default edit window, generated in runtime (module HSDefEditForm.pas). The kernel also implements RTTI mechanisms for classes that do not implement them directly. The Class Editor creates automatically functions FieldClassByIndex and FieldNameByIndex according to data input by the user, overriding methods implemented in THSBaseObject. If someone writes source code of a class manually (which we do not recommend) and does not implement these methods the class will use kernel services by default. In that case the kernel will gather needed data from Delphi's RTTI, additionally buffering it for future calls. The Class Editor can generate on demand an optimized version of the FieldIndexByName method, but by default it is covered by the kernel. to be continued...
|
|||||||||||||||||||||





