4,250
社区成员
发帖
与我相关
我的任务
分享讨论一下，关于plugin的实现
关于plugin的实现,都来谈谈你熟悉的什么开源系统里是如何实现plugin的吧,
尤其你觉得比较好的.
我了解vbulletin和wordpress的, 嗯,还有gallery的,
但是都是不是太满意, 看看其它的有无更好的.
如果你有自己的想法,也说说看吧
尤其你觉得比较好的.
我了解vbulletin和wordpress的, 嗯,还有gallery的,
但是都是不是太满意, 看看其它的有无更好的.
如果你有自己的想法,也说说看吧
...全文
请发表友善的回复…
发表回复
helloyou0 2010-09-15
- 打赏
- 举报
帖子不顶就是不行....
青蛙现在越来越能侃了... :) 说得很好, php就是太自由...缺少规范....缺少统一的平台....不过自由也有好处,就是谁都可以拿来创新一下...所以PHP的开源最多...
我对兼容不太在意...目前的情况下,除非在php层面,否则不太可能在不同php软件间兼容.
对我来说,plugin的好处就是在改变功能的时候可以不触及核心代码,这个对一些经常需要定制的软件非常好,....咳咳,这些客户和领导们提变态需求的想象力总是超出程序员的想象....
前几天翻手册看到这章,
http://ca.php.net/manual/en/ref.runkit.php
不过好像更新不够, 这个东东用来做插件倒是够强大.......
就是太强大了以至于没法控制....如果滥用,这个代码上帝也要看昏掉...
话说回来,还有什么开源项目的plugin设计能推荐给我看的吗? 谢谢
青蛙现在越来越能侃了... :) 说得很好, php就是太自由...缺少规范....缺少统一的平台....不过自由也有好处,就是谁都可以拿来创新一下...所以PHP的开源最多...
我对兼容不太在意...目前的情况下,除非在php层面,否则不太可能在不同php软件间兼容.
对我来说,plugin的好处就是在改变功能的时候可以不触及核心代码,这个对一些经常需要定制的软件非常好,....咳咳,这些客户和领导们提变态需求的想象力总是超出程序员的想象....
前几天翻手册看到这章,
http://ca.php.net/manual/en/ref.runkit.php
不过好像更新不够, 这个东东用来做插件倒是够强大.......
就是太强大了以至于没法控制....如果滥用,这个代码上帝也要看昏掉...
话说回来,还有什么开源项目的plugin设计能推荐给我看的吗? 谢谢
helloyou0 2010-08-25
- 打赏
- 举报
很好，很好，谢谢
还有别的值得一看的吗
还有别的值得一看的吗
骄傲青蛙 2010-08-25
- 打赏
- 举报
我觉得plug最大问题是兼容性，次之是灵活性，安全性。
例一，
就拿dz说事， 写dz的plug，但它不能应用基于其核心产品各个系统应用程序，在dz的里的插件不能放到uchome里用，之类。
提到这点，可以说是个代码封装的问题，php的产品都独立存在和发展，和asp.net一样，在.net中，你写一个用户控件可以应用到任何的产品，这点非常好，重用率高。
而php不能，discuz的插件不能拿到workpress里用，如上所说，php产品之间相对较独立，低偶合所决定，它没像.net一样的平台。
例二，
如分页函数/类，在一个项目里你可能把它封装叫插件，但这个插件却没办法应用到另一个项目，
因为很可能它们之前分别实现的M.V.C层都不一样，输入和输出都以不同形式进行。
假设，如果php有像.net一样的平台，我们做的插件就可以基于这个平台或协议来开发插件，这样重用率高，提高生产效率的同时能节省很多的时间去做设计。
小结
假设，我们PHP项目的V层都统一用smarty去做，所有业务功能，如html escape, nl2br, bbcode2html之类的都用smarty处理，或者通过插件方式去完成，这样，我们的workpress里的插件就可移植到其它项目，如drupal
V层这么做，而M层和C层也由成熟的产品去完成，这样我们的插件才更通用，如果插件机制都统一起来了，大家讨论时不必顾虑太多环境因素，经验上的差别，这有助于插件方面的发展和进步。
如你所说的从vbulletin到wordpress， gallery他们实现插件的机制其实都是大同小异，但就是有不同地方，因为它们不统一，你做你的，我做我的，程序员写插件的时间都用在看手册，重新了解各个系统特性，而不是用在对插件的统一改善，更新，升级，还有共同的讨论和进步，
例一，
就拿dz说事， 写dz的plug，但它不能应用基于其核心产品各个系统应用程序，在dz的里的插件不能放到uchome里用，之类。
提到这点，可以说是个代码封装的问题，php的产品都独立存在和发展，和asp.net一样，在.net中，你写一个用户控件可以应用到任何的产品，这点非常好，重用率高。
而php不能，discuz的插件不能拿到workpress里用，如上所说，php产品之间相对较独立，低偶合所决定，它没像.net一样的平台。
例二，
如分页函数/类，在一个项目里你可能把它封装叫插件，但这个插件却没办法应用到另一个项目，
因为很可能它们之前分别实现的M.V.C层都不一样，输入和输出都以不同形式进行。
假设，如果php有像.net一样的平台，我们做的插件就可以基于这个平台或协议来开发插件，这样重用率高，提高生产效率的同时能节省很多的时间去做设计。
小结
假设，我们PHP项目的V层都统一用smarty去做，所有业务功能，如html escape, nl2br, bbcode2html之类的都用smarty处理，或者通过插件方式去完成，这样，我们的workpress里的插件就可移植到其它项目，如drupal
V层这么做，而M层和C层也由成熟的产品去完成，这样我们的插件才更通用，如果插件机制都统一起来了，大家讨论时不必顾虑太多环境因素，经验上的差别，这有助于插件方面的发展和进步。
如你所说的从vbulletin到wordpress， gallery他们实现插件的机制其实都是大同小异，但就是有不同地方，因为它们不统一，你做你的，我做我的，程序员写插件的时间都用在看手册，重新了解各个系统特性，而不是用在对插件的统一改善，更新，升级，还有共同的讨论和进步，
phper_cd 2010-08-24
- 打赏
- 举报
drupal的写法还不错，启用的时候执行xxx.install文件和xxx.module文件，而且基本都是在实现hook，xxx.info保存着模块信息，各个分工都很明确
xuzuning 2010-08-24
- 打赏
- 举报
插件无非就是一个功能模块，他通过指定的规则与主系统交换信息。当然应该封装成类
helloyou0 2010-08-24
- 打赏
- 举报
[Quote=引用 2 楼 jameshooo 的回复:]
PHP反正是动态解析名称的，用名称约束可能是最简洁的插件机制，无论是用函数还是类成员都一样，发现存在这种名称就当成插件调用。然后在参数上增加一些约定，或者核心提供某些API或工具类给插件使用。
[/Quote]
你说的这个，有无实际应用的开源项目？ 想看看，
粗粗想想觉得还行，但是有时实际使用会有意料之外的问题
PHP反正是动态解析名称的，用名称约束可能是最简洁的插件机制，无论是用函数还是类成员都一样，发现存在这种名称就当成插件调用。然后在参数上增加一些约定，或者核心提供某些API或工具类给插件使用。
[/Quote]
你说的这个，有无实际应用的开源项目？ 想看看，
粗粗想想觉得还行，但是有时实际使用会有意料之外的问题
helloyou0 2010-08-24
- 打赏
- 举报
[Quote=引用 1 楼 amani11 的回复:]
值得深究的话题，LZ先说说，不满意在哪里呢？
个人觉得关键在于对插件的管理方式？，如果这个需求是定的，那核心系统设计上，对plugin的管理模块也就定了，具体的插件，也只能按照规范来开发。
MARK，聆听高见
[/Quote]
vbulletin的比较原始，实际就等于直接插代码进去，开发不方便，变量容易冲突，也容易互相影响。
wordpress稍微改进一点不过本质也是一样的，这2个都是因为主软件都是非面向对象的，所以插件代码也不容易封装。
gallery2的看着较好，不过没有细研究。
主要想看看大家用过的有无更好的，值得学习的。
值得深究的话题，LZ先说说，不满意在哪里呢？
个人觉得关键在于对插件的管理方式？，如果这个需求是定的，那核心系统设计上，对plugin的管理模块也就定了，具体的插件，也只能按照规范来开发。
MARK，聆听高见
[/Quote]
vbulletin的比较原始，实际就等于直接插代码进去，开发不方便，变量容易冲突，也容易互相影响。
wordpress稍微改进一点不过本质也是一样的，这2个都是因为主软件都是非面向对象的，所以插件代码也不容易封装。
gallery2的看着较好，不过没有细研究。
主要想看看大家用过的有无更好的，值得学习的。
jameshooo 2010-08-24
- 打赏
- 举报
嗯，参考drupal的扩展机制，全是用名称实现钩子，不一定需要注册后才调用，合适的函数名、类成员名、文件名，只要放在那，让drupal自己来找
liangpei2008 2010-08-24
- 打赏
- 举报
那楼主先说说你理想中的插件是什么样的
jameshooo 2010-08-21
- 打赏
- 举报
PHP反正是动态解析名称的，用名称约束可能是最简洁的插件机制，无论是用函数还是类成员都一样，发现存在这种名称就当成插件调用。然后在参数上增加一些约定，或者核心提供某些API或工具类给插件使用。
amani11 2010-08-21
- 打赏
- 举报
值得深究的话题，LZ先说说，不满意在哪里呢？
个人觉得关键在于对插件的管理方式？，如果这个需求是定的，那核心系统设计上，对plugin的管理模块也就定了，具体的插件，也只能按照规范来开发。
MARK，聆听高见
个人觉得关键在于对插件的管理方式？，如果这个需求是定的，那核心系统设计上，对plugin的管理模块也就定了，具体的插件，也只能按照规范来开发。
MARK，聆听高见
