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 :)

  1. cma
    21/12/2010 à 11:53 | #1

    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

  2. cma
    21/12/2010 à 11:56 | #2

    il manque un bout…

    Pour simplifier l’intégration, créez des templates gii (model, crud, ect) qui utilisent vos classes

  3. 21/12/2010 à 19:10 | #3

    @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 :)

  1. Pas encore de trackbacks

Performance Optimization WordPress Plugins by W3 EDGE

Switch to our mobile site