Habituellement pour accéder à la fiche d'un item (un article ou un membre par exemple), on y accède par une vue affichant la liste des items (articles, membres, etc...).
Après avoir affichée le fiche, on revient dans la liste en conservant les filtres éventuels.
Ceci est le cas standard bien géré par les classes du framework de Joomla.
Toutefois on peut avoir besoin d'appeler un fiche pour affichage ou mise à jour à partir d'une autre vue que le vue affichage la liste, ce qui est simple à faire en effectuant un lien vers la vue de la fiche au bon emplacement.
Toutefois, il faut encore gérer le retour à la fermeture de la fiche.
Quelques exemples :
- mettre à jour un lieu à partir d'un calendrier évènementiel indiquant un évènement se déroulant dans ce lieu puis revenir au calendrier.
Ceci plutôt que de devoir aller dans la liste des lieux pour y accéder. - accéder à un formulaire d'affichage de la fiche d'un auteur à partir de l'un de ses publications, puis revenir à la publication.
Ceci plutôt que de devoir passer par la liste des membres - etc...
Une fois de plus, Joomla a déjà prévu ce cas dans son framework !
Principe du cas standard
Quand on doit mettre à jour un élément (un item), la vue utilisé peut être lancée de plusieurs manières.
Le cas "standard", est que l'on appelle la vue unitaire que l'on appellera item par une vue tableau de type "list" que l'on appellera items.
(Dans les habitudes de nommage, elle aura la même nom mais avec un "s" final) .
Dans ce cas lors de la fermeture de la vue "item", on retournera dans la vue définie dans son contrôleur (héritant de JControllerForm), généralement dans le constructeur par l'affectation suivante :
public function construct($config = array())
{
$this->view_list = 'items'; // nom de la vue de type list
parent::construct($config);
}
Définir une url de retour
Mais il est possible de donner une autre url de retour par le biais de la variable d'url "return".
Cette variable sera vérifié dans les méthodes "save" et "cancel" définies dans la classe contrôleur FormController et remplacera si elle est présente l'url de retour "standard" vers la vue "list".
Dans ce cas il faudra alors préparer dans votre contrôleur (qui n'est pas celui "standard" de la vue list items) qui permettra la mise a jour ou l'affichage d'un item l'url d’édition de l'item de la sorte :
$this->setRedirect('index.php?option=com_items&task=item.edit&id=' . $id . '&return='.base64_encode($this->getReturnPage()));
Et la méthode :
protected function getReturnPage()
{
$return = JUri::getInstance()->toString();
if (empty($return) || !JUri::isInternal(base64_decode($return)))
{
return JUri::base();
}
else
{
return base64_decode($return);
}
}
Votre contrôleur item hérite bien sur aussi de JControllerForm.
La méthode getRedirectToItemAppend de JControllerForm complètera l'url de retour avec les variables suivantes (dans la mesure où elles figurent dans la requête GET) :
- tmpl
- layout (valeur par défaut edit)
- forcedlanguage
- return (decodé base64)
La méthode est définie en /librairies/src/MVC/Controller/FormController.php vers la ligne 462
On voit donc que return est repris, si elle est définie dans l'url courante.
La méthode getRedirectToItemAppend($recordId = null, $urlVar = 'id') peut être redéfinie dans votre contrôleur bien sûr.
La classe mêre JControlerForm gére bien sûr nativement le retour sur le vue item, lors des méthode 'apply' et 'save2copy' (mise à jour sans fermeture de la fiche et duplication de la fiche).
Il en est de même lors d'une erreur de validation.
Dans votre template de la vue unitaire, il ne faut pas oublier de renvoyer la variable return :
<input type="hidden" name="return" value="<?php echo $input->get('return', null, 'base64'); ?>" />
Ainsi on peut lancer une vue "unitaire" affichant ou permettant la mise à jour d'un élément, sans obligatoirement devoir passer par une page d'affichage de type table comme on le pratique habituellement.