Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I'm coding a very complex plugin which it's organized as a parent "container" class and several subclasses, where each subclass is an optional/mandatory element which usually (but not always) maps to his own add_submenu_page.

Basically, it's a plugin with his private set of let's call them "subplugins".

Every subclass/subplugin has its own (big) set of add_action and add_filter. So, technically speaking, my plugin's subplugin is a valid WP plugin, simply it's not called directly by WP itself.

Since i planned...actually tons of add_action...I'm wondering if i should refactor my plugin using a 'private' Observer/Mediator pattern ie. collect all relevant add_actions to my parent class only and baking up a pattern to notify/forward subclasses of events, reducing the impact of my plugin to WP event ques.

Is it a good idea or it's absolutely not necesssary? Can u help me with some code for the class refactoring?

tnx in advance for help, gabriele

share|improve this question
    
i was likewise thinking about the best patterns to use here, you can check plugins.svn.wordpress.org/wp-favicons/trunk for my current pre-refactoring code (im a hobby coder) so under /includes some kind of abstract plugin class and then each /plugin has its own 'admin page' and inherits from 'plugin' which has some default methods to call. Maybe more in general: i also would need some more patterns for creating WP plugins since i made a lot of design decisions which are probably not perfect or maybe even totally not ok. –  edelwater Apr 16 '11 at 10:14

3 Answers 3

up vote 2 down vote accepted

I'm wondering if i should refactor my plugin using a 'private' Observer/Mediator pattern ie. collect all relevant add_actions to my parent class only and baking up a pattern to notify/forward subclasses of events, reducing the impact of my plugin to WP event ques.

The event queue is fundamental to WP, so it's pretty fast and getting faster all the time.

So, I don't think it makes any sense, performance wise, to make your own sub-queues.

Refactoring your code so that you don't have to make each add_action() call manually is a different matter.

share|improve this answer
    
that's exactly what i need to know! tnx a lot! –  Gabriele B Apr 17 '11 at 16:13

So ... I basically took the same approach, dont know if it is correct. I think many people come to this approach since it flows naturally forth out of using the settings api.

  • I define modules (=1 admin page, so header, etc...) and each module has plugins (plugins have fields, are 1 object derived from abstract plugin class.

here: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-load-configuration.php

I thinks this automatically is done by most because e.g. a module: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-module.php corresponds to what we need to do for the settings api

  • the init loads the modules and plugins (which each have their own filters actions or attach to filter or actions) {and 3rd party can add plugins to modules}

here: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-init.php

(where the plugins check if they should be activated if they are turned on on the corresponding admin page) (and can be represented as abstract: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-plugin.php)

So from the other side "the backend site" I defined just my own filters where each of the plugins can attach themselves to e.g. http://plugins.svn.wordpress.org/wp-favicons/trunk/plugins/metadata_favicon/inc/class-favicon-factory.php defines filters such as "Config::GetPluginSlug() . 'search'"

So in general... I think the settings API drives us to this approach naturally.

So... then some come to the point (your question) in which you would think to re-factor your own add-actions to 'something else' which could be observer/mediator patterns or anything else.

But... since we followed the WordPress approach using the settings API (the whole thing above), by using this making it easy for 3rd party's to "hook in to" actions, write their own help page extensions etc... I would stick here also with add_action just because "the rest" of the design also follows this and it make it probably easier to comprehend the whole code.

share|improve this answer
    
+1 A pretty complex, but also pretty smart approach. I wouldn't say that this is the most "natural" approach, but it's really a kool idea. One thing where you're absolutely right is that everybody starts automating the settings API stuff after the 2nd or 3rd she/he used it. –  kaiser Apr 16 '11 at 13:41
    
it seems quite verbose, but definitively a good architecture! I'm dig a bit on it, trying to understand better the whole subject –  Gabriele B Apr 17 '11 at 10:35
    
@kaiser it would be interesting to see what approaches people take in automating the settings API and maybe see if there is 1 uber correct perfect way in doing so. –  edelwater Apr 21 '11 at 0:05
1  
@edelwater - i'd say, you could do a pretty encapsulated core class and then add nearly every way to add the data: parsing ini/xml/json/yaml/etc., making general functions to call the core class, then sub-functions that add predefines for the general functions and then a set of specific functions that solve common tasks with a three_word_string();... i call this über-perfekt, but bloat & overload in the same sentence... –  kaiser Apr 21 '11 at 12:55
1  
@kaiser thanks for THINK-ing about this. I have left this open to think about it. The nice thing about GPL is that you learn stuff, that makes it fun. –  edelwater Apr 21 '11 at 21:32

Another nice example for distributing a plugin with sub-plugins is this one.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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