Home Notices Documents Classes Download Others Rice
Documents  >  Development  >  Dynamic embedded classes  >  Registration
Implementation for dynamic registration of classes

Purpose of this page

This page details the implementation of the RtemplateEmbedder.cs.

RtemplateEmbedder.cs is responsible for dynamic registration of classes into the application.

The first section explains how to dynamically register classes into the application.

Next, we will explain the IEmbedPrototype class which is an interface class for dynamic registration.

Next, we will explain the Embed() method which is the only method of IEmbedPrototype class.

Finally, example of implementation is explained.

Mechanism of dynamic class registration

Only way for registeration a class to an application is to call the AddBuiltIn() method of the RiceManager class. Rice does not have other way for loading a class into the execution environment.

The AddBuiltIn() method takes a class name and a delegate as arguments. For example, registration of the template class to the execution environment is as follows.

RiceManager.AddBuiltIn(Rtemplate.TYPENAME, Rtemplate.InstanceGenerator);

There is no problem about classes statically embedded in the CookerGX. Because their source files are included in the CookerGX project, both the class name and the delegate are known. Therefore, we can call the AddBuiltIn() method with the appropriate arguments.

The problem is the class that is loaded dynamically when the CookerGX starts up. These are unknown classes and neither class names nor delegates are known. We can not call the AddBuiltIn() method for these classes without taking some measures.

Fortunately, CookerGX has a mechanism to correctly call the AddBuiltIn () method for unknown classes.

Dynamic class registration to the execution environment has three points.

① : Directory where embedded class .dll files are located.

In the case of CookerGX, the embedded class .dll files must be placed somewhere in the directory hierarchy rooted in the dlls subdirectory of the execution directory - the directory where CookerGX.exe is located -.

② :Name of embedded class .dll file.

It has been explained in the overview page. Please see here.

③ : IEmbedPrototype interface

It will be explained below.


The IEmbedPrototype class is an interface class for dynamic class loading.

The definition of the IEmbedPrototype class is shown below.

1:public interface IEmbedPrototype {
1:void Embed(string path);

When dynamic class loading, Rice looks for the IEmbedPrototype derived class which there is in the .dll file with the corresponding name (②) from the directory hierarchy (①).

If there is an IEmbedPrototype derived class, Rice calls its Embed() method.

public void Embed(string path)

In the step above, the Embed() method in the .dll file is called. Since this Embed() method is included in the project of the .dll file, we know the class name and the delegate of the class to be embedded.

We can call the AddBuiltIn() method to register the class here.

When the Embed() method is called, the path argument is passed the absolute path of the .dll file.

Example of Implementation

An implementation example of the Embed() method for the template class is shown below.

Note that the path argument of the Embed()method is passed the absolute path of the .dll file.

1:public class RtemplateEmbedder : IEmbedPrototype {
2:public void Embed(string path) {
3:// class registration
4:RiceManager.AddBuiltIn(Rtemplate.TYPENAME, Rtemplate.InstanceGenerator);
5:// Sets message text.
6:FileInfo dllFile = new FileInfo(path);
7:string messageFilePath = dllFile.Directory.FullName + @"\message.template.txt";
8:FileInfo messageFile = new FileInfo(messageFilePath);
9:if (messageFile.Exists) {
12:else {
13:RiceManager.AddMessage("Rtemplate-mess001", "It is a message #1.");
14:RiceManager.AddMessage("Rtemplate-mess002", "It is a message #2.");

The above implementation can be divided into two parts.

The first part, the call of the AddBuiltIn() method has already been described.

The rest is example for how to use the path argument.

let's assume that the exception message required for the template class is stored in message.template.txt, and that file is in the same directory as Rtype.template.dll.

Since the absolute path of the .dll file is passed to the path argument, it is easy to create a path to a file that exists in the same directory from this path information.

If can create a path, we can check the existence of files and read messages. If the file exists, reads the message, otherwise registers the default message.

For example, if we store non-English messages in a file, we can realize easy multilingualization.

At the end

If you change the class name and implementation of the sample file appropriately, you should be able to build a new embedded class .dll file.

This document has been described assuming the template class. The template class is an explanatory class, so it does not have a function that can withstand practical use. However, there are already several embedded classes in CookerGX, all of their source code are publicly available. The implementation of the class actually used should help your embedded class implementation. These archive files are in the embedded class manual pages. Please use it as a reference for embedded class implementation.

Copyright © CookerGX All rights reserved.