Введение в Zend Framework

 Learning Zend Framework


 Zend Framework Reference

  • Zend_Gdata
  • Zend_Http
  • Zend_InfoCard
  • Zend_Json
  • Zend_Layout
  • Zend_Ldap
  • Zend_Loader
  • Zend_Locale
  • Zend_Log
  • Zend_Mail
  • Zend_Markup
  • Zend_Measure
  • Zend_Memory
  • Zend_Mime
  • Zend_Navigation
  • Zend_Oauth
  • Zend_OpenId
  • Zend_Paginator
  • Zend_Pdf
  • Zend_ProgressBar
  • Zend_Queue
  • Zend_Reflection
  • Zend_Registry
  • Zend_Rest

  • Zend_Search_Lucene
  • Zend_Serializer
  • Zend_Server
  • Zend_Service
  • Zend_Session
  • Zend_Soap
  • Zend_Tag
  • Zend_Test
  • Zend_Text
  • Zend_TimeSync
  • Zend_Tool
  • Zend_Tool_Framework
  • Zend_Tool_Project
  • Zend_Translate
  • Zend_Uri
  • Zend_Validate
  • Zend_Version
  • Zend_View
  • Zend_Wildfire
  • Zend_XmlRpc
  • ZendX_Console_Process_Unix
  • ZendX_JQuery
  • Ttranslation 27.4% Update 2010-11-28 - Revision 23238 - Version ZF 1.11.x

    14.4. Examples

    The Bootstrap class itself will typically be fairly minimal; often, it will simply be an empty stub extending the base bootstrap class:

    class Bootstrap extends Zend_Application_Bootstrap_Bootstrap

    With a corresponding configuration file:

    autoloaderNamespaces[] = "My_"
    bootstrap.path APPLICATION_PATH "/Bootstrap.php"
    bootstrap.class = "Bootstrap"
    pluginpaths.My_Bootstrap_Resource "My/Bootstrap/Resource"
    resources.frontController.controllerDirectory APPLICATION_PATH "/controllers"

    [testing production]
    development production]
    [Замечание] Autoloader namespaces

    Because these examples use custom code, we need to register the namespace prefixes for that code with our configuration; this is done with the autoloaderNamespaces configuration key, which is an array.

    Additionally, to ensure that custom plugin resources are discovered, we need to register a plugin prefix path with the bootstrap. This is done with the pluginpaths configuration key, which is an associative array, with keys denoting the prefix to use, and values denoting the path related to that prefix.

    However, should custom initialization be necessary, you have two choices. First, you can write methods prefixed with _init to specify discrete code to bootstrap. These methods will be called by bootstrap(), and can also be called as if they were public methods: bootstrap<resource>(). They should accept an optional array of options.

    If your resource method returns a value, it will be stored in a container in the bootstrap. This can be useful when different resources need to interact (such as one resource injecting itself into another). The method getResource() can then be used to retrieve those values.

    The example below shows a resource method for initializing the request object. It makes use of dependency tracking (it depends on the front controller resource), fetching a resource from the bootstrap, and returning a value to store in the bootstrap.

    class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
        protected function 
    // Ensure front controller instance is present, and fetch it
    $front $this->getResource('FrontController');

    // Initialize the request object
    $request = new Zend_Controller_Request_Http();

    // Add it to the front controller

    // Bootstrap will store this value in the 'request' key of its container
    return $request;

    Note in this example the call to bootstrap(); this ensures that the front controller has been initialized prior to calling this method. That call may trigger either a resource or another method in the class.

    The other option is to use resource plugins. Resource plugins are objects that perform specific initializations, and may be specified:

    • When instantiating the Zend_Application object

    • During initialization of the bootstrap object

    • By explicitly enabling them via method calls to the bootstrap object

    Resource plugins implement Zend_Application_Resource_ResourceAbstract, which defines simply that they allow injection of the caller and options, and that they have an init() method. As an example, a custom "View" bootstrap resource might look like the following:

    class My_Bootstrap_Resource_View
    extends Zend_Application_Resource_ResourceAbstract
        public function 
    $view = new Zend_View($this->getOptions());

    $view->headTitle()->setSeparator(' - ')->append('My Site');
    'text/html; charset=utf-8');


    $viewRenderer Zend_Controller_Action_HelperBroker::getStaticHelper(


    To tell the bootstrap to use this, you would need to provide either the class name of the resource plugin, or a combination of a plugin loader prefix path and the short name of the resource plugin (e.g, "view"):

    $application = new Zend_Application(
    'resources' => array(
    'My_Bootstrap_Resource_View' => array(), // full class name; OR
    'view' => array(),                       // short name

    'FrontController' => array(
    'controllerDirectory' => APPLICATION_PATH '/controllers',

    // For short names, define plugin paths:
    'pluginPaths = array(
    My_Bootstrap_Resource' => 'My/Bootstrap/Resource',

    Resource plugins can call on other resources and initializers by accessing the parent bootstrap:

    class My_Bootstrap_Resource_Layout
    extends Zend_Application_Resource_ResourceAbstract
        public function 
    // ensure view is initialized...

    // Get view object:
    $view $this->getBootstrap()->getResource('view');

    // ...

    In normal usage, you would instantiate the application, bootstrap it, and run it:

    $application = new Zend_Application(...);

    For a custom script, you might need to simply initialize specific resources:

    $application = new Zend_Application(...);

    $service = new Zend_XmlRpc_Server();
    $service->setClass('Foo');  // uses database...
    echo $service->handle();

    Instead of using the bootstrap() method to call the internal methods or resources, you may also use overloading:

    $application = new Zend_Application(...);
    digg delicious meneame google twitter technorati facebook