Zend_Application-TheoryOfOperation.xml 23 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612
  1. <?xml version="1.0" encoding="utf-8"?>
  2. <!-- EN-Revision: 24249 -->
  3. <!-- Reviewed: no -->
  4. <sect1 id="zend.application.theory-of-operation">
  5. <title>Théorie générale</title>
  6. <para>
  7. Monter une application <acronym>MVC</acronym> configurée et prête à être lancée requière de
  8. plus en plus de code au fur et à mesure de l'ajout de fonctionnalités&#160;: monter une base
  9. de données, configurer la vue et ses aides, les layouts, enregistrer des plugins, des aides
  10. d'action et bien plus encore...
  11. </para>
  12. <para>
  13. Aussi, vous réutiliserez souvent le même code dans vos tests, dans une tâche cron ou
  14. encore un service. Il est certes possible d'inclure le script de bootstrap dans de tels cas,
  15. mais souvent des variables seront dépendantes de l'environnement. Par exemple, vous n'aurez
  16. pas besoin de <acronym>MVC</acronym> dans une tâche cron, ou alors vous aurez juste besoin
  17. de l'accès à la base de données dans un script de service.
  18. </para>
  19. <para>
  20. <classname>Zend_Application</classname> a pour but de simplifier ces processus et de
  21. promouvoir la réutilisabilité de code en encapsulant les étages de définition du bootstrap
  22. en concepts orientés objet (<acronym>OO</acronym>).
  23. </para>
  24. <para><classname>Zend_Application</classname> se décompose en 3 parties&#160;:</para>
  25. <itemizedlist>
  26. <listitem>
  27. <para>
  28. <classname>Zend_Application</classname> charge l'environnement
  29. <acronym>PHP</acronym>, à savoir les include_paths et les autoloads, et instancie
  30. la classe de bootstrap demandée.
  31. </para>
  32. </listitem>
  33. <listitem>
  34. <para>
  35. <classname>Zend_Application_Bootstrap</classname> regroupe les interfaces pour les
  36. classes de bootstrap. <classname>Zend_Application_Bootstrap_Bootstrap</classname>
  37. propose des fonctionnalités de base concernant l'amorçage (le bootstrap), à savoir
  38. des algorithmes de vérification des dépendances et la possibilité de charger des
  39. ressources à la demande.
  40. </para>
  41. </listitem>
  42. <listitem>
  43. <para>
  44. <classname>Zend_Application_Resource</classname> est une interface pour les
  45. ressources de bootstrap qui peuvent être chargées à la demande depuis les instances
  46. de bootstrap.
  47. </para>
  48. </listitem>
  49. </itemizedlist>
  50. <para>
  51. Les développeurs créent une classe de bootstrap pour leur application en étendant
  52. <classname>Zend_Application_Bootstrap_Bootstrap</classname> ou en implémentant (au minimum)
  53. <classname>Zend_Application_Bootstrap_Bootstrapper</classname>. Le point d'entrée
  54. (<filename>public/index.php</filename>) chargera <classname>Zend_Application</classname>
  55. en l'instanciant et en lui passant&#160;:
  56. </para>
  57. <itemizedlist>
  58. <listitem>
  59. <para>L'environnement courant</para>
  60. </listitem>
  61. <listitem>
  62. <para>Des options de bootstrapping</para>
  63. </listitem>
  64. </itemizedlist>
  65. <para>
  66. Les options de bootstrap incluent le chemin vers le fichier contenant la classe de
  67. bootstrap, et optionnellement&#160;:
  68. </para>
  69. <itemizedlist>
  70. <listitem>
  71. <para>Des include_paths supplémentaires</para>
  72. </listitem>
  73. <listitem>
  74. <para>Des espaces de nom d'autoload à enregistrer</para>
  75. </listitem>
  76. <listitem>
  77. <para>Des paramètres <filename>php.ini</filename> à initialiser</para>
  78. </listitem>
  79. <listitem>
  80. <para>Le nom de la classe pour le bootstrap (sinon "Bootstrap" sera utilisée)</para>
  81. </listitem>
  82. <listitem>
  83. <para>Des paires préfixe&#160;/&#160;chemin pour les ressources à utiliser</para>
  84. </listitem>
  85. <listitem>
  86. <para>N'importe quelle ressource à utiliser (nom de classe ou nom court)</para>
  87. </listitem>
  88. <listitem>
  89. <para>Des chemins additionnels vers un fichier de configuration à charger</para>
  90. </listitem>
  91. <listitem>
  92. <para>Des options de configuration supplémentaires</para>
  93. </listitem>
  94. </itemizedlist>
  95. <para>
  96. Les options peuvent être un tableau, un objet <classname>Zend_Config</classname>, ou
  97. le chemin vers un fichier de configuration.
  98. </para>
  99. <sect2 id="zend.application.theory-of-operation.bootstrap">
  100. <title>Bootstrapping</title>
  101. <para>
  102. <classname>Zend_Application</classname>'s second area of responsibility is
  103. executing the application bootstrap. Bootstraps minimally need to
  104. implement <classname>Zend_Application_Bootstrap_Bootstrapper</classname>,
  105. which defines the following <acronym>API</acronym>:
  106. </para>
  107. <programlisting language="php"><![CDATA[
  108. interface Zend_Application_Bootstrap_Bootstrapper
  109. {
  110. public function __construct($application);
  111. public function setOptions(array $options);
  112. public function getApplication();
  113. public function getEnvironment();
  114. public function getClassResources();
  115. public function getClassResourceNames();
  116. public function bootstrap($resource = null);
  117. public function run();
  118. }
  119. ]]></programlisting>
  120. <para>
  121. This <acronym>API</acronym> allows the bootstrap to accept the environment and
  122. configuration from the application object, report the resources its
  123. responsible for bootstrapping, and then bootstrap and run the
  124. application.
  125. </para>
  126. <para>
  127. You can implement this interface on your own, extend
  128. <classname>Zend_Application_Bootstrap_BootstrapAbstract</classname>, or use
  129. <classname>Zend_Application_Bootstrap_Bootstrap</classname>.
  130. </para>
  131. <para>
  132. Besides this functionality, there are a number of other areas of
  133. concern you should familiarize yourself with.
  134. </para>
  135. <sect3 id="zend.application.theory-of-operation.bootstrap.resource-methods">
  136. <title>Resource Methods</title>
  137. <para>
  138. The <classname>Zend_Application_Bootstrap_BootstrapAbstract</classname>
  139. implementation provides a simple convention for defining class
  140. resource methods. Any protected method beginning with a name
  141. prefixed with <emphasis>_init</emphasis> will be considered a resource
  142. method.
  143. </para>
  144. <para>
  145. To bootstrap a single resource method, use the
  146. <methodname>bootstrap()</methodname> method, and pass it the name of the
  147. resource. The name will be the method name minus the
  148. <emphasis>_init</emphasis> prefix.
  149. </para>
  150. <para>
  151. To bootstrap several resource methods, pass an array of names.
  152. Too bootstrap all resource methods, pass nothing.
  153. </para>
  154. <para>
  155. Take the following bootstrap class:
  156. </para>
  157. <programlisting language="php"><![CDATA[
  158. class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
  159. {
  160. protected function _initFoo()
  161. {
  162. // ...
  163. }
  164. protected function _initBar()
  165. {
  166. // ...
  167. }
  168. protected function _initBaz()
  169. {
  170. // ...
  171. }
  172. }
  173. ]]></programlisting>
  174. <para>
  175. To bootstrap just the <methodname>_initFoo()</methodname> method, do the
  176. following:
  177. </para>
  178. <programlisting language="php"><![CDATA[
  179. $bootstrap->bootstrap('foo');
  180. ]]></programlisting>
  181. <para>
  182. To bootstrap the <methodname>_initFoo()</methodname> and
  183. <methodname>_initBar()</methodname> methods, do the following:
  184. </para>
  185. <programlisting language="php"><![CDATA[
  186. $bootstrap->bootstrap(array('foo', 'bar'));
  187. ]]></programlisting>
  188. <para>
  189. To bootstrap all resource methods, call <methodname>bootstrap()</methodname>
  190. with no arguments:
  191. </para>
  192. <programlisting language="php"><![CDATA[
  193. $bootstrap->bootstrap();
  194. ]]></programlisting>
  195. </sect3>
  196. <sect3 id="zend.application.theory-of-operation.bootstrap.resource-plugins">
  197. <title>Bootstraps that use resource plugins</title>
  198. <para>
  199. To make your bootstraps more re-usable, we have provided the
  200. ability to push your resources into resource plugin classes.
  201. This allows you to mix and match resources simply via
  202. configuration. We will cover <link
  203. linkend="zend.application.theory-of-operation.resources">how
  204. to create resources</link> later; in
  205. this section we will show you how to utilize them only.
  206. </para>
  207. <para>
  208. If your bootstrap should be capable of using resource plugins,
  209. you will need to implement an additional interface,
  210. <classname>Zend_Application_Bootstrap_ResourceBootstrapper</classname>.
  211. This interface defines an <acronym>API</acronym> for locating, registering, and
  212. loading resource plugins:
  213. </para>
  214. <programlisting language="php"><![CDATA[
  215. interface Zend_Application_Bootstrap_ResourceBootstrapper
  216. {
  217. public function registerPluginResource($resource, $options = null);
  218. public function unregisterPluginResource($resource);
  219. public function hasPluginResource($resource);
  220. public function getPluginResource($resource);
  221. public function getPluginResources();
  222. public function getPluginResourceNames();
  223. public function setPluginLoader(Zend_Loader_PluginLoader_Interface $loader);
  224. public function getPluginLoader();
  225. }
  226. ]]></programlisting>
  227. <para>
  228. Resource plugins basically provide the ability to create
  229. resource intializers that can be re-used between applications.
  230. This allows you to keep your actual bootstrap relatively clean,
  231. and to introduce new resources without needing to touch your
  232. bootstrap itself.
  233. </para>
  234. <para>
  235. <classname>Zend_Application_Bootstrap_BootstrapAbstract</classname> (and
  236. <classname>Zend_Application_Bootstrap_Bootstrap</classname> by extension)
  237. implement this interface as well, allowing you to utilize
  238. resource plugins.
  239. </para>
  240. <para>
  241. To utilize resource plugins, you must specify them in the
  242. options passed to the application object and/or bootstrap. These
  243. options may come from a configuration file, or be passed in
  244. manually. Options will be of key to options pairs, with the key
  245. representing the resource name. The resource name will be the
  246. segment following the class prefix. For example, the resources
  247. shipped with Zend Framework have the class prefix
  248. "<classname>Zend_Application_Resource_</classname>"; anything following this would
  249. be the name of the resource. As an example,
  250. </para>
  251. <programlisting language="php"><![CDATA[
  252. $application = new Zend_Application(APPLICATION_ENV, array(
  253. 'resources' => array(
  254. 'FrontController' => array(
  255. 'controllerDirectory' => APPLICATION_PATH . '/controllers',
  256. ),
  257. ),
  258. ));
  259. ]]></programlisting>
  260. <para>
  261. This indicates that the "FrontController" resource should be
  262. used, with the options specified.
  263. </para>
  264. <para>
  265. If you begin writing your own resource plugins, or utilize
  266. third-party resource plugins, you will need to tell your
  267. bootstrap where to look for them. Internally, the bootstrap
  268. utilizes <classname>Zend_Loader_PluginLoader</classname>, so you will only
  269. need to indicate the common class prefix an path pairs.
  270. </para>
  271. <para>
  272. As an example, let's assume you have custom resource plugins in
  273. <filename>APPLICATION_PATH/resources/</filename> and that they share the
  274. common class prefix of <classname>My_Resource</classname>. You would then
  275. pass that information to the application object as follows:
  276. </para>
  277. <programlisting language="php"><![CDATA[
  278. $application = new Zend_Application(APPLICATION_ENV, array(
  279. 'pluginPaths' => array(
  280. 'My_Resource' => APPLICATION_PATH . '/resources/',
  281. ),
  282. 'resources' => array(
  283. 'FrontController' => array(
  284. 'controllerDirectory' => APPLICATION_PATH . '/controllers',
  285. ),
  286. ),
  287. ));
  288. ]]></programlisting>
  289. <para>
  290. You would now be able to use resources from that directory.
  291. </para>
  292. <para>
  293. Just like resource methods, you use the <methodname>bootstrap()</methodname>
  294. method to execute resource plugins. Just like with resource
  295. methods, you can specify either a single resource plugin,
  296. multiple plugins (via an array), or all plugins. Additionally,
  297. you can mix and match to execute resource methods as well.
  298. </para>
  299. <programlisting language="php"><![CDATA[
  300. // Execute one:
  301. $bootstrap->bootstrap('FrontController');
  302. // Execute several:
  303. $bootstrap->bootstrap(array('FrontController', 'Foo'));
  304. // Execute all resource methods and plugins:
  305. $bootstrap->bootstrap();
  306. ]]></programlisting>
  307. </sect3>
  308. <sect3 id="zend.application.theory-of-operation.bootstrap.registry">
  309. <title>Resource Registry</title>
  310. <para>
  311. Many, if not all, of your resource methods or plugins will
  312. initialize objects, and in many cases, these objects will be
  313. needed elsewhere in your application. How can you access them?
  314. </para>
  315. <para>
  316. <classname>Zend_Application_Bootstrap_BootstrapAbstract</classname>
  317. provides a local registry for these objects. To store your
  318. objects in them, you simply return them from your resources.
  319. </para>
  320. <para>
  321. For maximum flexibility, this registry is referred to as a
  322. "container" internally; its only requirements are that it is an
  323. object. Resources are then registered as properties named after
  324. the resource name. By default, an instance of
  325. <classname>Zend_Registry</classname> is used, but you may also specify any
  326. other object you wish. The methods <methodname>setContainer()</methodname>
  327. and <methodname>getContainer()</methodname> may be used to manipulate the
  328. container itself. <methodname>getResource($resource)</methodname> can be
  329. used to fetch a given resource from the container, and
  330. <methodname>hasResource($resource)</methodname> to check if the resource has
  331. actually been registered.
  332. </para>
  333. <para>
  334. As an example, consider a basic view resource:
  335. </para>
  336. <programlisting language="php"><![CDATA[
  337. class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
  338. {
  339. protected function _initView()
  340. {
  341. $view = new Zend_View();
  342. // more initialization...
  343. return $view;
  344. }
  345. }
  346. ]]></programlisting>
  347. <para>
  348. You can then check for it and/or fetch it as follows:
  349. </para>
  350. <programlisting language="php"><![CDATA[
  351. // Using the has/getResource() pair:
  352. if ($bootstrap->hasResource('view')) {
  353. $view = $bootstrap->getResource('view');
  354. }
  355. // Via the container:
  356. $container = $bootstrap->getContainer();
  357. if (isset($container->view)) {
  358. $view = $container->view;
  359. }
  360. ]]></programlisting>
  361. <para>
  362. Please note that the registry and also the container is not global. This
  363. means that you need access to the bootstrap in order to fetch
  364. resources. <classname>Zend_Application_Bootstrap_Bootstrap</classname>
  365. provides some convenience for this: during its
  366. <methodname>run()</methodname> execution, it registers itself as the front
  367. controller parameter "bootstrap", which allows you to fetch it
  368. from the router, dispatcher, plugins, and action controllers.
  369. </para>
  370. <para>
  371. As an example, if you wanted access to the view resource from
  372. above within your action controller, you could do the following:
  373. </para>
  374. <programlisting language="php"><![CDATA[
  375. class FooController extends Zend_Controller_Action
  376. {
  377. public function init()
  378. {
  379. $bootstrap = $this->getInvokeArg('bootstrap');
  380. $view = $bootstrap->getResource('view');
  381. // ...
  382. }
  383. }
  384. ]]></programlisting>
  385. </sect3>
  386. <sect3 id="zend.application.theory-of-operation.bootstrap.dependency-tracking">
  387. <title>Dependency Tracking</title>
  388. <para>
  389. In addition to executing resource methods and plugins, it's
  390. necessary to ensure that these are executed once and once
  391. only; these are meant to bootstrap an application, and
  392. executing multiple times can lead to resource overhead.
  393. </para>
  394. <para>
  395. At the same time, some resources may depend on other
  396. resources being executed. To solve these two issues,
  397. <classname>Zend_Application_Bootstrap_BootstrapAbstract</classname>
  398. provides a simple, effective mechanism for dependency
  399. tracking.
  400. </para>
  401. <para>
  402. As noted previously, all resources -- whether methods or plugins
  403. -- are bootstrapped by calling <methodname>bootstrap($resource)</methodname>,
  404. where <varname>$resource</varname> is the name of a resource, an array
  405. of resources, or, left empty, indicates all resources should be
  406. run.
  407. </para>
  408. <para>
  409. If a resource depends on another resource, it should call
  410. <methodname>bootstrap()</methodname> within its code to ensure that resource
  411. has been executed. Subsequent calls to it will then be ignored.
  412. </para>
  413. <para>
  414. In a resource method, such a call would look like this:
  415. </para>
  416. <programlisting language="php"><![CDATA[
  417. class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
  418. {
  419. protected function _initRequest()
  420. {
  421. // Ensure the front controller is initialized
  422. $this->bootstrap('FrontController');
  423. // Retrieve the front controller from the bootstrap registry
  424. $front = $this->getResource('FrontController');
  425. $request = new Zend_Controller_Request_Http();
  426. $request->setBaseUrl('/foo');
  427. $front->setRequest($request);
  428. // Ensure the request is stored in the bootstrap registry
  429. return $request;
  430. }
  431. }
  432. ]]></programlisting>
  433. </sect3>
  434. </sect2>
  435. <sect2 id="zend.application.theory-of-operation.resources">
  436. <title>Resource Plugins</title>
  437. <para>
  438. <link
  439. linkend="zend.application.theory-of-operation.bootstrap.resource-plugins">As noted
  440. previously</link>, a good way to create re-usable bootstrap resources and to
  441. offload much of your coding to discrete classes is to utilize resource
  442. plugins. While Zend Framework ships with a number of standard
  443. resource plugins, the intention is that developers should write
  444. their own to encapsulate their own initialization needs.
  445. </para>
  446. <para>
  447. Resources plugins need only implement
  448. <classname>Zend_Application_Resource_Resource</classname>, or, more simply
  449. still, extend
  450. <classname>Zend_Application_Resource_ResourceAbstract</classname>. The basic
  451. interface is simply this:
  452. </para>
  453. <programlisting language="php"><![CDATA[
  454. interface Zend_Application_Resource_Resource
  455. {
  456. public function __construct($options = null);
  457. public function setBootstrap(
  458. Zend_Application_Bootstrap_Bootstrapper $bootstrap
  459. );
  460. public function getBootstrap();
  461. public function setOptions(array $options);
  462. public function getOptions();
  463. public function init();
  464. }
  465. ]]></programlisting>
  466. <para>
  467. The interface defines simply that a resource plugin should accept options
  468. to the constructor, have mechanisms for setting and retrieving
  469. options, have mechanisms for setting and retrieving the bootstrap
  470. object, and an initialization method.
  471. </para>
  472. <para>
  473. As an example, let's assume you have a common view intialization you
  474. use in your applications. You have a common doctype, <acronym>CSS</acronym> and
  475. JavaScript, and you want to be able to pass in a base document title
  476. via configuration. Such a resource plugin might look like this:
  477. </para>
  478. <programlisting language="php"><![CDATA[
  479. class My_Resource_View extends Zend_Application_Resource_ResourceAbstract
  480. {
  481. protected $_view;
  482. public function init()
  483. {
  484. // Return view so bootstrap will store it in the registry
  485. return $this->getView();
  486. }
  487. public function getView()
  488. {
  489. if (null === $this->_view) {
  490. $options = $this->getOptions();
  491. $title = '';
  492. if (array_key_exists('title', $options)) {
  493. $title = $options['title'];
  494. unset($options['title']);
  495. }
  496. $view = new Zend_View($options);
  497. $view->doctype('XHTML1_STRICT');
  498. $view->headTitle($title);
  499. $view->headLink()->appendStylesheet('/css/site.css');
  500. $view->headScript()->appendfile('/js/analytics.js');
  501. $viewRenderer =
  502. Zend_Controller_Action_HelperBroker::getStaticHelper(
  503. 'ViewRenderer'
  504. );
  505. $viewRenderer->setView($view);
  506. $this->_view = $view;
  507. }
  508. return $this->_view;
  509. }
  510. }
  511. ]]></programlisting>
  512. <para>
  513. As long as you register the prefix path for this resource plugin,
  514. you can then use it in your application. Even better, because it
  515. uses the plugin loader, you are effectively overriding the shipped
  516. "View" resource plugin, ensuring that your own is used instead.
  517. </para>
  518. </sect2>
  519. </sect1>