views:

73

answers:

1

i was reading Zend Framework Book: Survive the Deep End about resource methods. it speaks about how resource methods will override resource plugin.

But wait, there's also a Resource Plugin (Zend_Application_Resource_View) which may also create a Resource called View. Can we have two View Resources? The answer is no - we can have one and one only

in Zend Framework Manual,

a good way to create re-usable bootstrap resources and to offload much of your coding to discrete classes is to utilize resource plugins ... the intention is that developers should write their own to encapsulate their own initialization needs

to me, resource methods seem like a more intuitive way to initialize resources, why then should I use plugins? is it just a question of which do I prefer? or are they used in different circumstances?

will resource methods replace or add to the functionality provided by the provided resource plugins? because if it replaces, I would need to make sure i initialize all variables or whatever I need?

By returning the new Zend_View instance from _initView(), Zend_Application will accept the replacement and will not attempt to overwrite our changes by running Zend_Application_Resource_View to set up a standard default Zend_View instance with the flaws we just corrected

if I dont return a Zend_View, it will be as if I didn't have the method? can I say that I should always return something from resource methods?

Here, we do the same thing by using the getResource() method to retrieve an instance of Zend_Controller_Front created and configured by Zend_Application_Resource_Frontcontroller

from the above, can i say that if i want my resource methods to have the defaults set by the provided resource plugin, i can do a getResource() 1st?

+3  A: 

Answering your questions:

Should I use resource plugins or methods?

I would say it's largely down to personal preference. As your quote from the manual says, if you use a resource plugin, it becomes easier to reuse the code in another project (as it's easier to move around/test a class than it is to cut'n'paste text from a method). In my opinion methods make it a little easier to see what's going on in the bootstrap, at least until they start becoming a bit complex, in which case it'd make sense to convert them into a plugin.

Will resource methods replace or add to the functionality provided by resource plugins?

I believe the way it works is that plugins are loaded up and initialised when the bootstrap class is first instantiated. The bootstrap will then go through your methods and run those. If you have a method named the same as a plugin resource, your method will override that plugin. However you can also access the existing resource from your method and modify it, in which case your method is adding to the functionality provided by the plugin.

Remember that plugins don't magically run by themselves (apart from the front controller plugin, which will always run). They will only be used if your application.ini triggers them (or if you call them from your own methods).

If I dont return a Zend_View, it will be as if I didn't have the method? can I say that I should always return something from resource methods?

It is good practice to return something from resource methods as this allows that resource to be accessed by other methods or other parts of the application. However the method will still run without the return value. But if you added an _initView method and setup a new Zend_View object, if you don't do anything with it it won't have any effect on your application.

Can i say that if i want my resource methods to have the defaults set by the provided resource plugin, i can do a getResource()

Yes. But I would make sure you return the resource in this case, just so that any other methods that access the resource are using your modified one rather than the one setup by the plugin.

Personally I would either stick to application.ini + resource plugins, or resource methods. It's easier to see what's going on if all of the resource stuff is in one place.

Tim Fountain