Plugin Framework Base Model

[UnKnOwned]

Introduction

Plug-in frameworks have basic principles to follow and can support whatever the developer wants it to. There are many options for various languages when it comes to plug-in frameworks but not so much in terms of Autoit. The subject matter here though is not to define what a plug-in framework is suppose to be or what it should support (for a brief overview you can go here) http://en.wikipedia.org/wiki/Plug-in_(computing)

Objective

1) Create a minimal non application specific plug-in framework base structure that will support non-compiled .au3 scripts in the form of extended functionality features or plug-ins for AU3 compiled.exe executable's.

Model

 

Model Overview

The above model demonstrates a chain style plugin whereas all functionality is initiated and received from a global point being the Host Application. Theoretically two directional functionality can take place between both Host Application & plug-ins in the above model reproducing two-way plugin structural behavior.

To make this as functional as possible we take out everything in the Host Application, and all we leave behind is a generic skeleton for the framework as well as any application specific instructions for handling incoming plug-ins. The plug-ins ultimately become the functioning parts of the application and/or the application directions for the framework. The Host application becomes a zombie for handling whatever the hell we tell it to handle.

All application feature functionality resides in the plug-ins. The Empty Compiled AU3 file is you guessed it, a module a piece of reusable software the middle man for handling parameters that will in turn invoke the plugin same as you would if you brought the Autoit interpreter with you. The plug-ins can then send parameters back to the main application telling it how to respond. During the 2nd initialization of the Host Application via the initialized plug-in we will check for parameters passed.

In the end what you have is a very well mannered base component for you application specific framework. One that waits in turn while having a conversation with the other components, only speaks when spoken to, and finishes what it starts in the form of start with one process end with one process.

Components

1) Host Application (YourApplication.exe)

2) Empty Compiled Au3 file (pluginloader.exe) - self explanatory

3) Plug-in (plugin.au3)

Research Resources

https://code.google.com/p/jin-plugin/

http://www.drdobbs.com/cpp/building-your-own-plugin-framework-part/204202899

http://www.eclipse.org/articles/Article-Plug-in-architecture/images/listeners_extensions.jpg

http://www.cs.tut.fi/~mda/documentation/eclipse/MadeArchitecture.gif

http://www.programcreek.com/wp-content/uploads/2011/09/EclipsePluginArchitecture2.jpg

Edited May 30, 2013 by UnKnOwned