2

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

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?

0

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.

1
  • See new edit...thanks for the link, but that's basically just implementing a convenience class for simply instanciating the other classes within your class.
    – wyrfel
    Commented Feb 25, 2011 at 3:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.