我正在编写一个非常复杂的插件,它被组织成一个父“容器”类和几个子类,其中每个子类都是一个可选/强制元素,通常(但并不总是)映射到他自己的add_submenu_page。
基本上,这是一个插件与他的私人集,让我们称之为“子插件”。
每个子类/子插件都有自己的(大) add_action和add_filter集。所以,从技术上讲,我的插件的子插件是一个有效的WP插件,简单地说,它不是由WP本身直接调用的。
由于我使用了大量的planned...actually _action.我想知道是否应该使用“私有”观察者/中介模式来重构我的插件。只收集所有相关的add_actions到我的父类,并建立一个模式来通知/转发事件的子类,减少我的插件对WP事件的影响。
这是个好主意还是绝对没有必要?你能帮我编写一些类重构的代码吗?
tnx提前寻求帮助,加布里埃尔
发布于 2011-04-16 12:20:27
我想知道是否应该使用“私有”观察者/中介模式来重构我的插件。只收集所有相关的add_actions到我的父类,并建立一个模式来通知/转发事件的子类,减少我的插件对WP事件的影响。
事件队列是WP的基础,所以它非常快,而且一直都是越快越快。
所以,我认为做自己的子队列是没有任何意义的,从性能上讲。
重构您的代码,这样您就不必手动进行每个add_action()调用,这是另一回事。
发布于 2011-04-16 11:05:31
所以..。我基本上采取了同样的方法,不知道它是否正确。我认为很多人都采用这种方法,因为它是通过使用设置api自然产生的。
这里:http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-load-configuration.php
我认为这是由大多数人自动完成的,因为例如,一个模块:http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-module.php对应于我们需要为设置api所做的工作。
这里:http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-init.php
(其中插件检查它们是否应该被激活,如果它们在相应的管理页面上打开)(并且可以用抽象的:http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-plugin.php表示)
因此,从另一边“后端站点”,我只定义了我自己的过滤器,其中每个插件都可以自己附加到例如,http://plugins.svn.wordpress.org/wp-favicons/trunk/plugins/metadata_favicon/inc/class-feicon-factory.php定义过滤器,如"Config::GetPluginSlug()“。
所以总的来说..。我认为设置API很自然地驱使我们采用这种方法。
所以..。然后,有些人谈到了(你的问题),在这个问题中,你会考虑重新考虑你自己在“其他事情”中的附加动作,这可能是观察者/中介模式或其他任何东西。
但是..。由于我们使用了WordPress方法,使用了设置API (上面的所有内容),通过使用它,第三方可以轻松地“加入”操作,编写自己的帮助页面扩展等等.我在这里也会坚持使用add_action,因为设计的“其余部分”也遵循这一点,这可能使理解整个代码变得更容易。
发布于 2011-04-21 12:58:01
另一个很好的例子,用于分发带有子插件的插件是这个吗?。
https://wordpress.stackexchange.com/questions/14901
复制相似问题