Yii : Configurer les contrôleurs à partir d’un contrôleur principal
Les fichiers de configuration de Yii sont un moyen simple et efficace de paramétrer le comportement global d’une application : gestion des paramètres des différents composants, initialisation de la connexion à la base de données, cache…
Il arrive cependant que certains éléments de votre application ne puissent pas être contrôlés de cette manière, notamment au niveau des contrôleurs. En effet, on voudra parfois que tous les contrôleurs de son application partagent certaines caractéristiques comme des comportements ou méthodes. Ce tutorial a pour but de vous montrer une méthode permettant d’arriver à ce résultat en créant un contrôleur principal qui sera chargé du partage de ces caractéristiques communes.
1. Création du contrôleur principal
D’abord, nous créons le contrôleur »maître » de l’application. Appelons-le MainController :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | <?php class MainController extends CController { public function init() { $this->attachBehavior('returnable', 'XReturnable'); // Excellente extension ;) CHtml::$errorSummaryCss = 'errorSummary ui-state-error ui-corner-all'; // Si on utilise JUI, ça peut aider } /** * @return array action filters */ public function filters() { return array ( 'accessControl', ); } } |
Rien de bien sorcier ici. Dans le méthode init, on attache un comportement et on paramètre un attribut de classe. On sur-défini la méthode filter afin que le contrôleur soit placer sous contrôle d’accès.
Ceci est un exemple, vous pouvez évidement ajouter les méthodes et initialisations qui correspondent à vos besoins.
2. Modification du fichier de configuration afin de charger le contrôleur principal
Etant donné que notre contrôleur ne sera jamais appelé directement, il va falloir indiqué à l’application qu’il faut le charger systématiquement.
Ceci peut facilement être réaliser en modifiant le fichier de configuration et en indiquant son chemin complet dans l’attribut « import » comme suit :
1 2 3 4 5 6 7 | // autoloading model and component classes 'import'=>array( 'application.models.*', 'application.components.*', 'application.extensions.xreturnable.*', 'application.controllers.MainController', // On charge le contrôleur ici ), |
C’est tout.
3. Modification des contrôleurs de l’application
Pour la dernière étape, une petite modification des contrôleurs de l’application est nécessaire. Pour que le contrôleur principal puisse apporter ses caractéristiques aux autres contôleurs, il faut que ceux-ci soient déclarés en tant que sous-classe de MainController.
Par exemple, pour un controleur nommé SiteController, cela donnera :
1 2 3 4 5 | <?php class SiteController extends MainController { ... } |
Voila, de cette manière, notre contrôleur a hérité des caractéristiques de son parent. On peut par exemple utiliser à présent le comportement XReturnable dans toute notre application sans devoir l’initialiser pour chaque contrôleur.
C’est une façon pratique partager des variables globales ou des méthodes transversales. L’autre avantage est que si l’on souhaite changer le comportement global de son application, il n’y a qu’un seul contrôleur à maintenir (tout le charme de la programmation objet et de l’héritage en somme).
A bientôt pour de nouvelles aventures
Hello,
Merci pour vos tutoriaux qui sont d’une grande qualité (à l’image du framework !).
Pour appuyer votre article, je recommande aussi de surcharger CHtml, CActiveForm, CActiveRecord, CFormModel et CAction.
Même si vous ne spécialisez pas tous de suite ces classes, vous vous garantissez une plus grande modularité. Typiquement dans le cas de l’utilisation de RBAC comme Rights ou d’ajout de fonctionnalités transversales (log, transformation de date, ect)
gii, c’est
il manque un bout…
Pour simplifier l’intégration, créez des templates gii (model, crud, ect) qui utilisent vos classes
@cma Merci beaucoup pour vos commentaires. La surcharge des classes est bien sûre une pratique fort utile en développement orienté objets. A noter que la version 1.1 intègre nativement une classe Controler qui surcharge CControler.
.
Pour le reste, c’est en fonction des besoins applicatifs et un soucis de ne pas non plus tomber dans le syndrome de la surcharge aiguë
Et oui, Gii est un outil absolument formidable de productivité, pas de doutes la dessus !
A bientôt j’espère