Joomla! Documentation™

Préface

Avant de lire cette rubrique, il vous est conseillé d'être familier avec le modèle MVC de Joomla!.

Introduction

Dans Joomla! 2.5 et 3.x, de nombreuses améliorations portant sur le MVC ont été ajoutées. Ces améliorations ont pour objectif de rendre les tâches des développeurs plus faciles à exécuter. Dans Joomla! 1.5, il n'y avait qu'une seule classe 'Controller' nommée JController. Dans Joomla! 2.5, "'JControllerAdmin"' et "'JControllerForm" " ont été ajoutées comme sous-classes de JControllerLegacy. Il existe différentes utilisations possibles de ces trois classes dans le cadre du développement d'un composant Joomla. C'est un modèle utilisé par la plupart des composants natifs de Joomla! comme pour com_content et com_banners.

		et suivant
JController	JController (depuis 2.5.5, il faut utiliser JControllerLegacy pour une question de rétro-compatibilité).	JControllerLegacy
	JControllerAdmin	JControllerAdmin
	JControllerForm	JControllerForm
		JControllerBase (nouveau MVC)

Si vous regardez le code admin pour com_content, vous trouverez les classes "controller" à deux endroits : dans le dossier racine et le dossier "controllers". Dans le dossier racine il existe un fichier nommé controller.php" qui est le contrôleur principal du composant. C'est une sous-classe directe de JControllerLegacy. Dans le dossier "controllers", de nombreux fichiers portent le nom de leur entité dans le composant comme par exemple "article" ou encore "articles". Il existe également des sous-classes de contrôleurs JControllerAdmin ou JControllerForm.

Le Controller principal

Le contrôleur principal qui se trouve dans le dossier racine est seulement responsable de l'affichage de la tâche. C'est la tâche par défaut pour JControllerLegacy. Si vous jetez un œil à JControllerLegacy::getInstance dans com_content/content.php, seul le nom du composant est passé en paramètre. JControllerLegacy utilise une variable de la tâche (dans la requête) afin de déterminer quelle est la classe Controller à charger. Si la variable de tâche contient un point (.), cela suppose que cette variable est dans le formulaire de controller.task ou controller.method. Vous devez savoir que la variable de tâche spécifie la méthode de contrôleur à exécuter. Ainsi, dans ce cas, la classe controller va se charger dans le dossier controllers et réécrire la variable de tâche en tâche réelle. Si la tâche ne contient pas de point (.), JControllerLegacy va charger le contrôleur principal, situé dans le dossier racine. Pour simplifier, nous appellerons les contrôleurs du dossier controllers comme des sous-contrôleurs. Vous remarquerez peut-être que dans le contrôleur principal, une vue par défaut est également spécifiée. Si il n'existe pas de variable dans l'URL de la requête, cette vue sera utilisée. Il est donc possible de conclure :

• Pour utiliser le contrôleur principal, il convient de spécifier une variable de vue comme nom de la vue à utiliser ou celle par défaut sera utilisée.
• Pour utiliser un 'subcontroller', il convient de spécifier la variable de tâche dans le formulaire du controller.task CONTROLLER_NAME.CONTROLLER_METHOD.

Nous pouvons classer les différents affichages en deux types : la présentation d'une liste d'éléments (list view - affichage en liste) et l'affichage détaillé des éléments à l'utilisateur (par exemple : modifier un formulaire). Si l'on regarde la vue d'articles dans com_content qui affiche une liste des éléments à l'utilisateur, nous pouvons remarquer que les boutons de barre d'outils sont ajoutés en fonction des droits des utilisateurs.

$JOOMLA_INSTALL/administrator/components/com_content/views/articles/view.html.php

 protected function addToolbar()
 {
   ...

   if (($canDo->get('core.edit')) || ($canDo->get('core.edit.own'))) {
     JToolBarHelper::editList('article.edit');
   }

   ...
  }

Par exemple, pour modifier un article, la variable serait article.edit. Cela permettra au subcontroller 'article' de se charger et à la méthode 'edit' de s'exécuter. Vous pouvez avoir une question à poser et ainsi, le formulaire d'édition sera affiché pour l'utilisateur. En général, c'est ce qu'il sera fait mais dans les composants natifs Joomla! 2.5, cela défini l'id de l'article à modifier pour la session utilisateur et redirigera vers l'url de type : &view=article&layout=edit. Cela sera géré par le contrôleur principal et le formulaire de modification sera affiché à l'utilisateur. Donc dans ce cas, l'affichage sera traitée par le contrôleur principal et aura besoin de vues.

• Si le nom d'une vue n'est pas défini dans l'URL, l'affichage de la vue par défaut sera utilisé et une tâche par défaut (display) sera exécutée. Nous utilisons cette option pour afficher une liste d'éléments. Par exemple : index.php?option=com_content.
• Si une vue est définie mais que la tâche ne l'est pas, le contrôleur principal va charger la vue spécifiée et exécuter la méthode d'affichage. Cela est également le cas pour afficher une liste d'éléments. Par exemple : index.php?option=com_content&view=articles.
• Si une vue est spécifiée ainsi qu'une tâche (pas dans le format dot (.)), le contrôleur principal va charger la vue spécifiée et exécuter la méthode spécifiée par la tâche. Ce cas est utilisé pour afficher le formulaire de modification ou pour afficher à l'utilisateur un élément. Un exemple : index.php?option=com_content&view=article&layout=edit.

Lorsque le contrôleur principal va créer une vue, il charge normalement un modèle ayant le même nom que la vue et intègre le modèle dans la vue. Alors, la méthode d'affichage de la vue est appelée. Ce faisant, il est possible d'obtenir les données du modèle à l'aide de la fonction $this->get("Items"). Dans ce cas, la vue va rechercher la méthode getItems dans le modèle et l'exécuter. En faisant cela, nous pouvons utiliser un contrôleur pour afficher toutes les types d'information du composant. Mais, de nombreuses vues sont encore nécessaires. Cela permet de réduire le nombre de classes de contrôleur et bien sûr, cela réduit le volume de code à produire par les développeurs.

Les Subcontrollers

Les sous-contrôleurs se chargeront de toutes les tâches CRUD. Pour des tâches telles que enregistrer, supprimer et publier qui ne nécessites pas de vues, le sous-contrôleur se contentera de supprimer ou de mettre à jour les enregistrements et rediriger l'utilisateur vers d'affichage en liste. Dans ce cas, l'utilisateur doit sélectionner au moins un élément et généralement, nous donnons un nom pluriel au contrôleur comme par exemple : articles.delete, articles.publish_up ou articles.publish_down. Ces sous-contrôleurs sont généralement hérités de JControllerAdmin qui suppriment la méthode d'affichage par défaut.

A première vue, l'autre type de CRUD comme 'ajouter' ou 'modifier', devrait préparer les données et présenter le formulaire à l'utilisateur. Mais dans les composants natifs de Joomla! 2.5, ce n'est pas le cas. En regardant ce type de sous-contrôleurs (par exemple ContentControllerArticle) on peut voir qu'ils sont toujours hérités de JControllerForm. Mais aucun formulaire n'est présenté à l'utilisateur par cette requête, il stock uniquement l'élément (l'ID de l'article) dans la variable de session utilisateur et redirige vers contrôleur principal. Comme une variable de tâche n'a pas été spécifiée, la méthode d'affichage est exécutée comme tâche par défaut.

Par exemple : la première requête traitée par un sous-contrôleur peut contenir task=article.edit et cid[]=3. Le sous-contrôleur va alors créer des URL de type index.php?option=com_content&view=article&layout=edit avant de rediriger l'utilisateur vers contrôleur principal.