Monter une application MVC configurée et prête à être lancée requière de plus en plus de code au fur et à mesure de l'ajout de fonctionnalités : monter une base de données, configurer la vue et ses aides, les layouts, enregistrer des plugins, des aides d'action et bien plus encore...
Aussi, vous réutiliserez souvent le même code dans vos tests, dans une tâche cron ou encore un service. Il est certes possible d'inclure le script de bootstrap dans de tels cas, mais souvent des variables seront dépendantes de l'environnement. Par exemple, vous n'aurez pas besoin de MVC dans une tâche cron, ou alors vous aurez juste besoin de l'accès à la base de données dans un script de service.
        Zend_Application a pour but de simplifier ces processus et de
        promouvoir la réutilisabilité de code en encapsulant les étages de définition du bootstrap
        en concepts orientés objet (OO).
    
Zend_Application se décompose en 3 parties :
- 
            
Zend_Applicationcharge l'environnement PHP, à savoir les include_paths et les autoloads, et instancie la classe de bootstrap demandée. - 
            
Zend_Application_Bootstrapregroupe les interfaces pour les classes de bootstrap.Zend_Application_Bootstrap_Bootstrappropose des fonctionnalités de base concernant l'amorçage (le bootstrap), à savoir des algorithmes de vérification des dépendances et la possibilité de charger des ressources à la demande. - 
            
Zend_Application_Resourceest une interface pour les ressources de bootstrap qui peuvent être chargées à la demande depuis les instances de bootstrap. 
        Les développeurs créent une classe de bootstrap pour leur application en étendant
        Zend_Application_Bootstrap_Bootstrap ou en implémentant (au minimum)
        Zend_Application_Bootstrap_Bootstrapper. Le point d'entrée
        (public/index.php) chargera Zend_Application
        en l'instanciant et en lui passant :
    
- 
            
L'environnement courant
 - 
            
Des options de bootstrapping
 
Les options de bootstrap incluent le chemin vers le fichier contenant la classe de bootstrap, et optionnellement :
- 
            
Des include_paths supplémentaires
 - 
            
Des espaces de nom d'autoload à enregistrer
 - 
            
Des paramètres
php.inià initialiser - 
            
Le nom de la classe pour le bootstrap (sinon "Bootstrap" sera utilisée)
 - 
            
Des paires préfixe / chemin pour les ressources à utiliser
 - 
            
N'importe quelle ressource à utiliser (nom de classe ou nom court)
 - 
            
Des chemins additionnels vers un fichier de configuration à charger
 - 
            
Des options de configuration supplémentaires
 
        Les options peuvent être un tableau, un objet Zend_Config, ou
        le chemin vers un fichier de configuration.
    
            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.
                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();
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 to 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();
        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 and also the 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');
        // ...
    }
}
        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;
    }
}
        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 plugins 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 plugin 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 plugin 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.