Preliminary Warning:
"
If you're afraid of classes and objects in PHP, run away now." - jpetso.
Update: For simplicity the API has been changed so that all faces are incorporated, thus modules have to care about naming collisions theirself. Also in the meantime file inclusions support has been added.
While figuring out a object oriented design for the
rules engine I recognized the need for a possibility to allow modules extend objects in various places. Thus I developed a generic concept which does just that: Allowing modules to extend objects. I called the concept "Extendable Object Faces", which basically implements the Facade pattern in a modular way.
So let's have a closer look at that. A module that wants to extend an object may only do so on top of a defined interface, preventing uncontrolled growing objects. Thus one can write some code, define an interface for it and attach it to potential any extendable object out there. Then other modules have an easy way to test whether some object has a functionality in place by checking for the availability of a certain interface.
To use that functionality the caller has to use the right "Face" of the object - corresponding to a certain interface. This approach using different "Object Faces" make sure there can't be conflicting method names, so modules don't need to prefix their methods with the module's name which would result in ugly and not readable code.
I've already implemented an initial version of the
Extendable Object Faces API. As of now you can:
- Extend an object by providing an Extender Class
- Extend an object simply by some functions, each implementing a method
-
- Override any dynamically added method by providing functions or an Extender Class
So apart from "allowing modules to extend an object", this also allows one to:
- Easily lazy load huge parts of an objects implementation, invisible for the caller.
- Allow modules to dynamically alter an implementation by using overriding.
Hence such an Extended Object can also serve as a clean abstraction for module provided callbacks!
Enough talk, let's show how it works:
<?php
interface FacesTestInterface {
function isWorking($prefix);
}
/**
* Extendable Class
*/
class FacesTestElement extends FacesExtendable {
//Your code here..
}
?
?>
This code provides the class for the Extendable Object and already defines an interface, which modules may implement. So let's extend it with an Extender Class.
<?php
/**
* Extender Class
*/
class FacesTestExtender extends FacesExtender implements FacesTestInterface {
function isWorking($prefix) {
return $prefix . $this-
?>
object->name;
}
}
?>
That's it. Now you can use the face!
<?php
$element = new FacesTestElement();
$element-
?>
name = 'test';
$element->extendByClass(array('FacesTestInterface'), 'FacesTestExtender');
// Now use it.
print $element->face('FacesTestInterface')->isWorking('Name:');
// This prints "Name:test".
?>
As you see, one has to use the face to be able to use the added method - so potential name collisions are avoided. However the Extendable Class can define so called incorporated faces, which are built in the Extendable Object as soon as a module provides an implementation:
<?php
/**
* New extendable Class
*/
class FacesTestElement extends FacesExtendable {
public function getIncorporatedFaces() {
return array('FacesTestInterface');
}
}
?
?>
So you can use it that way, once extended:
<?php
print $element-
?>
isWorking('Name:');
?>
You can find more examples in the
simpletests I've written. Also checkout the benchmarks I've run.
So what's missing? Basically the implementation is complete and working fine. Though feedback and suggestions are very welcome! However currently the code doesn't deal with including code where the implementation can reside (lazy loading), though for drupal 7 that is already solved by the code registry (just add one call to drupal_function_exists()). For drupal 6 I think about adding the possibility to specify include files per added interface.
Dreaming...
If we would have an object oriented "Data API" in drupal core, this could serve as a way to let modules extend those objects. So instead of writing node-centric code code could would be written in a generic way - attachable to potentially each of those data objects (users, comments, terms). Having such generic code would allow us to finally end the "Everything should be a node" debate. Apart from that this would help us to easily lazy load big chunks of code, just exploiting the code registry!
It's finally grown-up?
Rules is already stable for quite a time, however I didn't consider it to be complete. During the last months I added missing important features, fixed bugs and translation issues and completed the documentation! While there was quite a bunch of useful developer documentation for a while, now there is also a complete hook reference in the doxygen format.
So it's grown up, but it's not (yet) perfect. So what comes next?