The Plugin Manager
At this stage, Charlie had the outline of a business-object Entity System and the outline of a runtime Web System. I felt that if Charlie was to have a flexible architecture based on the concept of Plugins, it would be a good idea to get those plugins working. But there were two decisions to be made about how the Plugin System would work.
First, was it possible to come up with some sort of convention that ensured all the Plugins would have the same overall design, even if they did completely different things? For example, the Security Plugin would concern itself with plumbing matters such as roles and users, with very few interface aspects. On the other hand, an Articles Plugin would concern itself with interface elements for creating, editing, and presenting online articles, with no plumbing involved. This was a problem that I had considered way back in my first attempt at an architecture, where I initially guessed that I would use Modules to represent interface-oriented plugins, and Components to repesent plumbing-oriented plugins. Even way back then I had dismissed this as being an arbitrary distinction between different types of plugins, and that I should be able to come up with some sort of convention that ensured all Plugins had the same overall design. But, what would that convention be?
The second decision concerned the practical matter of actually getting those plugins to, well, plug in to the base Charlie framework.
Instinctively, I felt that I should address the first decision first (what the plugins would look like) before I worried about the second decision (how the plugins would come into play). While that definitely seemed the right approach, I could not make that first decision. Sensing that I was approaching a mental block, I decided to do it back-to-front. I hoped that as I worked with the practical matter of getting plugins into play, ideas might form about a convention that ensured all plugins had the same overall design.
Because I had earlier resolved to use an EntityManager to load up and then control access to the base Entity and EntityCollection objects (rather than allowing direct access to entities and collections), it seemed a good idea to create a PluginManager to load up and then control access to the plugins. So I added a PluginManager to my architectural diagram.
Having updated the diagram and pinpointed the next challenge, I set about finding a way for the plugins to be brought into play. This proved a lot harder than I had expected.
by Alister Jones | Next up: The Trouble with Modules →
----
Post a Comment