C'est parti pour le pavé.
D'abord on va voir un cas général sur le passage de paramètres entre l'action, son partial (template) et un sous-partial (pour rester simple on va oublier le générateur pour l'instant, vu qu'il respecte en tous points cette logique).
On va imaginer qu'on se trouve dans un projet (site) nommé
myproject, dans une application nommée
myapp, dans un module appelé
mymodule et une action intitulée
myaction. On a une variable à transmettre qui s'appelle
myvariable et qui contient une valeur extrêmement utile :
123456.
----------------------------------------------------------
Exemple simple sans générateur :
Côté action, on a :
<?php
// fichier : /myproject/apps/myapp/modules/mymodule/actions/actions.class.php
// Il y a deux façons d'écrire ses actions pour un module (on peut aussi utiliser les deux dans un même module) :
// 1: - soit une classe pour toutes les actions (le cas classique, ce que fait le générateur, et ce que nous faisons ici)
// 2: - soit une classe pour chaque action.
// Pour le cas n°1, le fichier contenant la classe s'appelle toujours module/actions/actions.class.php
// et la classe doit toujours hériter de sfActions (directement, comme ici, ou indirectement, comme avec le générateur)
class MymoduleActions extends sfActions{
// Voici notre méthode spécifique à l'action :
public function executeMyaction(){
// Ici nous instancions notre variable :
$variable = 123456;
// Ici nous la rendons disponible dans le partial sous le nom myvariable :
$this->myvariable = $variable;
// une action qui se termine normalement doit toujours renvoyer cette valeur
// (on peut aussi ne pas la spécifier, car symfony la rajoute par défaut)
return sfView::SUCCESS;
}
}
Côté partial, on a :
<!-- fichier : /myproject/apps/myapp/modules/mymodule/templates/myactionSuccess.php -->
<?php
// On teste si la variable a bien été transmise :
echo 'Premier fichier : '.$myvariable; // 123456
?>
<?php
// Transmission explicite des variables au sous-template sous forme de paires clé => valeur
include_partial('mysubpartial', array(
'myvariable' => $myvariable
));
?>
<!-- fichier : /myproject/apps/myapp/modules/mymodule/templates/_mysubpartial.php -->
<?php
// On teste si la variable a bien été transmise :
echo 'Second fichier : '.$myvariable; // 123456
?>
Exemple à l'appui on a donc vu que :
- Le premier partial (myactionSuccess) reçoit ses variables à partir des propriétés de l'objet action qui le lance.
- Les sous-partials reçoivent leurs variables de manière explicite lors de l'inclusion par le partial parent.
On peut se représenter les partials sous forme de hiérarchie (entre crochets, les variables transmises) :
Code : Tout sélectionner
-Action:myaction
+--myactionSuccess [myvariable]
+--_mysubpartial [myvariable]
----------------------------------------------------------
Avec le générateur :
Le générateur crée à ta place un certain nombre d'actions et leurs partials (et sous-partials) correspondants, dans un répertoire de cache (pour ne pas les mélanger avec ceux que tu écris).
Ce processus de génération est contrôlé par le fichier mymodule/config/generator.yml . La classe actions du répertoire principal de ton module étend par héritage de classes la classe action générée par le générateur
( qui s'appelle, elle,
autoMymoduleActions ). A noter également que le processus d'inclusion de symfony (et include_partial() qu'on a vu plus haut utilise aussi ce principe) est capable d'aller chercher dans plusieurs répertoires avec une gestion de priorité. Conséquences :
- Si tu veux surcharger le code d'une action générée, il te suffit de réécrire la méthode concernée dans ta classe mymoduleActions en veillant à bien recopier l'en-tête (prototype) de la méthode ( sinon : erreur php )
- Si tu veux surcharger un partial, ou sous-partial, il te suffit de créer dans ton répertoire mymodule/templates/ un fichier de même nom. Il sera utilisé en lieu et place du fichier généré.
- Si tu surcharges un partial qui appele des sous-partials, il te faut bien respecter la chaîne d'inclusion des sous-partials en la réécrivant (à moins de savoir ce que tu fais). Mais tu peux aussi ajouter des paramètres aux appels à include_partial() et c'est surtout ça que tu as besoin de faire dans ton cas,
agité.
Voici la hiérarchie du module créé par le générateur d'admin (pour une classe métier Myobject):
Code : Tout sélectionner
-Action:index (alias pour list)
-Action:list
+--listSuccess [pager, filters]
+--_list_header [pager]
+--_list_messages [pager]
+--_filters [filters]
+--_list [pager]
+--_list_th_tabular
+--_list_th_stacked
+--_list_td_tabular [myobject]
+--_list_td_stacked [myobject]
+--_list_td_actions [myobject]
+--_list_actions
+--_list_footer [pager]
-Action:create (alias pour edit)
-Action:edit
+--editSuccess [myobject, labels]
+--_edit_header [myobject]
+--_edit_messages [myobject, labels]
+--_edit_form [myobject, labels]
+--_edit_actions [myobject]
+--_edit_footer [myobject]
Est-ce que tu vois mieux ce qui te reste à faire maintenant ?
----------------------------------------------------------
Le pager c'est quoi ?
C'est une classe symfony qui est capable de gérer une liste d'objet avec gestion d'affichage page par page. En gros c'est l'objet qui te permet d'avoir le gros tableau de ta list view, avec le total d'éléments trouvés... ainsi que la pagination
|< < 1 2 3 > >|. Mais pour simplifier on peut le voir uniquement comme une liste d'objets, tout bêtement. On le lit dans une boucle et les objets sortent un à un.
)
).
Il se peut aussi que tu aies quelques autres méthodes à surcharger dans les actions, sur le même principe...
