Any way to inherit methods from both my plugin class and WP_List_Class?

by

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.

2 Answers
2

This is a common design pattern, and I would have solved it in the same way you did. Let My_WP_List_Class extend WP_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:

interface My_WP_List_Configuration
{
    public function get_name();
    public function get_admin_page_uri();
    // ...
}

class WPSE10402_Plugin extends Wyrfel_Plugin implements My_WP_List_Configuration
{
    public function get_name()
    {
        return $this->_name;
    }

    public function get_admin_page_uri()
    {
         // ...
    }
}

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?

Leave a Comment