1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246
|
<?xml version="1.0" encoding="utf-8"?>
<!-- EN-Revision: 24249 -->
<!-- Reviewed: no -->
<sect1 id="zend.application.examples">
<title>Exemples</title>
<para>
La classe de bootstrap elle-même sera typiquement minimaliste ; souvent, elle s'agira
simplement d'une extension vide de la classe de bootstrap de base :
</para>
<programlisting language="php"><![CDATA[
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
}
]]></programlisting>
<para>Avec un fichier de configuration tel que :</para>
<programlisting language="ini"><![CDATA[
; 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]
]]></programlisting>
<note>
<title>Espaces de noms de l'autoloader</title>
<para>
Comme ces exemples utilisent du code personnalisé, nous devons enregistrer les préfixes
des espaces de noms pour ce code dans notre configuration ; ceci est réalisé avec
la clé de configuration <property>autoloaderNamespaces</property>, qui est un tableau.
</para>
<para>
De plus, afin de s'assurer que les plugins de ressources sont trouvées, nous devons
enregistrer un préfixe de chemin de plugin lors de l'amorçage. Ceci peut être réalisé
avec la clé de configuration <property>pluginpaths</property>, qui est un tableau
associatif dont les clés sont les préfixes à utiliser et les valeurs sont les chemins
relatifs à ces préfixes.
</para>
</note>
<para>
Cependant, si de l'initialisation personnalisée est nécessaire, alors vous avez 2
choix. D'abord vous pouvez écrire des méthodes préfixées par <emphasis>_init</emphasis> pour
ajouter du code au bootstrap. De telles méthodes seront appelées par
<methodname>bootstrap()</methodname>, et peuvent être appelées comme si elles étaient
publiques, par : <emphasis>bootstrap<resource>()</emphasis>. Elles peuvent
accepter un tableau d'options.
</para>
<para>
Si votre méthode de ressource retourne une valeur, elle sera stockée dans un conteneur du
bootstrap. Ceci peut être utile quand différentes ressources ont besoin d'interagir (comme
une ressource s'injectant elle-même dans une autre). La méthode
<methodname>getResource()</methodname> peut être utilisée pour récupérer ces valeurs.
</para>
<para>
L'exemple ci-dessous montre une méthode de ressource pour l'initialisation d'un objet
requête. Il utilise le traqueur de dépendances (il dépend de la ressource de contrôleur
frontal), récupère une ressource à partir du bootstrap, et retourne une valeur à stocker
dans le bootstrap.
</para>
<programlisting language="php"><![CDATA[
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
protected function _initRequest()
{
// Vérifie que le contrôleur frontal est bien présent, et le récupère
$this->bootstrap('FrontController');
$front = $this->getResource('FrontController');
// Initialise l'objet requête
$request = new Zend_Controller_Request_Http();
$request->setBaseUrl('/foo');
// On l'ajoute au contrôleur frontal
$front->setRequest($request);
// Le bootstrap va stocker cette valeur dans la clé 'request'
// de son conteneur
return $request;
}
}
]]></programlisting>
<para>
Notez l'appel à <methodname>bootstrap()</methodname> ; Ceci permet de s'assurer que le
contrôleur frontal a bien été initialisé avant d'appeler cette méthode.
</para>
<para>
Une autre option consiste à utiliser des ressources de bootstrap. Les plugins de
ressources sont des objets qui s'occupent d'initialisations spéciales, elles peuvent être
spécifiées :
</para>
<itemizedlist>
<listitem>
<para>
à l'instanciation d'un objet <classname>Zend_Application</classname> ;
</para>
</listitem>
<listitem>
<para>pendant l'initialisation de l'objet bootstrap ;</para>
</listitem>
<listitem>
<para>
en les activant spécifiquement via des appels de méthodes sur l'objet de
bootstrap.
</para>
</listitem>
</itemizedlist>
<para>
Les plugins de ressources implémentent
<classname>Zend_Application_Resource_ResourceAbstract</classname>, qui définit simplement
qu'elles peuvent être injectées dans l'objet les appelant, et qu'elles ont une méthode
<methodname>init()</methodname>. Voici un exemple d'un bootstrap de vue :
</para>
<programlisting language="php"><![CDATA[
class My_Bootstrap_Resource_View
extends Zend_Application_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;
}
}
]]></programlisting>
<para>
Pour dire au bootstrap d'utiliser cette classe, vous devrez fournir le nom de la
classe pour ce plugin de ressource, ou une combinaison préfixe / chemin
de chargeur de plugin (plugin loader) et le nom court du plugin de ressource
("view") :
</para>
<programlisting language="php"><![CDATA[
$application = new Zend_Application(
APPLICATION_ENV,
array(
'resources' => array(
'My_Bootstrap_Resource_View' => array(), // nom de la classe OU
'view' => array(), // nom court
'FrontController' => array(
'controllerDirectory' => APPLICATION_PATH . '/controllers',
),
),
// Pour les noms courts, définissez les chemins :
'resourcePaths = array(
'My_Bootstrap_Resource' => 'My/Bootstrap/Resource',
)
)
);
]]></programlisting>
<para>
Les plugins de ressource peuvent en appeler d'autres via le bootstrap parent :
</para>
<programlisting language="php"><![CDATA[
class My_Bootstrap_Resource_Layout
extends Zend_Application_ResourceAbstract
{
public function init()
{
// Assurons nous que la vue est initialisée...
$this->getBootstrap()->bootstrap('view');
// Récupère l'objet de vue :
$view = $this->getBootstrap()->getResource('view');
// ...
}
}
]]></programlisting>
<para>
En usage normal, vous instancierez votre application, lancerez le bootstrap, puis
l'application :
</para>
<programlisting language="php"><![CDATA[
$application = new Zend_Application(...);
$application->bootstrap()
->run();
]]></programlisting>
<para>
Pour un script personnalisé, vous auriez peut être besoin de ne lancer que des
ressources spécifiques :
</para>
<programlisting language="php"><![CDATA[
$application = new Zend_Application(...);
$application->getBootstrap()->bootstrap('db');
$service = new Zend_XmlRpc_Server();
$service->setClass('Foo'); // uses database...
echo $service->handle();
]]></programlisting>
<para>
Plutôt que d'utiliser la méthode <methodname>bootstrap()</methodname> pour appeler les
méthodes internes, vous pouvez surcharger :
</para>
<programlisting language="php"><![CDATA[
$application = new Zend_Application(...);
$application->getBootstrap()->bootstrapDb();
]]></programlisting>
</sect1>
|