Structuring a complex plugin

Some plugins are a lot easier to develop and maintain when they're broken up into multiple files, and I recently came up with a simple structuring paradigm to help achieve this. It's similar in concept to World of Warcraft's addons.

First, an example:


Under this structural paradigm, every plugin is contained within its own folder (which itself should be under plugins/). The main plugin XML is contained within plugin.xml, which you might relate to a .toc file in World of Warcraft. And the resources are contained in a further subfolder, named resources/ in this case.

The plugin's folder is suffixed with '.plugin' to differentiate it from normal folders. 'plugin.xml' is thusly named so that an automated tool could be told to "install Gauges", and it would look for Gauges.plugin and install its plugin.xml. 'resources' is an arbitrary name that simply explains its content decently, containing plugin-specific, non-script-file resources.

A plugin can access anything within its folder simply by using GetPluginInfo(GetPluginID(), 20), and concatenating the desired file/resource.


This isn't really a question nor a suggestion, but I like the structure this gives me, and I figured I may as well let everyone else know, in case they want to use it.

This is a good idea, and I should point out that a while ago I did a "plugin-loading plugin". This simply scanned a directory and loaded every plugin it could find (in fact, which is what WoW does when you add a plugin to the Addons directory).

This means installing a plugin simply requires putting it there (in the directory). You don't have to go into the program and "install" it like you do in MUSHclient.

Your proposed structure is more complex, but ultimately a lot more flexible. The directory scanning plugin could be changed to locate directories (one for each plugin) rather than simply .xml files.

The other thing that MUSHclient does not totally address now is the issue of dependent plugins (of course, the PPI stuff is heading in that direction).

As a follow-up on this recommendation, I propose two additional standard subfolders: scripts/ and libraries/. For example:



The scripts/ folder, while unused in the example, is simply a standard location to put the broken-up parts of the plugin, so the top-level directory contains only plugin.xml. The libraries/ folder is somewhat more important, as it provides a standard location to place third-party libraries that your script uses, such as the PPI module.


I am also considering authoring a small 'structured plugin' base library to include in the libraries/ folder, to abstract out the issues of dealing with dofile() rather than require() to load scripts and libraries. It would likely be an XML-wrapped file, so you could <include> it within your plugin.xml. I think it would be rather useful, personally. What are your thoughts?