Plugin Template/Framework

[Angryboy]

I do like that the assets are prepackaged, and lang.
although the only htaccess you need is allow for assets folders. js, css etc.

But the organization of the oop seems odd to me.

I think to benefit from this, the entire plugin needs to be class based so no globals are necessary.
And you do not need to replace yourplugin_id all over the place or use a namespace.

$uniqueID = new plugin($uniqueID);
add some stuff here version author
$uniqueid->author =
The only hook into the class could be something like register_plugin(){global uniqueID;$uniqueID->register);

I guess you would still have the same problem though with globals but you could prevent collisions with variable variables and variable function names. But you would need to handle callbacks from filters and hooks with normal functions or you might lose a argument in the process if you can only pass an action.

But another issue is that gs requirements are still 5.2.3, so alot of oop stuff might not be useable until 5.3

Yeah, the OOP design pattern I've used is pretty slap-dash I'll admit. xD

So with your example, are you saying that I should wrap up the plugin registration itself into an object, or is there already a plugin object in GS for doing this?

Also, if the OOP functions might not work until 5.3, how has SimpleXMLExtended been working for the core? If there is legacy code to ensure that it works, I would be grateful to know so that I can make my code backwards-compatible too.

hmm has anyone tested hooks and filters with namespaces or classes?

They definitely work with classes (both instances and singletons). Haven't tried with namespaces yet though.

Instances:

PHP Code:

$obj = new yourobject($param1, $param2, ...);
add_action( 'hook_name', array($obj, 'method_to_call'), array($args) ); 


Singleton (static methods):

PHP Code:

add_action( 'hook_name', 'yourobject::method_to_call', array($args) ); 


Unless you mean registering hooks when in the class itself...?