Plug-in Manager

This class is based on the observer pattern, see more about this on the observer pattern page on Wikipedia. It is used to run plug-ins inside Proteus.

How does it works

The core will create an object from the class called pluginManager and it will load the plug-ins from a table stored on the default database. During the core code execution, every attached plu-in will be notified of an hook, there are four of them and they can be called only by the core. the next section will explain them in particular.

Hooks

Right now they are only four of them and it is my objective to keep them as few as possible. Here is the list of the hooks and how and when they are called and for what kind of use they are created:

FIRST_HOOK

This hook is notified immediately, at this early stage you can write plug-ins that can change any parameter of PROTEUS and its class. The GZ Compressor plug-in use this hook to start catching every output, for example.

FEATURES_LOADED_HOOK

At this time, every class that the module requires is loaded, so it is possible to manipulate them at this time and every changes here will have an effect to the module execution.

CONTENTS_HOOK

When this hook will be notified, you will have access to the title, description, and contents of the module loaded. This is the only moment when this condition is possible, writing a plug-in that will try access to this feature later or before this hook will have no effects. This is a general rule. The NBBC plug-in make use of this hook to parse the contents and translate the BBCode inside it.

LAST_HOOK

This is the last hook that will be notified, as the name says, and here you have the access to the final output of the web page before it is sent to the client. Possible scenarios here are: Create a PDF version of the page, beutify the source code of the page (Dindent plug-in) or, like GZ Compressor does, compressing the output data.