So WP 3.1 introduces the fancy WP_List_Class() causing me to rewrite all my custom admin tables. Fair enough. But…in the good’ol days, i was able to call my plugin methods using $this->method()
as i included the page file within the method that got hooked to via add_submenu_page()
. That was nice and somewhat elegant – or at least nice – i thought.
Now, though, my code has to live within the methods of My_WP_List_Class, which inherits from WP_List_Class. Since i can’t do multiple inheritance, i seem to have to reference my global plugin instance or reinstanciate it within my class, either one of which makes me a little upset.
Class stacking doesn’t seem to be an option either, because obviously i can’t make WP_List_Class inherit from my plugin class, nor do i want to make my plugin class inherit from WP_List_Class.
Am i overlooking something or do i just have to live with it?
Edit: more context:
I might be thinking too complicated, but my scenario is this: I’m having a ‘meta’ plugin class that is instanciated by other plugins (several times). So i don’t even know what it’s instanciated as and frankly, i don’t want to know. 😉
Each of these instances hooks itself into the admin menu and creates a custom menu page. Each of these instances also get’s some parameters passed (like an id-like one for instance) that it stores internally upon instanciation. If i call a method, the method depends on these internally stored values.
So far, each of these instances could all live self-contained, i didn’t need to register them in any array or anything, you could even instanciate them anonymously, if you wanted.
Now i need to add methods to my WP_List_Class inheriting class that will depend on those values as well. So the only thing i can imagine is to do something like this:
function table_me_some() {
$table = new My_WP_List_Class(&$this);
...
}
and then within My_WP_List_Class
do something like this:
function __construct($mama) {
$this->_mama = $mama;
}
function whatever() {
$this->_mama->my_plugin_class_instance_method();
}
Then my_plugin_class_instance_method()
lives in my instanciated plugin class and references it’s own internal variable store.
However, i only came up with this now, but i still don’t find it very neat.
This is a common design pattern, and I would have solved it in the same way you did. Let
My_WP_List_Class
extendWP_List_Class
, and pass a “configuration” object to it. You could even make the relation more explicit by defining an interface your configuration object must adhere to:I don’t see much difference with the current way of using actions to hook your functionality into. Yes, your code is now structured in a class instead of in a list of functions, but that is the only difference, no?
Take 2:
My first answer was … not right.
Basically, PHP does not support multiple inheritance. However, there is something that may get you “close enough.” I found some references to symfony using mixin classes, something I’ve used successfully in other languages.
Grab the 1.4.9 release (current stable) and do
grep -i mixin -r .
I found a number of references to it. E.g.
lib/plugins/sfPropelPlugin/lib/addon/sfMixer.class.php
. The docs are a bit thin in this area, but it may be what you need.