我正在阅读Zend Framework Book:Survive the Deep End关于资源方法.它讲述了资源方法如何覆盖资源插件.
但是等等,还有一个资源插件(Zend_Application_Resource_View),它也可以创建一个名为View的资源.我们可以有两个查看资源吗？答案是否定的 - 我们只能拥有一个和一个
创建可重用的引导资源并将大部分编码卸载到离散类的好方法是利用资源插件......意图是开发人员应该编写自己的封装自己的初始化需求
对我来说,资源方法似乎是一种更直观的资源初始化方式,为什么我应该使用插件？这只是一个我更喜欢哪个问题？或者他们在不同的情况下使用？
资源方法会替换或添加由提供的资源插件提供的功能吗？因为如果它取代了,我需要确保我初始化所有变量或我需要的任何东西？
通过从_initView()返回新的Zend_View实例,Zend_Application将接受替换,并且不会尝试通过运行Zend_Application_Resource_View来设置标准的默认Zend_View实例来覆盖我们的更改,我们刚刚纠正了这些缺陷
如果我不回复Zend_View,那就好像我没有这个方法？我可以说我应该总是从资源方法中返回一些内容吗？
在这里,我们通过使用getResource()方法来检索Zend_Application_Resource_Frontcontroller创建和配置的Zend_Controller_Front实例,从而做同样的事情.
从上面可以说,如果我希望我的资源方法具有由提供的资源插件设置的默认值,我可以做getResource()第1个？
回答你的问题:
我应该使用资源插件还是方法？
我会说这很大程度上取决于个人偏好.正如您从手册中引用的那样,如果您使用资源插件,则在另一个项目中重用代码变得更加容易(因为它更容易移动/测试类而不是从方法中剪切''''''''''''''''') .在我看来,方法使得更容易看到引导程序中发生了什么,至少在它们开始变得有点复杂之前,在这种情况下将它们转换为插件是有意义的.
资源方法是否会替换或添加资源插件提供的功能？
我相信它的工作方式是在首次实例化bootstrap类时加载并初始化插件.然后,引导程序将通过您的方法并运行它们.如果您的方法名称与插件资源相同,则您的方法将覆盖该插件.但是,您也可以从方法中访问现有资源并对其进行修改,在这种情况下,您的方法将添加到插件提供的功能中.
请记住,插件不会自行运行(除了前控制器插件,它将始终运行).它们仅在您的application.ini触发它们时使用(或者如果您使用自己的方法调用它们).
如果我不返回Zend_View,那就好像我没有这个方法？我可以说我应该总是从资源方法中返回一些内容吗？
优良作法是从资源方法返回一些东西,因为这允许该资源被其他方法或应用程序的其他部分访问.但是,该方法仍将在没有返回值的情况下运行.但是如果你添加一个_initView方法并设置一个新的Zend_View对象,如果你不对它做任何事情,它将对你的应用程序没有任何影响.
我可以说,如果我希望我的资源方法具有由提供的资源插件设置的默认值,我可以做一个getResource()
是.但是我会确保在这种情况下返回资源,只是为了访问资源的任何其他方法都使用您修改过的资源而不是插件设置的方法.
我个人会坚持使用application.ini +资源插件或资源方法.如果所有资源都在一个地方,那么更容易看到发生了什么.
| 归档时间： |
|
| 查看次数： |
638 次 |
| 最近记录： |