On 26 Aug 2012, at 19:42, Mark <mark...@gmail.com> wrote:

> Envision the following plugin architecture:
> class PluginLoader
> {
> }
> interface PluginInterface
> {
> .. some function definitions ..
> }
> class PluginOne implements PluginInterface
> {
> }
> class PluginTwo implements PluginInterface
> {
> }
> The PluginLoader is loading the plugins.
> The PluginInterface defines an interface which each plugin has to implement.
> PluginOne and PluginTwo are plugins that implement the interface.
> Each plugin (PluginOne and PluginTwo) are stored in their own folders.
> So the folder structure would be somewhat like this:
> |- Plugins
> |- - PluginOne
> |- - - PluginOne.php
> |- - - other possible files
> |- - PluginTwo
> |- - - PluginTwo.php
> |- - - other possible files
> |- PluginLoader.php
> |- PluginInterface.php
> Now making this structure isn't an issue. I can do all of that just
> fine. The place where i'm actually going to make a plugin instance is
> where things get a little more complicated. The PluginLoader simply
> reads all the dirs in the Plugins folder and tries to find a filename
> with the same dir. So if it reads the dir Plugins/PluginOne it will
> try to include the PHP file: Plugins/PluginOne/PluginOne.php. That's
> fine and working.
> To actually make a plugin instance i can do two things that i know of:
> 1. use eval like so: eval('$obj = new '.$pluginName.'();'); and
> register it to the PluginLoader.

No need to use eval, you can simply do this:

$obj = new $pluginName();

See here: http://php.net/language.variables.variable

> 2. Let the plugin itself (so in this case PluginOne.php) open itself
> and register it to the PluginLoader.
> With the first option i have to do eval which i try to avoid if possible.
> With the second solution the PluginLoader probably has to be a singlethon.

Why does it need to be a singleton?

> Now my question is: what is the right way of loading plugins like
> this? Is there some other option then the two i described above? My
> PHP limitations are the newest version so no limitation there :)
> I'm kinda leaning towards the second option now since that seems to be
> quite stable and not very error prone. The eval one is much easier to
> break :p

If you're happy for each plugin to be in a separate directory then what you 
have in option 1, minus the eval, will work perfectly well. I don't know what 
your use case is but if there's a chance a single plugin might want to provide 
several classes then I'd require an init.php in each plugin folder and have 
that register the class names with the class loader. It could also then pass 
along some meta information such as a description of what each class does. If 
this is for use in web requests you might want to stick to what you currently 
have as there's a lot less overhead.


Stuart Dallas
3ft9 Ltd

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to