Quantcast
Channel: Recent posts across whole site
Viewing all articles
Browse latest Browse all 49199

OOP Hooks / plugin objects

$
0
0

In one of my projects (crumbs) I am playing with a new (ctools has something similar afaik, but still somewhat different) mechanism for hooks, that is based on classes and plugin objects. Plugin objects give us some local state that lasts longer than one hook invocation, but not as long as a static function variable. And aside of that, they give us a namespace for method names.

Plugin objects are created either based on their class name (scan for $module . '_class_' . $pluginName), or by some factory function (in case of crumbs this is a static class method, but could also be a classical Drupal function hook). They can be dropped and created new, each time we want to flush their local state. Or we just give them a reset() method.

Now I wonder if we should do something similar for Drupal bootstrap and page building.
We could let each module define one or more plugin objects for each of the scope/lifetime context components, with the respective context component(s) as a constructor argument, and with methods for hooks that somewhat belong to this context component.

<?php
class mymodule_plugin_World {
  function
__construct($world) {..}
 
// hook_boot
 
function boot() {..}
  function
nodeapi($node, $user, $op) {
   
// $user wants to do $op on $node.
    // $op can be "save", "update", etc. "view" would be done by some another plugin that knows about $theme.
   
...
  }
}
?>

And maybe the world plugin could be used as a factory for other plugins?

I know we said goodbye to "every module is a class", and this was very wise.
But this idea is somewhat different.
And at this moment it's pure brainstorming.


Viewing all articles
Browse latest Browse all 49199

Trending Articles