Resource Plugin are tied to bootstrapping process in Zend Framework. In order to get a good understanding of Resource Plugins, it would be good to first of all take a step back and have an overview of what Bootstrapping means in Zend Framework’s context. This would help in getting a better understanding of what actually goes on when we say we want to make use of or write our own Resource plugins.
So what exactly is Bootstrapping?
Whenever a Zend Framework application is accessed, the following process must occur in order for the application to run and respond to a request. These processes occur in the order that they are listed below:1.Application Bootstrapping: This is the process of preparing the application and making sure things needed to run it are available: setting up application environment etc.
2.URL Routing: Process of getting the URL and determining the respective Modules, Controller, Action that is being referred to in the application.
3.Dispatch: This is actually the process of initiating and calling the necessary controller and action from the specified module (if module is specified)
As you can see, the first thing that happens is the Bootstrapping process and this is what we are most interested in, in this post.
So what does the Bootstrapping do? As stated above, it is basically the process of initiating your application and making it ready. In Zend Framework, it is the Zend_Application component that takes care of this. The Official Documentation describes Zend_Application as providing a bootstrapping facility for applications which provides re-usable resources, common- and module-based bootstrap classes and dependency checking. Simply put: It sets your application running.
One important thing to take note of is the fact that at the point of Bootstrapping, your application is not aware of what will happen next after bootstrapping; i.e. which Module, Controller or Action that would be called, but what it does is to make dependencies or settings which might be needed at later stages in your application available; and accessible when needed.
A trivial example would be having the Operating System the application is running set and available later on in the request process.
So that is Bootstrapping: getting the application ready to run. But what if you want to include some certain operations in your Bootstrapping process? Is there a way to do this?
Yes! Thankfully Zend Framework allows us to ‘interfere’ or better put, to customize what goes on during this Bootstrapping process. Meaning we can determine which codes to run as part of the default bootstrapping routine, and thus we can specify which constants, resources etc should be set and made available at the end of bootstrapping.
And it is this that leads us to Resource Plugins because as you would soon see, Resource Plugin is Zend Frameworks way of letting us have our own code that can be Plugged in during Bootstrapping.
The methods we have for this sort of inclusion during Bootstrapping are via Resource Methods and Resource Plugins.
Resource Methods using Bootstrap.
The Zend_Application works with Zend_Application_Bootstrap in the business of bootstrapping. This is why in your Bootstrap.php file the Zend_Application_Bootstrap is always extended (and Zend_Application_Module_Bootstrap in the case where you have modules)To set up codes that run during the bootstrap process, just create a Method of the Bootstrap class and prepend it with _init.
Let’s assume you have some contact info (say email, phone, address etc.) that you want to make globally available in your application. One way to do this is to set these variables during the bootstrapping processes.
Let’s see how the code may look:
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
protected function _initInfo()
{
$contact= array(
'email' => 'youremail@yourdomain.com',
'phone' => 'yourphonenumber',
'address' => 'youraddress'
);
}
Zend_Registry::set("contact ", $contact);
}
Notice that the Zend_Registry is used to store the array. Other Zend Components just like Zend_Registry can be accessible at the point of Bootstraping.
With this, you can now access the stored variables anywhere in your application via
Zend_Registry::get('contact');This is what is called Resource Methods: And it brings us to the next method which is actual Resource Plugins
Resource Plugins
At this point, you now know what Resource methods are and how they are created. What you would notice with Resource methods is the fact that they are tied to a particular Bootstrap and thus it is a tad more difficult to re-use whatever code you have in that Bootstrap in other different applications.Sometimes you have certain bootstrapping functionalities that are general enough to be re-used across different applications and not have tied to a specific Bootstrap file. It is for such instances that you would find yourself needing to write a Resource Plugin.
Resource Plugin make code (that are needed during bootstrapping) easily re-useable across different projects.
So let us see how this is done.
Writing Resource Plugin
To illustrate, we will use yet another trivial example: setting up global application variables. Most likely if you have an application, you would have settings like the App Name, App Version, List of Developers, License, Copyright, Company Name etc. This is general enough for you to want to put the process of setting these variables up into a Resource Plugin instead of a Resource method.
To write a Resource Plugin, first thing you do is to edit your application.ini file as the application.ini file is needed for you to put a Resource Plugin together. So, for our example let’s assume the variables we want to set are Application Name, Application Version, List of Developers, and license.
Next, let’s also assume that the Resource Plugin code that we would be writing would be found in appsettings.php.
You can then have the following in your application.ini
pluginPaths.MyResource = APPLICATION_PATH "/../library/resourceplugins"
What this means is that you have a Class prefix named “MyResource” and it autoloads from the APPLICATION_PATH "/../library/resourceplugins/".
This also allows Zend Framework know where your Resource Plugin, which would have MyResource as Class Prefix, be located.
So we have the Resource plugin file (named appsettings.php with MyResource as Class Prefix) and it would be placed inside the resourceplugins folder.
Next thing you should do in the application.ini file is to set the values you want for your resource plugin.
Your application.ini may look like this:
resources.appsettings.name = Zend Awesome App //name of app resources.appsettings.version = 1.4.0 //version of app resources.appsettings.developers = Jack,Jill //developers resources.appsettings.license = GPL //type of license for your app
With the above you have specified that you have a resource called appsettings with name, version, developers and license as options which has been set.
This is the basic thing you need to do as far as the application.ini is concerned. The next thing is to author the appsettings.php file itself.
The appsettings.php should contain codes that would look like this:
class MyResource _ appsettings extends Zend_Application_Resource_ResourceAbstract
{
protected $_options = array(
' name ' => 'default_name',
' version ' => 'default_version',
' developers ' => 'default_list_of_developers',
' license ' => 'default_license',
);
public function init()
{
$option = $this->getOptions();
Zend_Registry::set('name', $option['name]);
Zend_Registry::set('version', $option['version']);
Zend_Registry::set('developers', $option['developers']);
Zend_Registry::set('license', $option['license'])
}
Notice that the class extends Zend_Application_Resource_ResourceAbstract. This is what makes the class a Resource Plugin and not something else.
Now,let’s take a look at some of the things going up there.
What this Resource plugin does is simple. It just takes the value entered in the Application.ini and stores it in Zend_Registery thereby making it available, application wide in the project.
First thing you have is the protection $_option property being assigned in an array of values. This is such that you have default values for the keys in the appsettings Resource Plugin should in case it is not specified in the application.ini
Next thing you have is Zend_Registry being set in the init Method. This is what makes the values globally present in your application and as you can see, the values that are set in the application.ini (or the default) can be retrieved via the getOptions() method of the Resource Plugin Class.
The getOptions is one of the Method you have available for you for use from the class Zend_Application_Resource_ResourceAbstract which your Resource Plugin is extending. Other methods include setOptions, mergeOptions etc. To see the available methods and have an idea of what they do you can take a peek at the Zend_Application_Resource_ResourceAbstract class itself which you can find in
Library/Zend/Application/Resource/ResourceAbstract.php
And it goes without saying that your Resource Plugin is a full fledge PHP class meaning you can write more additional methods that gets to perform more complex task during the bootstrapping process other than just creating a Zend_Registry key like we have in the trivial example above.
Just like most of every other thing in Zend Framework, there are some Resource Plugins already made available to you that you can use in your application instead of having to reinvent the wheel. The common ones that you would find yourself using include DB (for setting Db related settings), Layout (for Layout specific settings), Modules (for setting up modular application structure), Router (for setting up customized routing) etc. These available Resource Plugins that ship with Zend Framework are quite handy. You can find the available resource plugins on Zend Framework Official Manual page.
I guess we’ve finally gotten to the end of the series on Zend Framework’s plugin. I really hope these 3 posts (the previous two being on Simple class/front Controller Plugin and Controller Action Helper/View Helper) will help shed more light into the world of Plugins as we have them in Zend Framework.
Got any suggestions or thoughts? Do drop them in the comments.
Simply awesome post bro...
ReplyDelete