PHP的插件架构 [英] A php plugin architecture

问题描述

我试图想办法来创建自己的框架的插件体系结构。我读过无数的话题和文章在这里和在其他网站上。基本上我已经来到了以下解决方案，这似乎是在PHP（目前）。

I'm trying to think of a way to create a plugin architecture for my own framework. I've read numerous topics and post here and on other sites. And basically i've came to the following solution which seems to be the only good option in PHP (currently).

我们的想法是，每一个类继承有点像类观察员。因此，一个模板类，BaseController等方面始终扩展插件类。

The idea is that every class extends a sort of observer like class. So a Template class, BaseController etc. always extend a Plugin class.

class BaseController extends Plugin
{
    public function __construct()
    {
        // Plugin check, notify all loaded plugins
        $this->checkForEarlyHooks();

        // Init some standard stuff
        $this->view = new Template();
        $this->baseLayout = 'layout.html';

        $this->something = new Something();

        // Plugin check, notify all loaded plugins
        $this->checkForLateHooks();
    }
}

那么，基本上happends这里是当indexController的延伸baseController插件检查完成。在这种情况下的构造。这可以方便的，当你想要做一个某种登录检查了插件，实际上是调用的操作方法之前。

So what basically happends here is that when an indexController extends a baseController a plugin check is done. In this case for the constructor. This can be convenient when you want to do a some sort of login check with a plugin, before an Action method is actually invoked.

插件类可以从被得到了叫什么类，并知道在加载插件要寻找什么功能解决。

The Plugin class can resolve from what class is got called from and knows for what functions to look for in the loaded plugins.

另外请注意，它检查装载的插件列表2次。任何一个之前被加载（早期）在构造函数中，一个当所有瓦尔加载（晚期）。

Also note that it checks the loaded plugin list 2 times. One before anything is loaded (early) in the constructor, and one when all vars are loaded (late).

我也可以变量添加到checkForLateHooks（）函数。所以钩子函数可以操纵那些太像了的baselayout'变量。

I can also add variables to the "checkForLateHooks()" function. So the hook functions can manipulate those too, like the 'baseLayout' variable.

一个钩子函数是这样的：

A hook function would look like this:

public function hookConstruct ( &$baseLayout )
{
    $baseLayout = 'login.html';
}

现在基本上是我的问题是，这种方法有什么好处？我知道有很多可能的其他方式来做到这一点。但我主要是不想以后碰到设计问题。现在似乎是一个好主意，但你永远不知道如何工作了以后......

Now basically my question is, is this approach any good? I know there are probably alot of other ways to do it too. But i mainly don't want to run into design problems later on. It seems like a good idea now, but you never know how things work out later on...

如果我记得正确（从我读过的所有文章），这是有点像Word preSS做它（和一些其他框架）。

If i remember it right (from all the posts the i've read), this is kinda like WordPress does it (and some other frameworks).

推荐答案

当然，还有许多不同的方法来设计一个插件系统，或许要求在 HTTP ：//programmers.stackexchange.com/ 会给你更多的想法，但我会努力通过分享我的想法和经验，帮助

There are certainly many different ways to design a plugin system and perhaps asking on http://programmers.stackexchange.com/ would give you more ideas, but I'll try to help by sharing my ideas and experience.

我的自己的框架已经大幅增长，已通过许多开发人员和公司。然而，可扩展性和创建和分发能力的插件是4.2版本一大要求。我已决定根据从Ruby on Rails的还有许多内部概念的一些想法，以改善显著。有关加载项的一般信息是在这里： http://new2.agiletoolkit.org/develop/addons

My "own" framework have grown considerably and have been adopted by many developers and companies. However the extensibility and ability to create and distribute plugins was a big request for the 4.2 version. I have decided to significantly improve based on some ideas from Ruby on Rails as well as many internal concepts. The general information about the add-ons is here: http://new2.agiletoolkit.org/develop/addons

一般情况下，插件仅仅是一个类的集合。它们不能与其他插件或核心类冲突，因此他们居住在一个单独的命名空间。开发咨询插件的文件，并决定如何将其纳入。附加组件不会自动初始化：

Generally, addon is just a collection of classes. They must not conflict with other addons or the core classes, therefore they reside in a separate namespace. Developer consults documentation of a plug-in and decides how to include it. Add-ons do not automatically initialize:

$api->add('myaddon/MyClass');

正如你所提到的，那么它的下跌到挂钩。初始code寄存器其他物体内可调用。在API是交流一些钩子的好地方，但它也可以放置其他物体内挂钩，如表单，认证类等。

As you have mentioned, then it's down to hooks. The initial code registers callables inside other objects. The "API" is a good place to exchange some hooks, however it's also possible to place hooks inside other objects, such as forms, authentication class, etc.

挂钩被称为是这样的：

function myHook($caller,$arg1,$arg2){
}

鱼钩可能返回结果，或者甚至称之为breakHook，这引起了异常，捕获它的挂钩（）函数中，因此$ P $被执行pventing等挂钩。

Hooks may return result or even call breakHook, which raises exception, catches it inside the hook() function and thus preventing other hooks from being executed.

的钩子用于方法注入，基本上映射__call（）由外部控制器注册的钩。这不是一个很好的开发实践，但可以通过附加的设计使事情更容易开发。还有一种是由所有对象调用时它们被初始化钩，以及一个可以被用来截取任何甚至替换对象与另一对象

The hooks are used for "method injecting", basically mapping __call() to a hook registered by external controller. It's not a good development practice, but can make things easier for developers by add-on designers. There is also a hook which is called by all objects when they are initialized, and that one can be used to intercept anything even substitute objects with another objects.

总的来说，我认为我有里面的文件大约20个不同的钩子使用。有些是多次执行或同一类内不同的实例。

Overall, I think I have about 20 different hooks inside the files to use. Some are executed multiple times or inside different instances of same class.

能够替代类自己是非常重要的。例如，在我的框架，它有一个标准的UI类，如形式。所以附加我只需要使用这个类：

Ability to substitute class with your own is really important. For example in my framework it has a standard UI classes such as "Form". So Add-on my just use that class:

$f=$this->add('Form');
$f->addField('name');

Form类在框架中定义是这样的：

The Form class is defined like this in the framework:

class Form extends Form_Basic {}

这使得它可以为用户覆盖类的定义，因此使附加使用窗体类自己选择的。

Which makes it possible for user to override class definition and therefore make add-on use form class of their choice.

我觉得附加屈尊归结为：

I think add-on deign boils down to:

• 安装简单，使用


• 避免附加组件之间的冲突


• 定义不同的附加类型 - 身份验证，用户界面​​，行为


• 注册回调里面附​​加


• 给了很大的功率才能附加在不牺牲性能

但是，如果你还打算增加你的框架：

But also if you intend to grow your framework:

• 允许用户继承的插件类的，延长


• 允许其他附加取决于你


• 请提交轻松附加到了第三方的中央资料库


• 明确定义插件应如何编写

有关你的结构，我建议你放置更多的回调，使插件决定使用哪些。这里是附加敏捷工具包，其中添加的记住我复选框，默认的登录屏幕的例子：

For your structure, I'd suggest to place many more call-backs and make plugins decide which ones to use. Here is the example of the add-on in Agile Toolkit which add's "remember me" checkbox to the default login screen:

https://github.com/ atk4 / atk4-插件/ BLOB / 4.2 /认证/ lib目录/控制器/ Cookie.php

这篇关于PHP的插件架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！