这段时间, 一直在分析magento, discuz, wordpress等程序, 这些产品都号称有良好的插件机制. 虽然不尽正确, 也列表一下各产品的插件执行原理.
discuz: 说它是插件可能太局域性, 这就像先在模板上放一个变量, 然后让用户在后面对这变量进行赋值与修改, 类似:
<?php if(!empty($_G['setting']['pluginhooks']['viewthread_profileside'][$postcount])) echo $_G['setting']['pluginhooks']['viewthread_profileside'][$postcount];?>
是由{hooks/viewthread_profileside $postcount}产生出来的, 可以看到, 这完全是在判断一个数组值的显示过程. discuz在模板上勾注了许多hooks, 即表明这块有可能会显示些其它信息.
wordpress:
wordpress我是持保留意见的, oschina里面许多人将这程序神化, 说什么它是最优秀的blog程序, 我想未免太长他人志气灭自己威风了, 什么都不说, 单纯的:memory_get_peak_usage()测试都可以让wp颜面无存了, 你要知道discuz内存memory_get_peak_usage才4MB呀, wp是14MB. wp的插件跟discuz不同, 因为discuz到达模板后基本上已经是变量了, 变量动作是无法获取的, 而wp到达模板时然后有无尽的函数, 所以这儿可以大下功夫了. 但wp使用的却是最低效非智能的方法, 就是指定勾注函数, 你在模板上对函数进行追踪, 然后函数体内如果有apply_filters字样, 就表示可以利用插件重写它. 函数加载时, 并非以主体函数为基础, 而是先计算插件重写函数的顺序, 然后将主体函数丢给第一组的插件函数. 也就是说, 假如十个插件都勾注了一个函数, 那怎么办呢? 只有一个插件能够得到原始函数的值, 其它的插件都是在后(一定是在后)叠加执行.
magento:
magento可能是最大型的web程序了, 它的确是实现了积木一样, 将显示层划成一块一块, 由模板驱动功能. 它的插件功能事实上是对模型的一次重写, 它不许可说你纯粹想改标题的颜色, 就提供一个hooks,或者接口给你, 你要改标题颜色, 那就重写整个head模型. 它也不具有多重重写功能, 比如人家写好了一个模型, 我想在原来的模型上继续深入, 你必须完成旧模型的所有方法, 也就是copy一份旧模型的所有, 然后自行修改. 这点跟wp, dz有所不同, wp, dz能够在一个hooks上注入多次执行, 而magento只能一次. 这样也有好处, 至少扩展性更好. 免得东扯西拼.
尽管wp, dz号称插件上十万, 可你却发现真正玩互联网, 真正从事互联网的公司对这些插件却是淡淡如斯, 插件的意义何在? 那些没有依用户需求而产生的插件如何突破. web是否需要插件.以下是我的观点:
假如我们制作一个dz的插件, 而前面有人已经写过了, 这时你第一想法就是继续旧插件然后重写, 可这儿有个严重的问题, 旧插件是否提供技术支持, 是否保持更新, 是否保持结构不变? 哪天人家更新了, 结构一改变, 那继承这个插件的新插件将会无法运行. 为此, 大家应该都知道, 插件肯定是原生继承在官方基础上的, 这样才是最保险的做法. 反过来也是一样, 官方调用一个插件安全, 要是循环在一个功能块上释放多个插件, 总会出现问题.理论上是不存在两个插件同时运行在一个hooks上,比如一个人同时安装了A,b,c公司的插件, 我想这种需求几乎为0, 决大多数类似于magento的某块模型全部私有重写, 更为理想.
插件模式不是在模板中放满了hooks点, 这只会增加插件开发者的设计成本. 插件有必要形成私有继承, 开发者如果需要写插件, 就将整个块的php, 模板都copy一份. 然后修改成自己插件的需求. 这点在企业web上特别重要, 没有哪家企业是专门安装不同的插件的, 通常是自行开发, 或者找专业技术团队. 既然有这技术, 自然也不需要你来提醒它hooks放哪, 程序做好主体与插件的结构继承判断即可.
插件模式走向积木块方式才能更好地发展起来, dz, wp目前的方式属于小众化, 终究会落幕.
做事的能力往往只能给你一种机会，
