One of the other defining characteristics of RedFeather is the fact that the core implementation comprises of a single PHP file. \u00a0Despite this, it still provides a highly extensible architecture capable of being customised and tweaked to suit different situations. \u00a0Plugins can be written to add new fields to the workflow, introduce new pages and functionality, or change the site’s appearance. \u00a0While the concept is nothing new, writing such an architecture while still maintaining the desired simplicity of RedFeather presents a distinct challenge. \u00a0By looking at existing implementations of plugin environments it is easy to appreciate the potential complexity of such a system and identify ways to simplify.<\/p>\n
The first architectural style I analysed was the ‘hook system’ of plugin management, as used in both WordPress and MediaWiki. \u00a0In these programs, each plugin is associated with a special point within the code, known as a ‘hook’. \u00a0Each hook corresponds to a different point in either the execution of the code (for adding additional processing), or a point in the rendering a page (for adding content). \u00a0The advantage of this system is that is allows for the greatest possible flexibility while still maintaining complete control over how and where the program can be extended.<\/p>\n
As you might expect, the code overhead associated with this system is considerable and would turn RedFeather into an unreadable mess of complexity. \u00a0Framework code would need to be written to support the processing of plugins in general, then additional code to handle each category of hook. Furthermore, every page and feature in the system needs to be written in a specific way to support the plugin environment.<\/p>\n
The EPrints platform utilises an entirely different system which relies largely on\u00a0inheritance. \u00a0Writing a new feature is done by creating a subclass of an existing one and adjusting the functionality as required. \u00a0Plugins are loaded automatically on server startup and configured using additional scripts within the cfg.d directory. \u00a0The main advantage of this system is that it is possible to entirely rewrite or extend any part of the platform, although a larger understanding of the core EPrints code.<\/p>\n
In the interest of keeping these blog posts readable I shall continue this topic in my next post.<\/p>\n","protected":false},"excerpt":{"rendered":"
One of the other defining characteristics of RedFeather is the fact that the core implementation comprises of a single PHP file. \u00a0Despite this, it still provides a highly extensible architecture capable of being customised and tweaked to suit different situations. …<\/p>\n