Examples
The Bootstrap class itself will typically be fairly minimal; often,
it will simply be an empty stub extending the base bootstrap class:
With a corresponding configuration file:
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.
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;
}
}
]]>
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_Bootstrap_Resource,
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:
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;
}
}
]]>
To tell the bootstrap to use this, you would need to provide either the
class name of the resource, or a combination of a plugin loader prefix
path and the short name of the resource (e.g, "view"):
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',
)
)
);
]]>
Resources can call on other resources and initializers by accessing the
parent bootstrap:
getBootstrap()->bootstrap('view');
// Get view object:
$view = $this->getBootstrap()->getResource('view');
// ...
}
}
]]>
In normal usage, you would instantiate the application, bootstrap it,
and run it:
bootstrap()
->run();
]]>
For a custom script, you might need to simply initialize specific
resources:
getBootstrap()->bootstrap('db');
$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:
getBootstrap()->bootstrapDb();
]]>