Zen :: Core Register your Application with the Plugin System

One of the first things you do in your Zen compatible application is to register it with the [zoss/Core#PluginSystem? Zen Plugin system].

The way you do this is with code like this:

std::string configFileName("config.xml")

I_PluginManager::getSingleton().installApplication(configFileName);

Note that you should only make this call once during the execution of an application.

config.xml

The configuration file name contains the path to an XML file that the plugin system willl load and parse.

<application>

The following snippet shows an example application called "Login". Zen Enterprise uses this information for identifying and authenticating the application.

<application
   id="Login"
   name="Login Client/Server Test"
   version="0.4.0"
   provider-name="IndieZen.org">
...
</application>

<plugin-path>

Another section in the XML file adds a path to where the plugin system can find additional plugin.xml files.

<application>
...
  <plugin-path path="C:/dev/Zen/plugins"/>
  <plugin-path path="C:/dev/community"/>
...
</application>

Note that a special character can be used instead of hard-coding the entire path, but in order for this to work correctly, you must first do this:

I_PluginManager::getSingleton().setRootPath(boost::filesystem::path('~', "C:/dev"));

And then the previous example can be changed to:

<application>
...
  <plugin-path path="~/Zen/plugins"/>
  <plugin-path path="~/community"/>
...
</application>

Hard-coding "C:/dev" is probably not a good idea and I'm only using it as an example. Using something like boost::filesystem::current_path() to get the current path, or looking it up in the system registry, etc might be a better idea. The perfect solution depends on your application, and so it's left up to you to decide what's best for your application.

<module-path>

Another section in this XML file is the module path. This indicates the paths that the plugin system uses to locate plugin module dll's. The order is important, and the first module that the plugin finds will be the one that is used.

<application>
...
  <module-path path="~/bin"/>
  <module-path path="~/MyGame/bin"/>
...
</application>

<requires>

The requires section indicates plugins that this application requires in order to execute. Note that these plugins will not be loaded until the application requests, but the related plugin.xml file will be parsed.

<application>
...
 <requires>
    <import plugin="Framework"/>
    <import plugin="ZBoostNetworking"/>
    <import plugin="LoginServer"/>
    <import plugin="LoginClient"/>
  </requires>
...
</application>

In this example, first the "~/Zen/plugins" and then the "~/community" paths will be searched. For the "Framework" example, the plugin system will look for "~/Zen/plugins/Framework/plugin.xml". If it doesn't find it, it will then look in "~/community/Framework/plugin.xml".

If the specified plugin.xml file is not found then a Utility::runtime_exception is thrown with an error message stating that the plugin cannot be located.

Again, note that the plugin.xml file is parsed, but the module .dll or .so is not loaded until the application explicitly loads it.