Wordpress Style Modules: Analysis
The Idea
There is a current idea that we might be able to take a hint from Wordpress for how to handle the front end modules hooks. Further there is an idea that this might be extended to handle the backend as well. Though this would make a lot of our module API developing for not, it has the potential to be easier to use in the end for developers. This system also has the promise for making code that executes modules more efficient than it is in its current scheme.
The System
Wordpress implements essentially 4 global functions that are used in order to make modules execution happen. They are the following: add_action(), do_action(), add_filter(), apply_filter(). Before these will make sense to us, however, we should define what an action and a filter are. An action is added functionality. This functionality could range to anything beyond the original scope of the application. A filter is modifying text you see on the screen. This would be like swapping out the username for a user's full name.
add_action()
This function registers a function name to a specific action type. An example would be add_action('build_backend','build_dhcp'). This would register the function build_dhcp to the build_backend actionset. This function call would take place in the module.
do_action()
This function performs the actions for the specified group. For example: do_action('build_backend'). This would perform all actions registered to build_backend. Using our previous example, this would call a function called build_dhcp, because it was registered to that action.Blah
add_filter()
This function is almost identical to add_action(), the only difference is it adds a filter instead of an action.
apply_filter()
This is virtually exactly the same as do_action(), except you're executing a filter instead.
As can be seen from above the module writer is specifying their function name and registering it to the actions it needs to be registered to. This means that we don't need to have an extensive module class for every occasion, they can call their functions whatever they like, and as long as they add it correctly, it doesn't matter.
Dealing With Multiple Modules
The catch is always how do we have multiple modules work together, especially in the same area of an application. This creates several key points of concern. Priority of filters and modules (who goes first), function name collisions and how we handle it, and how extensible the system is down the road.
Priority of Filters and Modules
Priority in Wordpress is an optional arguement to the add_* functions. With a default value being assigned if it isn't specified on addition. Those with higher priority numbers trump those that don't (They will be the behavior that you see, in terms of filters). This can easily be extended into Maintain by offering the things we want to overwrite with the lowest priority, thus modules would overwrite them. However, in terms of actions, our "core" functionality (things we don't want to be disableable and such, or things we want to happen first) should be of the highest priority, and thus aren't overrided. An example would be our Navigation Menu. We want OUR nav bar to happen first, so its consistently in the same place, so it would have the highest priority so it's done first.
Function Name Collisions
This is perhaps the trickiest part. The way that Wordpress handles this is to have people check for themselves to see if their function is already defined somewhere else. This is fine and dandy, but can't be guaranteed. Another way would be to qualify it by the module name. This sounds like a more effective means of enforcement.
Extensibility
The system sounds very easy to expand. For example, if you want people to be able to apply filters elsewhere in the system, you just need to add a name for that area, then call apply_filter() at that point. Suddenly, any module can modify the behavior there. The same is very true with actions. The system truly looks to be simple, yet amazingly powerful.
