La clase Bootstrap en sí misma será típicamente bastante mínima; a menudo, será simplemente un stub vacío que extiende la clase base de bootstrap:
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
}
Con un archivo de configuración correspondiente:
; APPLICATION_PATH/configs/application.ini [production] 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]
![]() |
Espacios de nombres del autoloader |
|---|---|
|
Debido a que estos ejemplos usan código personalizado, necesitamos registrar los prefijos de espacio de nombres para ese código en nuestra configuración; esto se hace con la clave de configuración autoloaderNamespaces, que es un array. Además, para asegurar que los recursos de plugin personalizados se descubran, necesitamos registrar una ruta de prefijo de plugin en el bootstrap. Esto se hace con la clave de configuración pluginpaths, que es un array asociativo, con claves que denotan el prefijo a usar, y valores que denotan la ruta relacionada con ese prefijo. |
Sin embargo, si fuera necesaria una inicialización personalizada, tiene dos
opciones. Primero, puede escribir métodos con el prefijo _init
para especificar código discreto a arrancar. Estos métodos serán llamados por
bootstrap(), y también se pueden llamar como si fueran métodos públicos:
bootstrap<resource>(). Deben aceptar un
array opcional de opciones.
Si su método de recurso devuelve un valor, se almacenará en un
contenedor en el bootstrap. Esto puede ser útil cuando diferentes recursos
necesitan interactuar (como cuando un recurso se inyecta a sí mismo en otro).
El método getResource() se puede usar entonces para recuperar esos
valores.
El ejemplo a continuación muestra un método de recurso para inicializar el objeto request. Hace uso del seguimiento de dependencias (depende del recurso del front controller), obteniendo un recurso del bootstrap, y devolviendo un valor para almacenar en el bootstrap.
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
protected function _initRequest()
{
// Ensure front controller instance is present, and fetch it
$this->bootstrap('FrontController');
$front = $this->getResource('FrontController');
// Initialize the request object
$request = new Zend_Controller_Request_Http();
$request->setBaseUrl('/foo');
// Add it to the front controller
$front->setRequest($request);
// Bootstrap will store this value in the 'request' key of its container
return $request;
}
}
Observe en este ejemplo la llamada a bootstrap();
esto asegura que el front controller se haya inicializado antes de
llamar a este método. Esa llamada puede activar un recurso u otro
método en la clase.
La otra opción es usar plugins de recursos. Los plugins de recursos son objetos que realizan inicializaciones específicas, y pueden especificarse:
Al instanciar el objeto
Zend_ApplicationDurante la inicialización del objeto bootstrap
Habilitándolos explícitamente mediante llamadas a métodos del objeto bootstrap
Los plugins de recursos implementan
Zend_Application_Resource_ResourceAbstract,
que simplemente define que permiten la inyección del invocador y
opciones, y que tienen un método init(). Como
ejemplo, un recurso de bootstrap "View" personalizado podría verse como el
siguiente:
class My_Bootstrap_Resource_View
extends Zend_Application_Resource_ResourceAbstract
{
public function init()
{
$view = new Zend_View($this->getOptions());
Zend_Dojo::enableView($view);
$view->doctype('XHTML1_STRICT');
$view->headTitle()->setSeparator(' - ')->append('My Site');
$view->headMeta()->appendHttpEquiv('Content-Type',
'text/html; charset=utf-8');
$view->dojo()->setDjConfigOption('parseOnLoad', true)
->setLocalPath('/js/dojo/dojo.js')
->registerModulePath('../spindle', 'spindle')
->addStylesheetModule('spindle.themes.spindle')
->requireModule('spindle.main')
->disable();
$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper(
'ViewRenderer'
);
$viewRenderer->setView($view);
return $view;
}
}
Para indicarle al bootstrap que use esto, necesitaría proporcionar ya sea el nombre de clase del plugin de recurso, o una combinación de una ruta de prefijo del cargador de plugins y el nombre corto del plugin de recurso (por ejemplo, "view"):
$application = new Zend_Application(
APPLICATION_ENV,
array(
'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',
)
)
);
Los plugins de recursos pueden invocar otros recursos e inicializadores accediendo al bootstrap padre:
class My_Bootstrap_Resource_Layout
extends Zend_Application_Resource_ResourceAbstract
{
public function init()
{
// ensure view is initialized...
$this->getBootstrap()->bootstrap('view');
// Get view object:
$view = $this->getBootstrap()->getResource('view');
// ...
}
}
En el uso normal, instanciaría la aplicación, la arrancaría, y la ejecutaría:
$application = new Zend_Application(...);
$application->bootstrap()
->run();
Para un script personalizado, podría necesitar simplemente inicializar recursos específicos:
$application = new Zend_Application(...);
$application->getBootstrap()->bootstrap('db');
$service = new Zend_XmlRpc_Server();
$service->setClass('Foo'); // uses database...
echo $service->handle();
En lugar de usar el método bootstrap() para llamar a los
métodos internos o recursos, también puede usar sobrecarga:
$application = new Zend_Application(...); $application->getBootstrap()->bootstrapDb();
![[Note]](images/note.png)