Previous Next

Theory of Operation

Getting an MVC application configured and ready to dispatch has required an increasing amount of code as more features become available: setting up the database, configuring your view and view helpers, configuring your layouts, registering plugins, registering action helpers, and more.

Additionally, you will often want to reuse the same code to bootstrap your tests, a cronjob, or a service script. While it's possible to simply include your bootstrap script, oftentimes there are initializations that are environment specific – you may not need the MVC for a cronjob, or just the DB layer for a service script.

Zend_Application aims to make this easier and to promote reuse by encapsulating bootstrapping into OOP paradigms.

Zend_Application is broken into three realms:

  • Zend_Application: loads the PHP environment, including include_paths and autoloading, and instantiates the requested bootstrap class.

  • Zend_Application_Bootstrap: provides interfaces for bootstrap classes. Zend_Application_Bootstrap_Bootstrap provides common functionality for most bootstrapping needs, including dependency checking algorithms and the ability to load bootstrap resources on demand.

  • Zend_Application_Resource provides an interface for standard bootstrapping resources that can be loaded on demand by a bootstrap instance, as well as several default resource implementations.

Developers create a bootstrap class for their application, extending Zend_Application_Bootstrap_Bootstrap or implementing (minimally) Zend_Application_Bootstrap_Bootstrapper. The entry point (e.g., public/index.php) will load Zend_Application, and instantiate it by passing:

  • The current environment

  • Options for bootstrapping

The bootstrap options include the path to the file containing the bootstrap class and optionally:

  • Any extra include_paths to set

  • Any additional autoloader namespaces to register

  • Any php.ini settings to initialize

  • The class name for the bootstrap class (if not "Bootstrap")

  • Resource prefix/path pairs to use

  • Any resources to use (by class name or short name)

  • Additional path to a configuration file to load

  • Additional configuration options

Options may be an array, a Zend_Config object, or the path to a configuration file.

Bootstrapping

Zend_Application's second area of responsibility is executing the application bootstrap. Bootstraps minimally need to implement Zend_Application_Bootstrap_Bootstrapper, which defines the following API:

interface Zend_Application_Bootstrap_Bootstrapper
{
    public function __construct($application);
    public function setOptions(array $options);
    public function getApplication();
    public function getEnvironment();
    public function getClassResources();
    public function getClassResourceNames();
    public function bootstrap($resource = null);
    public function run();
}

This API allows the bootstrap to accept the environment and configuration from the application object, report the resources its responsible for bootstrapping, and then bootstrap and run the application.

You can implement this interface on your own, extend Zend_Application_Bootstrap_BootstrapAbstract, or use Zend_Application_Bootstrap_Bootstrap.

Besides this functionality, there are a number of other areas of concern you should familiarize yourself with.

Resource Methods

The Zend_Application_Bootstrap_BootstrapAbstract implementation provides a simple convention for defining class resource methods. Any protected method beginning with a name prefixed with _init will be considered a resource method.

To bootstrap a single resource method, use the bootstrap() method, and pass it the name of the resource. The name will be the method name minus the _init prefix.

To bootstrap several resource methods, pass an array of names. Too bootstrap all resource methods, pass nothing.

Take the following bootstrap class:

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initFoo()
    {
        // ...
    }

    protected function _initBar()
    {
        // ...
    }

    protected function _initBaz()
    {
        // ...
    }
}

To bootstrap just the _initFoo() method, do the following:

$bootstrap->bootstrap('foo');

To bootstrap the _initFoo() and _initBar() methods, do the following:

$bootstrap->bootstrap(array('foo', 'bar));

To bootstrap all resource methods, call bootstrap() with no arguments:

$bootstrap->bootstrap();

Bootstraps that use resource plugins

To make your bootstraps more re-usable, we have provided the ability to push your resources into resource plugin classes. This allows you to mix and match resources simply via configuration. We will cover how to create resources later; in this section we will show you how to utilize them only.

If your bootstrap should be capable of using resource plugins, you will need to implement an additional interface, Zend_Application_Bootstrap_ResourceBootstrapper. This interface defines an API for locating, registering, and loading resource plugins:

interface Zend_Application_Bootstrap_ResourceBootstrapper
{
    public function registerPluginResource($resource, $options = null);
    public function unregisterPluginResource($resource);
    public function hasPluginResource($resource);
    public function getPluginResource($resource);
    public function getPluginResources();
    public function getPluginResourceNames();
    public function setPluginLoader(Zend_Loader_PluginLoader_Interface $loader);
    public function getPluginLoader();
}

Resource plugins basically provide the ability to create resource intializers that can be re-used between applications. This allows you to keep your actual bootstrap relatively clean, and to introduce new resources without needing to touch your bootstrap itself.

Zend_Application_Bootstrap_BootstrapAbstract (and Zend_Application_Bootstrap_Bootstrap by extension) implement this interface as well, allowing you to utilize resource plugins.

To utilize resource plugins, you must specify them in the options passed to the application object and/or bootstrap. These options may come from a configuration file, or be passed in manually. Options will be of key/options pairs, with the key representing the resource name. The resource name will be the segment following the class prefix. For example, the resources shipped with Zend Framework have the class prefix "Zend_Application_Resource_"; anything following this would be the name of the resource. As an example,

$application = new Zend_Application(APPLICATION_ENV, array(
    'resources' => array(
        'FrontController' => array(
            'controllerDirectory' => APPLICATION_PATH . '/controllers',
        ),
    ),
));

This indicates that the "FrontController" resource should be used, with the options specified.

If you begin writing your own resource plugins, or utilize third-party resource plugins, you will need to tell your bootstrap where to look for them. Internally, the bootstrap utilizes Zend_Loader_PluginLoader, so you will only need to indicate the common class prefix an path pairs.

As an example, let's assume you have custom resource plugins in APPLICATION_PATH/resources/ and that they share the common class prefix of My_Resource. You would then pass that information to the application object as follows:

$application = new Zend_Application(APPLICATION_ENV, array(
    'pluginPaths' => array(
        'My_Resource' => APPLICATION_PATH . '/resources/',
    ),
    'resources' => array(
        'FrontController' => array(
            'controllerDirectory' => APPLICATION_PATH . '/controllers',
        ),
    ),
));

You would now be able to use resources from that directory.

Just like resource methods, you use the bootstrap() method to execute resource plugins. Just like with resource methods, you can specify either a single resource plugin, multiple plugins (via an array), or all plugins. Additionally, you can mix and match to execute resource methods as well.

// Execute one:
$bootstrap->bootstrap('FrontController');

// Execute several:
$bootstrap->bootstrap(array('FrontController', 'Foo'));

// Execute all resource methods and plugins:
$bootstrap->bootstrap();

Resource Registry

Many, if not all, of your resource methods or plugins will initialize objects, and in many cases, these objects will be needed elsewhere in your application. How can you access them?

Zend_Application_Bootstrap_BootstrapAbstract provides a local registry for these objects. To store your objects in them, you simply return them from your resources.

For maximum flexibility, this registry is referred to as a "container" internally; its only requirements are that it is an object. Resources are then registered as properties named after the resource name. By default, an instance of Zend_Registry is used, but you may also specify any other object you wish. The methods setContainer() and getContainer() may be used to manipulate the container itself. getResource($resource) can be used to fetch a given resource from the container, and hasResource($resource) to check if the resource has actually been registered.

As an example, consider a basic view resource:

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initView()
    {
        $view = new Zend_View();
        // more initialization...

        return $view;
    }
}

You can then check for it and/or fetch it as follows:

// Using the has/getResource() pair:
if ($bootstrap->hasResource('view')) {
    $view = $bootstrap->getResource('view');
}

// Via the container:
$container = $bootstrap->getContainer();
if (isset($container->view)) {
    $view = $container->view;
}

Please note that the registry/container is not global. This means that you need access to the bootstrap in order to fetch resources. Zend_Application_Bootstrap_Bootstrap provides some convenience for this: during its run() execution, it registers itself as the front controller parameter "bootstrap", which allows you to fetch it from the router, dispatcher, plugins, and action controllers.

As an example, if you wanted access to the view resource from above within your action controller, you could do the following:

class FooController extends Zend_Controller_Action
{
    public function init()
    {
        $bootstrap = $this->getInvokeArg('bootstrap');
        $view = $bootstrap->getResource('view');
        // ...
    }
}

Dependency Tracking

In addition to executing resource methods and plugins, it's necessary to ensure that these are executed once and once only; these are meant to bootstrap an application, and executing multiple times can lead to resource overhead.

At the same time, some resources may depend on other resources being executed. To solve these two issues, Zend_Application_Bootstrap_BootstrapAbstract provides a simple, effective mechanism for dependency tracking.

As noted previously, all resources -- whether methods or plugins -- are bootstrapped by calling bootstrap($resource), where $resource is the name of a resource, an array of resources, or, left empty, indicates all resources should be run.

If a resource depends on another resource, it should call bootstrap() within its code to ensure that resource has been executed. Subsequent calls to it will then be ignored.

In a resource method, such a call would look like this:

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initRequest()
    {
        // Ensure the front controller is initialized
        $this->bootstrap('FrontController');

        // Retrieve the front controller from the bootstrap registry
        $front = $this->getResource('FrontController');

        $request = new Zend_Controller_Request_Http();
        $request->setBaseUrl('/foo');
        $front->setRequest($request);

        // Ensure the request is stored in the bootstrap registry
        return $request;
    }
}

Resource Plugins

As noted previously, a good way to create re-usable bootstrap resources and to offload much of your coding to discrete classes is to utilize resource plugins. While Zend Framework ships with a number of standard resource plugins, the intention is that developers should write their own to encapsulate their own initialization needs.

Resources need only implement Zend_Application_Resource_Resource, or, more simply still, extend Zend_Application_Resource_ResourceAbstract. The basic interface is simply this:

interface Zend_Application_Resource_Resource
{
    public function __construct($options = null);
    public function setBootstrap(
        Zend_Application_Bootstrap_Bootstrapper $bootstrap
    );
    public function getBootstrap();
    public function setOptions(array $options);
    public function getOptions();
    public function init();
}

The interface defines simply that a resource should accept options to the constructor, have mechanisms for setting and retrieving options, have mechanisms for setting and retrieving the bootstrap object, and an initialization method.

As an example, let's assume you have a common view intialization you use in your applications. You have a common doctype, CSS and JavaScript, and you want to be able to pass in a base document title via configuration. Such a resource might look like this:

class My_Resource_View extends Zend_Application_Resource_ResourceAbstract
{
    protected $_view;

    public function init()
    {
        // Return view so bootstrap will store it in the registry
        return $this->getView();
    }

    public function getView()
    {
        if (null === $this->_view) {
            $options = $this->getOptions();
            $title   = '';
            if (array_key_exists('title', $options)) {
                $title = $options['title'];
                unset($options['title']);
            }

            $view = new Zend_View($options);
            $view->doctype('XHTML1_STRICT');
            $view->headTitle($title);
            $view->headLink()->appendStylesheet('/css/site.css');
            $view->headScript()->appendfile('/js/analytics.js');

            $viewRenderer =
                Zend_Controller_Action_HelperBroker::getStaticHelper(
                    'ViewRenderer',
                );
            $viewRenderer->setView($view);

            $this->_view = $view;
        }
        return $this->_view;
    }
}

As long as you register the prefix path for this resource plugin, you can then use it in your application. Even better, because it uses the plugin loader, you are effectively overriding the shipped "View" resource plugin, ensuring that your own is used instead.

Previous Next
Introduction to Zend Framework
Overview
Installation
Zend_Acl
Introduction
Refining Access Controls
Advanced Usage
Zend_Amf
Introduction
Zend_Amf_Server
Zend_Application
Introduction
Zend_Application Quick Start
Theory of Operation
Examples
Core Functionality
Available Resource Plugins
Zend_Auth
Introduction
Database Table Authentication
Digest Authentication
HTTP Authentication Adapter
LDAP Authentication
Open ID Authentication
Zend_Cache
Introduction
The Theory of Caching
Zend_Cache Frontends
Zend_Cache Backends
Zend_Captcha
Introduction
Captcha Operation
CAPTCHA Adapters
Zend_CodeGenerator
Introduction
Zend_CodeGenerator Examples
Zend_CodeGenerator Reference
Zend_Config
Introduction
Theory of Operation
Zend_Config_Ini
Zend_Config_Xml
Zend_Config_Writer
Zend_Config_Writer
Zend_Console_Getopt
Introduction
Declaring Getopt Rules
Fetching Options and Arguments
Configuring Zend_Console_Getopt
Zend_Controller
Zend_Controller Quick Start
Zend_Controller Basics
The Front Controller
The Request Object
The Standard Router
The Dispatcher
Action Controllers
Action Helpers
The Response Object
Plugins
Using a Conventional Modular Directory Structure
MVC Exceptions
Migrating from Previous Versions
Zend_Currency
Introduction to Zend_Currency
How to Work with Currencies
Migrating from Previous Versions
Zend_Date
Introduction
Theory of Operation
Basic Methods
Zend_Date API Overview
Creation of Dates
Constants for General Date Functions
Working Examples
Zend_Db
Zend_Db_Adapter
Zend_Db_Statement
Zend_Db_Profiler
Zend_Db_Select
Zend_Db_Table
Zend_Db_Table_Row
Zend_Db_Table_Rowset
Zend_Db_Table Relationships
Zend_Debug
Dumping Variables
Zend_Dojo
Introduction
Zend_Dojo_Data: dojo.data Envelopes
Dojo View Helpers
Dojo Form Elements and Decorators
Zend_Dom
Introduction
Zend_Dom_Query
Zend_Exception
Using Exceptions
Zend_Feed
Introduction
Importing Feeds
Retrieving Feeds from Web Pages
Consuming an RSS Feed
Consuming an Atom Feed
Consuming a Single Atom Entry
Modifying Feed and Entry structures
Custom Feed and Entry Classes
Zend_File
Zend_File_Transfer
Validators for Zend_File_Transfer
Filters for Zend_File_Transfer
Migrating from previous versions
Zend_Filter
Introduction
Standard Filter Classes
Filter Chains
Writing Filters
Zend_Filter_Input
Zend_Filter_Inflector
Zend_Form
Zend_Form
Zend_Form Quick Start
Creating Form Elements Using Zend_Form_Element
Creating Forms Using Zend_Form
Creating Custom Form Markup Using Zend_Form_Decorator
Standard Form Elements Shipped With Zend Framework
Standard Form Decorators Shipped With Zend Framework
Internationalization of Zend_Form
Advanced Zend_Form Usage
Zend_Gdata
Introduction
Authenticating with AuthSub
Using the Book Search Data API
Authenticating with ClientLogin
Using Google Calendar
Using Google Documents List Data API
Using Google Health
Using Google Spreadsheets
Using Google Apps Provisioning
Using Google Base
Using Picasa Web Albums
Using the YouTube Data API
Catching Gdata Exceptions
Zend_Http
Introduction
Zend_Http_Client - Advanced Usage
Zend_Http_Client - Connection Adapters
Zend_Http_Cookie and Zend_Http_CookieJar
Zend_Http_Response
Zend_InfoCard
Introduction
Zend_Json
Introduction
Basic Usage
Advanced Usage of Zend_Json
XML to JSON conversion
Zend_Json_Server - JSON-RPC server
Zend_Layout
Introduction
Zend_Layout Quick Start
Zend_Layout Configuration Options
Zend_Layout Advanced Usage
Zend_Ldap
Introduction
Zend_Loader
Loading Files and Classes Dynamically
The Autoloader
Resource Autoloaders
Loading Plugins
Zend_Locale
Introduction
Using Zend_Locale
Normalization and Localization
Working with Dates and Times
Supported locales
Migrating from previous versions
Zend_Log
Overview
Writers
Formatters
Filters
Zend_Mail
Introduction
Sending via SMTP
Sending Multiple Mails per SMTP Connection
Using Different Transports
HTML E-Mail
Attachments
Adding Recipients
Controlling the MIME Boundary
Additional Headers
Character Sets
Encoding
SMTP Authentication
Securing SMTP Transport
Reading Mail Messages
Zend_Measure
Introduction
Creation of Measurements
Outputting measurements
Manipulating Measurements
Types of measurements
Zend_Memory
Overview
Memory Manager
Memory Objects
Zend_Mime
Zend_Mime
Zend_Mime_Message
Zend_Mime_Part
Zend_Navigation
Introduction
Pages
Containers
Zend_OpenId
Introduction
Zend_OpenId_Consumer Basics
Zend_OpenId_Provider
Zend_Paginator
Introduction
Usage
Configuration
Advanced usage
Zend_Pdf
Introduction
Creating and Loading PDF Documents
Save Changes to PDF Documents
Working with Pages
Drawing
Document Info and Metadata.
Zend_Pdf module usage example
Zend_ProgressBar
Zend_ProgressBar
Zend_Reflection
Introduction
Zend_Reflection Examples
Zend_Reflection Reference
Zend_Registry
Using the Registry
Zend_Rest
Introduction
Zend_Rest_Client
Zend_Rest_Server
Zend_Search_Lucene
Overview
Building Indexes
Searching an Index
Query Language
Query Construction API
Character Set
Extensibility
Interoperating with Java Lucene
Advanced
Best Practices
Zend_Server
Introduction
Zend_Server_Reflection
Zend_Service
Introduction
Zend_Service_Akismet
Zend_Service_Amazon
Zend_Service_Amazon_Ec2
Zend_Service_Amazon_Ec2: Instances
Zend_Service_Amazon_Ec2: Windows Instances
Zend_Service_Amazon_Ec2: Reserved Instances
Zend_Service_Amazon_Ec2: CloudWatch Monitoring
Zend_Service_Amazon_Ec2: Amazon Machine Images (AMI)
Zend_Service_Amazon_Ec2: Elastic Block Stroage (EBS)
Zend_Service_Amazon_Ec2: Elastic IP Addresses
Zend_Service_Amazon_Ec2: Keypairs
Zend_Service_Amazon_Ec2: Regions and Availability Zones
Zend_Service_Amazon_Ec2: Security Groups
Zend_Service_Amazon_S3
Zend_Service_Audioscrobbler
Zend_Service_Delicious
Zend_Service_Flickr
Zend_Service_Nirvanix
Zend_Service_ReCaptcha
Zend_Service_Simpy
Introduction
Zend_Service_StrikeIron
Zend_Service_StrikeIron: Bundled Services
Zend_Service_StrikeIron: Advanced Uses
Zend_Service_Technorati
Zend_Service_Twitter
Zend_Service_Yahoo
Zend_Session
Introduction
Basic Usage
Advanced Usage
Global Session Management
Zend_Session_SaveHandler_DbTable
Zend_Soap
Zend_Soap_Server
Zend_Soap_Client
WSDL Accessor
AutoDiscovery
Zend_Tag
Introduction
Zend_Tag_Cloud
Zend_Test
Introduction
Zend_Test_PHPUnit
Zend_Text
Zend_Text_Figlet
Zend_Text_Table
Zend_TimeSync
Introduction
Working with Zend_TimeSync
Zend_Tool_Framework
Introduction
Using the CLI Tool
Architecture
Creating Providers to use with Zend_Tool_Framework
Shipped System Providers
Zend_Tool_Project
Zend_Tool_Project Introduction
Create A Project
Zend Tool Project Providers
Zend_Translate
Introduction
Adapters for Zend_Translate
Using Translation Adapters
Migrating from previous versions
Zend_Uri
Zend_Uri
Zend_Validate
Introduction
Standard Validation Classes
Validator Chains
Writing Validators
Validation Messages
Zend_Version
Getting the Zend Framework Version
Zend_View
Introduction
Controller Scripts
View Scripts
View Helpers
Zend_View_Abstract
Migrating from Previous Versions
Zend_Wildfire
Zend_Wildfire
Zend_XmlRpc
Introduction
Zend_XmlRpc_Client
Zend_XmlRpc_Server
Zend Framework Requirements
Introduction
Zend Framework Coding Standard for PHP
Overview
PHP File Formatting
Naming Conventions
Coding Style
Zend Framework Performance Guide
Introduction
Class Loading
Zend_Db Performance
Internationalization (i18n) and Localization (l10n)
View Rendering
Copyright Information