On Mon, Aug 27, 2012 at 12:41 PM, Stuart Dallas <stu...@3ft9.com> wrote:
> 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.variableAhh right, i completely forgot about that option. That might just work the way i want it :) > >> 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? Well, i would then do something like this from within the included plugin file after the class: PluginLoader::getInstance()->registerPlugin(new PluginOne()); Or something alike. > >> 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. Yeah, if i extend it more that will certainly be an requirement. > > -Stuart > > -- > Stuart Dallas > 3ft9 Ltd > http://3ft9.com/ Thank you for your advice, really appreciated. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
