|
|
@@ -1,38 +1,38 @@
|
|
|
-<?xml version="1.0" encoding="UTF-8"?>
|
|
|
-<!-- EN-Revision: 15617 -->
|
|
|
+<?xml version="1.0" encoding="utf-8"?>
|
|
|
+<!-- EN-Revision: 16169 -->
|
|
|
<!-- Reviewed: no -->
|
|
|
<sect1 id="zend.application.theory-of-operation">
|
|
|
<title>Théorie générale</title>
|
|
|
|
|
|
<para>
|
|
|
- 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...
|
|
|
+ Monter une application <acronym>MVC</acronym> 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...
|
|
|
</para>
|
|
|
|
|
|
<para>
|
|
|
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.
|
|
|
+ pas besoin de <acronym>MVC</acronym> 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.
|
|
|
</para>
|
|
|
|
|
|
<para>
|
|
|
<classname>Zend_Application</classname> 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.
|
|
|
+ en concepts orientés objet (<acronym>OO</acronym>).
|
|
|
</para>
|
|
|
|
|
|
- <para>Zend_Application se décompose en 3 parties :</para>
|
|
|
+ <para><classname>Zend_Application</classname> se décompose en 3 parties :</para>
|
|
|
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>
|
|
|
- <classname>Zend_Application</classname> charge l'environnement PHP, à savoir
|
|
|
- les include_paths et les autoloads, et instancie la classe de bootstrap
|
|
|
- demandée.
|
|
|
+ <classname>Zend_Application</classname> charge l'environnement
|
|
|
+ <acronym>PHP</acronym>, à savoir les include_paths et les autoloads, et instancie
|
|
|
+ la classe de bootstrap demandée.
|
|
|
</para>
|
|
|
</listitem>
|
|
|
|
|
|
@@ -59,8 +59,8 @@
|
|
|
Les développeurs créent une classe de bootstrap pour leur application en étendant
|
|
|
<classname>Zend_Application_Bootstrap_Bootstrap</classname> ou en implémentant (au minimum)
|
|
|
<classname>Zend_Application_Bootstrap_Bootstrapper</classname>. Le point d'entrée
|
|
|
- (public/index.php) chargera <classname>Zend_Application</classname> en l'instanciant et en
|
|
|
- lui passant :
|
|
|
+ (<filename>public/index.php</filename>) chargera <classname>Zend_Application</classname>
|
|
|
+ en l'instanciant et en lui passant :
|
|
|
</para>
|
|
|
|
|
|
<itemizedlist>
|
|
|
@@ -88,7 +88,7 @@
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
- <para>Des paramètres php.ini à initialiser</para>
|
|
|
+ <para>Des paramètres <filename>php.ini</filename> à initialiser</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
@@ -96,7 +96,7 @@
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
- <para>Des paires prefix/chemin pour les ressources à utiliser</para>
|
|
|
+ <para>Des paires préfixe / chemin pour les ressources à utiliser</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
@@ -124,7 +124,7 @@
|
|
|
<classname>Zend_Application</classname>'s second area of responsibility is
|
|
|
executing the application bootstrap. Bootstraps minimally need to
|
|
|
implement <classname>Zend_Application_Bootstrap_Bootstrapper</classname>,
|
|
|
- which defines the following API:
|
|
|
+ which defines the following <acronym>API</acronym>:
|
|
|
</para>
|
|
|
|
|
|
<programlisting language="php"><![CDATA[
|
|
|
@@ -142,7 +142,7 @@ interface Zend_Application_Bootstrap_Bootstrapper
|
|
|
]]></programlisting>
|
|
|
|
|
|
<para>
|
|
|
- This API allows the bootstrap to accept the environment and
|
|
|
+ This <acronym>API</acronym> 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.
|
|
|
@@ -166,15 +166,15 @@ interface Zend_Application_Bootstrap_Bootstrapper
|
|
|
The <classname>Zend_Application_Bootstrap_BootstrapAbstract</classname>
|
|
|
implementation provides a simple convention for defining class
|
|
|
resource methods. Any protected method beginning with a name
|
|
|
- prefixed with <code>_init</code> will be considered a resource
|
|
|
+ prefixed with <emphasis>_init</emphasis> will be considered a resource
|
|
|
method.
|
|
|
</para>
|
|
|
|
|
|
<para>
|
|
|
To bootstrap a single resource method, use the
|
|
|
- <code>bootstrap()</code> method, and pass it the name of the
|
|
|
+ <methodname>bootstrap()</methodname> method, and pass it the name of the
|
|
|
resource. The name will be the method name minus the
|
|
|
- <code>_init</code> prefix.
|
|
|
+ <emphasis>_init</emphasis> prefix.
|
|
|
</para>
|
|
|
|
|
|
<para>
|
|
|
@@ -207,7 +207,7 @@ class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
|
|
|
]]></programlisting>
|
|
|
|
|
|
<para>
|
|
|
- To bootstrap just the <code>_initFoo()</code> method, do the
|
|
|
+ To bootstrap just the <methodname>_initFoo()</methodname> method, do the
|
|
|
following:
|
|
|
</para>
|
|
|
|
|
|
@@ -216,16 +216,16 @@ $bootstrap->bootstrap('foo');
|
|
|
]]></programlisting>
|
|
|
|
|
|
<para>
|
|
|
- To bootstrap the <code>_initFoo()</code> and
|
|
|
- <code>_initBar()</code> methods, do the following:
|
|
|
+ To bootstrap the <methodname>_initFoo()</methodname> and
|
|
|
+ <methodname>_initBar()</methodname> methods, do the following:
|
|
|
</para>
|
|
|
|
|
|
<programlisting language="php"><![CDATA[
|
|
|
-$bootstrap->bootstrap(array('foo', 'bar));
|
|
|
+$bootstrap->bootstrap(array('foo', 'bar'));
|
|
|
]]></programlisting>
|
|
|
|
|
|
<para>
|
|
|
- To bootstrap all resource methods, call <code>bootstrap()</code>
|
|
|
+ To bootstrap all resource methods, call <methodname>bootstrap()</methodname>
|
|
|
with no arguments:
|
|
|
</para>
|
|
|
|
|
|
@@ -251,7 +251,7 @@ $bootstrap->bootstrap();
|
|
|
If your bootstrap should be capable of using resource plugins,
|
|
|
you will need to implement an additional interface,
|
|
|
<classname>Zend_Application_Bootstrap_ResourceBootstrapper</classname>.
|
|
|
- This interface defines an API for locating, registering, and
|
|
|
+ This interface defines an <acronym>API</acronym> for locating, registering, and
|
|
|
loading resource plugins:
|
|
|
</para>
|
|
|
|
|
|
@@ -288,12 +288,12 @@ interface Zend_Application_Bootstrap_ResourceBootstrapper
|
|
|
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/options pairs, with the key
|
|
|
+ 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,
|
|
|
+ "<classname>Zend_Application_Resource_</classname>"; anything following this would
|
|
|
+ be the name of the resource. As an example,
|
|
|
</para>
|
|
|
|
|
|
<programlisting language="php"><![CDATA[
|
|
|
@@ -321,8 +321,8 @@ $application = new Zend_Application(APPLICATION_ENV, array(
|
|
|
|
|
|
<para>
|
|
|
As an example, let's assume you have custom resource plugins in
|
|
|
- <code>APPLICATION_PATH/resources/</code> and that they share the
|
|
|
- common class prefix of <code>My_Resource</code>. You would then
|
|
|
+ <filename>APPLICATION_PATH/resources/</filename> and that they share the
|
|
|
+ common class prefix of <classname>My_Resource</classname>. You would then
|
|
|
pass that information to the application object as follows:
|
|
|
</para>
|
|
|
|
|
|
@@ -344,7 +344,7 @@ $application = new Zend_Application(APPLICATION_ENV, array(
|
|
|
</para>
|
|
|
|
|
|
<para>
|
|
|
- Just like resource methods, you use the <code>bootstrap()</code>
|
|
|
+ Just like resource methods, you use the <methodname>bootstrap()</methodname>
|
|
|
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,
|
|
|
@@ -384,11 +384,11 @@ $bootstrap->bootstrap();
|
|
|
object. Resources are then registered as properties named after
|
|
|
the resource name. By default, an instance of
|
|
|
<classname>Zend_Registry</classname> is used, but you may also specify any
|
|
|
- other object you wish. The methods <code>setContainer()</code>
|
|
|
- and <code>getContainer()</code> may be used to manipulate the
|
|
|
- container itself. <code>getResource($resource)</code> can be
|
|
|
+ other object you wish. The methods <methodname>setContainer()</methodname>
|
|
|
+ and <methodname>getContainer()</methodname> may be used to manipulate the
|
|
|
+ container itself. <methodname>getResource($resource)</methodname> can be
|
|
|
used to fetch a given resource from the container, and
|
|
|
- <code>hasResource($resource)</code> to check if the resource has
|
|
|
+ <methodname>hasResource($resource)</methodname> to check if the resource has
|
|
|
actually been registered.
|
|
|
</para>
|
|
|
|
|
|
@@ -427,11 +427,11 @@ if (isset($container->view)) {
|
|
|
]]></programlisting>
|
|
|
|
|
|
<para>
|
|
|
- Please note that the registry/container is not global. This
|
|
|
+ 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. <classname>Zend_Application_Bootstrap_Bootstrap</classname>
|
|
|
provides some convenience for this: during its
|
|
|
- <code>run()</code> execution, it registers itself as the front
|
|
|
+ <methodname>run()</methodname> execution, it registers itself as the front
|
|
|
controller parameter "bootstrap", which allows you to fetch it
|
|
|
from the router, dispatcher, plugins, and action controllers.
|
|
|
</para>
|
|
|
@@ -474,15 +474,15 @@ class FooController extends Zend_Controller_Action
|
|
|
|
|
|
<para>
|
|
|
As noted previously, all resources -- whether methods or plugins
|
|
|
- -- are bootstrapped by calling <code>bootstrap($resource)</code>,
|
|
|
- where <code>$resource</code> is the name of a resource, an array
|
|
|
+ -- are bootstrapped by calling <methodname>bootstrap($resource)</methodname>,
|
|
|
+ where <varname>$resource</varname> is the name of a resource, an array
|
|
|
of resources, or, left empty, indicates all resources should be
|
|
|
run.
|
|
|
</para>
|
|
|
|
|
|
<para>
|
|
|
If a resource depends on another resource, it should call
|
|
|
- <code>bootstrap()</code> within its code to ensure that resource
|
|
|
+ <methodname>bootstrap()</methodname> within its code to ensure that resource
|
|
|
has been executed. Subsequent calls to it will then be ignored.
|
|
|
</para>
|
|
|
|
|
|
@@ -517,10 +517,10 @@ class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
|
|
|
<title>Resource Plugins</title>
|
|
|
|
|
|
<para>
|
|
|
- <link linkend="zend.application.theory-of-operation.bootstrap.resource-plugins">As
|
|
|
- noted previously</link>,
|
|
|
- a good way to create re-usable bootstrap resources and to offload
|
|
|
- much of your coding to discrete classes is to utilize resource
|
|
|
+ <link
|
|
|
+ linkend="zend.application.theory-of-operation.bootstrap.resource-plugins">As noted
|
|
|
+ previously</link>, 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.
|
|
|
@@ -557,7 +557,7 @@ interface Zend_Application_Resource_Resource
|
|
|
|
|
|
<para>
|
|
|
As an example, let's assume you have a common view intialization you
|
|
|
- use in your applications. You have a common doctype, CSS and
|
|
|
+ use in your applications. You have a common doctype, <acronym>CSS</acronym> and
|
|
|
JavaScript, and you want to be able to pass in a base document title
|
|
|
via configuration. Such a resource might look like this:
|
|
|
</para>
|
|
|
@@ -591,7 +591,7 @@ class My_Resource_View extends Zend_Application_Resource_ResourceAbstract
|
|
|
|
|
|
$viewRenderer =
|
|
|
Zend_Controller_Action_HelperBroker::getStaticHelper(
|
|
|
- 'ViewRenderer',
|
|
|
+ 'ViewRenderer'
|
|
|
);
|
|
|
$viewRenderer->setView($view);
|
|
|
|
|
|
@@ -609,4 +609,4 @@ class My_Resource_View extends Zend_Application_Resource_ResourceAbstract
|
|
|
"View" resource plugin, ensuring that your own is used instead.
|
|
|
</para>
|
|
|
</sect2>
|
|
|
-</sect1>
|
|
|
+</sect1>
|
mikaelkael