Following on from the post where I vaguely mentioned building a framework, I thought I would get started on two crucial elements of it today, namely hooks and modules. I’ll talk about how they will work in a moment but first I wanted to explain the state of the code as I begin this part of the project.
As I have said, I’ve building a site in order to build the framework. The site is a gallery, similar, at least in structure, to http://cssimport.com or http://bestwebgallery.com and will make use of external services to generate parts of its content. There is currently a URL router, views, templates, basic authentication and very, very basic database connection handling. The core pulls these elements together procedurally depending on what is required to serve the request. This all consists of very little code at the moment. It is embryonic, very basic and very fast. I’m hoping to use this simple base as a benchmark and to try to avoid straying too far from it’s simplicity to avoid adding unnecessary overhead to a request. But, getting back to the point, the next step is hooks and modules.
And they are…?
Starting with modules, as they are a more widely understood concept, a module is an add-on, a plug-in, an extension. It adds functionality to the system. For example, the User module (as it will be—this code was initially written into the core for ease) provides the framework with authentication, registration, group permissions, profiles and so on. A module which is not required is flagged as inactive, its code is not imported and it has no bearing on request overhead.
Hooking is “a technique used to alter or augment the behavior of an operating system or application”. In the framework, hooks will be used to allow modules control over certain core functionality. For example, one hook will allow a module to add to the URL routing table, another may be used to override output to one template, switching it to another if certain conditions are met. There will be types of hook affecting whether they are run before, during or after the request.
The list of modules, which ones are active, and which ones contain what hooks is all data which will be cached as this processing would add a substantial expense to each request. The cache will only be refreshed when a module is activated or deactivated, or when a manual refresh is called.
Prior art
As ever, none of this is new. All the best frameworks and some CMS’s will offer this or similar functionality. Drupal, for example, use the same terminology of “modules” and “hooks”, indeed I’m taking some cues from that implementation.
I’m looking forward to seeing what I can do with this. I remember my first experiments in building a completely modular CMS way back in about 2003. That was a little more extreme in its modularity and more of a purely academic exercise than a practical reality. There was no core functionality at all, only the absolute minimum required to discover and load other modules in the correct order. From there you would add the building blocks of the system in completely plug and play fashion. Back then I paid little attention to other work going on around me, or to existing systems—I just enjoyed coding this stuff up. working in my spare time, and alone, I wasn’t aware of the standard of existing systems out there. But I always assumed that people must have already done way more, way better than I was capable of so I never really shared it or showed it, or backed it up, sadly. Makes me wonder, knowing the state of the solutions available today what I might be doing now if some of those early high-minded experiments which are long since lost had become something more, and if my enthusiasm or optimism hadn’t been severely damaged by my previous over-working employment. But, musing and self-importance aside, this should be interesting.