Arelle/Arelle — pull request #16 by regisd (2011-12-24 13:07:47+00:00)
Title: Plugin framework

Plugins are components that add features to a hosting application. I think it would be useful for Arelle to support plugins:

* it helps to maintain the code loosely coupled and modularized
* it avoids dealing with branches and merging if my specific features are needed in a company
* it encourages third-party development, by allowing to use other pieces of code, even if they have not been merged in Arelle/Arelle

I made a brief review of existing plugin framework for python (see also http://wehart.blogspot.com/2009/01/python-plugin-frameworks.html)

* yasy looks good. It was written in python. Despite, porting a couple of obvious points, I could not make it work, though.
* trac/zope have plugins, but there is no plugin framework per se. Their solution is quite specific to these applications and are quite heavy.
* plugnplay is extremely simple (I mean, it is just 10 lines of code)
* Martin Alchin's Simple plugin framework is also very simple

So I decided to start from Marty Alchin's proposal, adapt is slightly for python 3, and implement that in Arelle.

Arelle now has apf.py for "Arelle plugin framework". This introduces a metaclass "MountPoint".

Arelle should define mount points where plugin can act. At the moment, I have defined 2 mount points for you:

* GUIMenu for plugins that want to add a menu entry
* CommandLineOption for plugins that want to add a new command-line option/argument

A plugin inherits one of this classes (probably both) to be called by Arelle when necessary.

The impact on Arelle code base is very minimal:

* Cntrl loads all plugins found in "plugins" directory
* CtrlWinMain creates menu-items in "Tools" for each plugin that has mount point GUIMenu
* CtrCmdLine adds options to the cli parser for each plugin that has mount point CommandLineOption

Right now, I think this is enough, even though more mount points can be added in the future.

On the other hand, plugin developers need to read the documentation on what they should provide if they write a GUIMenu. In the spirit of "duck typing", there is no interface to which a plugin should conform.

In order to demonstrate, that writing a plugin is simple, I have published HelloDolly plugin.

For your information, I have also successfully "plugified" the "save DTS" feature I contributed last time. (I realize some code has been lost, like support for nested files ; I'll fix that before)

Future developments include:

* more mount points, like a Validation mount point for plugins that validate a XBRL DTS, within the current validation method
* a plugin directory in user directory (like Application Data on windows)
* a mechanism to activate/deactivate plugins

I hope you will like this idea, and I'm sure you will. Feel free to provide feedback in the comments :)