22 minutes reading time (4312 words)

Série : développer une extension Joomla! 3.0 - Episode 5 : la configuration de l'administration et le nettoyage du code

Série : développer une extension Joomla! 3.0 - Episode 5 : la configuration de l'administration et le nettoyage du code

Salut à tous et soyez les bienvenus pour l’ultime partie de codage de notre série sur le développement d'une extension. Si vous avez suivi les précédents tutoriaux, vous avez passé toutes les étapes du développement nécessaires à la création d'une extension native pour Joomla 3.x. Ce fut un long processus, mais je l'espère, enrichissant et instructif. J'ai apprécié l'opportunité de partager avec vous, tout au long de ces précédents articles, des trucs et astuces sur le développement d'une extension pour Joomla!. Dans ce dernier tutoriel, nous allons explorer quelques derniers concepts, faire un peu de nettoyage et discuter de fonctionnalités supplémentaires que nous pourrions ajouter dans le futur. Alors préparez-vous à plonger dans l'ultime article sur le développement d’un composant pour Joomla! 3.x…

Etape 0 : préparez votre café

Et oui, comme à l’accoutumée et comme pour chacun des articles précédents, nous allons commencer par préparer une tasse de bon café. Au travers de cette routine, nous mettons en condition notre esprit en vue de l'écriture du code et nous nous concentrons sur les tâches à accomplir. Heureusement, cet article n'aura pas besoin d'être aussi détaillé que certains des précédents et je suis certain qu'il ne nécessitera pas un café supplémentaire. Mieux encore et avec un peu de chance, il se pourrait même que vous ayez parcouru la majeure partie de ce tutoriel avant même d'avoir terminé votre tasse.

Etape 1 : l'écriture du panneau d'administration

Le Panneau d'administration Joomla! propose toute une variété de fonctionnalités afin de rendre son utilisation la plus efficace possible. Le panneau d'administration permet de définir les paramètres d'utilisation de tous composants.
Nous avons conçu Lendr comme étant une application de frontend dont la plupart des fonctionnalités sont directement définies par le visiteur. C'est précisément pour cette raison que nous utiliserons le panneau d'administration uniquement pour l'ajout de fonctionnalités complémentaires et quelques paramétrages basiques d'options. En procédant ainsi, nous évitons un duplicata de l'intégralité du code "site" dans la partie "administration" pour chacun des modèles, vues, et contrôleurs du composant.
En suivant cette approche, j'espère que vous serez en mesure de comprendre quand et comment le panneau d'administration peut être utilisé avec un maximum d'efficacité.

Nous allons donc créer les fichiers destinés à la partie du code pour l'administration (NDT : Dossier source administrator) : un fichier aide (helper), un contrôleur (controller), un modèle (model), une vue (view), un fichier d'accès, un fichier de configuration et notre fichier langue.

Nous allons reprendre chacun de ces fichiers, en débutant par le point d'entrée : lendr.php

joomla_root/administrator/components/com_lendr/lendr.php

<?php // No direct access
defined( '_JEXEC' ) or die( 'Restricted access' );
//load classes
JLoader::registerPrefix('Lendr', JPATH_COMPONENT_ADMINISTRATOR);
//Load plugins
JPluginHelper::importPlugin('lendr');
 
//application
$app = JFactory::getApplication();
 
// Require specific controller if requested
$controller = $app->input->get('controller','display');
// Create the controller
$classname  = 'LendrControllers'.ucwords($controller);
$controller = new $classname();
 
// Perform the Request task
$controller->execute();
              
Ce code est relativement similaire à celui destiné au frontend et sert essentiellement à diriger correctement le trafic vers le contrôleur approprié.

joomla_root/administrator/components/com_lendr/controllers/displays.php

<?php defined( '_JEXEC' ) or die( 'Restricted access' ); 
 
class LendrControllersDisplay extends JControllerBase
{
  public function execute()
  {
    // Get the application
    $app = $this->getApplication();
 
    // Get the document object.
    $document     = JFactory::getDocument();
 
    $viewName     = $app->input->getWord('view', 'statistics');
    $viewFormat   = $document->getType();
    $layoutName   = $app->input->getWord('layout', 'default');
    $app->input->set('view', $viewName);
 
    // Register the layout paths for the view
    $paths = new SplPriorityQueue;
    $paths->insert(JPATH_COMPONENT . '/views/' . $viewName . '/tmpl', 'normal');
 
    $viewClass  = 'LendrViews' . ucfirst($viewName) . ucfirst($viewFormat);
    $modelClass = 'LendrModels' . ucfirst($viewName);
    $view = new $viewClass(new $modelClass, $paths);
    $view->setLayout($layoutName);
    // Render our view.
    echo $view->render();
 
    return true;
  }
}

Vous remarquerez au premier coup d'œil les similitudes entre ce contrôleur et le contrôleur par défaut du frontend. Nous réalisons des tâches similaires avec les deux.
Dans ce cas précis, nous paramétrons la vue par défaut différemment de celle du frontend.

Nous allons ensuite examiner le fichier html.php situé dans le dossier de vue par défaut (comme indiqué précédemment la vue par défaut est nommée 'statistics').

joomla_root/administrator/components/com_lendr/views/statistics/html.php

<?php defined( '_JEXEC' ) or die( 'Restricted access' ); 
 
class LendrViewsStatisticsHtml extends JViewHtml
{
  function render()
  {
    $app = JFactory::getApplication();
   
    //retrieve task list from model
    $model = new LendrModelsStatistics();
    $this->stats = $model->getStats();
    $this->addToolbar();
    //display
    return parent::render();
  } 
    /**
     * Add the page title and toolbar.
     *
     * @since   1.6
     */
    protected function addToolbar()
    {
        $canDo  = LendrHelpersLendr::getActions();
        // Get the toolbar object instance
        $bar = JToolBar::getInstance('toolbar');
        JToolbarHelper::title(JText::_('COM_LENDR_STATISTICS'));
               
        if ($canDo->get('core.admin'))
        {
            JToolbarHelper::preferences('com_lendr');
        }
    }
}
              

Ce fichier intègre quelques nouveaux éléments que nous allons étudier plus en détail.
En premier lieu, vous remarquerez que nous héritons de la classe JViewHtml. Cela nous permet de bénéficier de certaines fonctionnalités de base que vous pouvez retrouver en inspectant directement la classe JViewHtml située dans le dossier Librairies de Joomla!.
Nous trouvons ensuite le traditionnel appel de notre modèle pour charger les données spécifiques nécessaires à notre vue.

Ensuite, nous trouvons une nouvelle ligne. La fonction addToolbar est appelée dans ce même fichier et est généralement utilisée pour l'ajout d'éléments dans la barre d'outils du composant de la partie administration du site. Du fait que notre panneau d'administration restera très basique et doté de fonctionnalités limitées, notre barre d'outils ne proposera qu’un seul élément.

Enfin, nous affichons la vue, comme nous l'avions fait précédemment pour le frontend.

La commande addToolbar, comme vu précédemment, ajoute des boutons à la sous-navigation de la barre d'outils de notre composant. Puisque nous n'avons pas besoin d'un ensemble complet de vues et fonctions à incorporer dans notre exemple de panneau d'administration, nous créerons dans notre cas un unique bouton.
La première chose à faire sera de créer une instance à la classe de la barre d'outils standard de Joomla! puis nous assignerons notre titre et bouton à cette instance.

Vous remarquerez que notre fichier langue est utilisé pour toutes les chaînes de caractère. Si vous souhaitez afficher une image à côté du titre de votre composant, il vous faudra simplement intégrer une seconde référence lors de la définition de la ligne du titre.

Note : souvenez-vous que dans les articles précédents, lors de la visualisation de l'administration, une erreur s'affichait. En effet, nous n’avions pas encore indiqué de titre pour la page alors que le template Isis en requiert un.

Dans cette commande, nous appelons également notre classe helper. C'est le bon moment pour revoir à quoi sert cette classe et comment elle est utilisée. Cette classe helper contient quelques fonctions utiles pour l'administration de notre composant.

Note : Il convient de remarquer que nous n'incluons jamais le helper directement. C’est l'auto-loader de Joomla! (comme défini dans le fichier principal lendr.php) qui détecte et charge automatiquement le fichier grâce à nos conventions de nommage.

joomla_root/administrator/components/com_lendr/helpers/lendr.php

<?php
/**
 * @package     Joomla.Administrator
 * @subpackage  com_lendr
 *
 * @copyright   Copyright (C) 2005 - 2013 Open Source Matters, Inc. All rights reserved.
 * @license     GNU General Public License version 2 or later; see LICENSE.txt
 */
defined('_JEXEC') or die;
/**
 * Lendr component helper.
 *
 * @package     Joomla.Administrator
 * @subpackage  com_lendr
 * @since       1.6
 */
class LendrHelpersLendr
{
  public static $extension = 'com_lendr';
  /**
   * @return  JObject
   */
  public static function getActions()
  {
    $user = JFactory::getUser();
    $result = new JObject;
    $assetName = 'com_lendr';
    $level = 'component';
    $actions = JAccess::getActions('com_lendr', $level);
    foreach ($actions as $action)
    {
      $result->set($action->name, $user->authorise($action->name, $assetName));
    }
    return $result;
  }
}

Dans ce helper, nous retrouvons actuellement une fonction. La fonction getActions utilisera le fichier access.xml situé dans le dossier racine 'administrator' du composant. C'est une sympathique petite fonctionnalité qui permet de charger un objet avec les valeurs présentes dans le fichier XML.

Prenons une minute pour jeter un œil à ce fichier access.xml et voyons comment il est lié à la fonctionnalité qui sera utilisée dans tout le composant.

joomla_root/administrator/components/com_lendr/access.xml

<?xml version="1.0" encoding="utf-8"?>
<access component="com_lendr">
  <section name="component">
    <action name="core.admin" title="JACTION_ADMIN" description="JACTION_ADMIN_COMPONENT_DESC" />
  </section>
</access>

Au regard des besoins de ce tutoriel, nous aurons un fichier access minimaliste. Fondamentalement, nous recherchons simplement à savoir si l’accès à l’administration est autorisé ou non. Nous allons utiliser le niveau d'accès à l'administration pour déterminer si l'utilisateur est autorisé ou non à voir les options du sous-menu d'administration du composant (élément que nous avons vu précédemment dans ce tutoriel).
De nombreuses autres sections et actions peuvent être ajoutées ici ainsi que des actions personnalisées. Ce fichier rappelle celui de Joomla!2.5 et si cela vous intéresse, je vous recommande de revoir ses spécificités par le tutoriel ci-dessous.

Note : vous pouvez consulter les informations relatives au fichier access pour Joomla! 2.5 sur : http://docs.joomla.org tutorial

Cela nous amène directement à la deuxième partie de notre étape : les options du composant.

Les options du composant

Les options de notre composant pourront être accessibles par le bouton d'options situé dans la barre d'outils du composant Lendr. Ce bouton est celui que nous avons précédemment étudié dans la partie concernant le fichier html.php. La ligne pour la vérification d'accès canDo permet d'ajouter un bouton "Paramètres" ("Options"). Ces paramètres permettent également d’accéder à la configuration globale des options du composant. Comme vous l’avez probablement découvert avec d'autres composants, tous les boutons "Paramètres" redirigent l'utilisateur vers le com_config du composant et vers la vue correspondante.

Les données utilisées pour cette vue (lorsque vous consultez la page com_config du composant Lendr) proviennent d'un fichier spécifique. Le fichier config.xml est également situé à la racine du composant Lendr, dans la partie administrator.
Jetons un œil à ce fichier.

joomla_root/administrator/components/com_lendr/config.xml

<?xml version="1.0" encoding="utf-8"?>
<config>
  <fieldset name="component"
    label="COM_LENDR_OPTIONS"
    description="COM_LENDR_OPTIONS_DESC"
  >
    <field name="required_account" type="radio"
      default="0"
      class="btn-group"
      label="COM_LENDR_REQUIRED_ACCOUNT"
      description="COM_LENDR_REQUIRED_ACCOUNT_DESC">
      
      <option value="0">JNO</option>
      <option value="1">JYES</option>
    </field>
    <field name="new_reviews" type="radio"
      default="1"
      class="btn-group"
      label="COM_LENDR_ALLOW_NEW_REVIEWS"
      description="COM_LENDR_ALLOW_NEW_REVIEWS_DESC">
      
      <option value="0">JNO</option>
      <option value="1">JYES</option>
    </field>
    <field name="new_wishlists" type="radio"
      default="1"
      class="btn-group"
      label="COM_LENDR_ALLOW_NEW_WISHLISTS"
      description="COM_LENDR_ALLOW_NEW_WISHLISTS_DESC">
      
      <option value="0">JNO</option>
      <option value="1">JYES</option>
    </field>
    <field name="new_waitlists" type="radio"
      default="1"
      class="btn-group"
      label="COM_LENDR_ALLOW_NEW_WAITLISTS"
      description="COM_LENDR_ALLOW_NEW_WAITLISTS_DESC">
      
      <option value="0">JNO</option>
      <option value="1">JYES</option>
    </field>
  </fieldset>
  <fieldset name="permissions"
    description="JCONFIG_PERMISSIONS_DESC"
    label="JCONFIG_PERMISSIONS_LABEL"
  >
    <field name="rules" type="rules"
      component="com_lendr"
      filter="rules"
      validate="rules"
      label="JCONFIG_PERMISSIONS_LABEL"
      section="component" />
  </fieldset>
</config>

Dans ce fichier, vous noterez que nous avons défini deux groupes de champs (fieldsets). Ces groupes correspondent aux onglets situés dans la partie admin lors de l'affichage des options du com_config. Le premier groupe affiche les paramètres spécifiques que nous souhaitons rendre accessibles aux administrateurs et le second groupe concerne l’accessibilité du bouton Paramètres.

Note : vous pouvez définir autant d’onglets "fieldsets" que vous souhaitez pour votre composant.

Lors de la création de ce fichier, il est important de garder à l’esprit certains éléments importants.
En premier lieu, vous devez utiliser en parallèle votre ficher langue pour définir toutes les chaînes de caractères appropriées.
Vous devez également définir les classes pour vos champs afin qu'ils utilisent les styles appropriés.
Enfin, vous pouvez définir différents types de champs que vous pourrez utiliser dans d'autres parties de Joomla!. Dans cet exemple en particulier, nous utilisons principalement les boutons radios pour basculer de la valeur oui à non et inversement.

Il convient maintenant d’explorer le code qui a été ajouté à la partie frontend et qui utilise ces nouveaux paramètres.

Nous allons nous concentrer en particulier sur deux instances.
La première concerne l'option d’un compte obligatoire : required_account. Cette option nous permet de définir si une personne doit ou non se connecter avant de pouvoir utiliser Lendr.
Nous implémentons cette option dans le fichier ci-dessous.

joomla_root/components/com_lendr/controllers/default.php

// Line 11 - 19
 $params = JComponentHelper::getParams('com_lendr');
    if ($params->get('required_account') == 1) 
    {
        $user = JFactory::getUser();
        if ($user->get('guest'))
        {
            $app->redirect('index.php',JText::_('COM_LENDR_ACCOUNT_REQUIRED_MSG'));
        }
    }

Tout d'abord, nous récupérons nos paramètres objet en utilisant le helper du composant. Une fois que nous disposons de ces paramètres, nous pouvons alors vérifier si nous exigeons ou non de nos utilisateurs de posséder un compte. Si c’est le cas, nous vérifions si l’utilisateur est connecté et s'il ne l’est pas, nous le dirigeons vers l'index.php avec un message lui demandant de se connecter pour pouvoir accéder à Lendr.

L'autre instance, où nous verrons l'utilisation d'une valeur de paramètre, se trouve dans la vue d'affichage suivante.

joomla_root/components/com_lendr/views/book/tmpl/_entry.php

Code

Pour cette vérification, nous suivons le même principe de base que celui suivi pour le contrôleur. La seule chose à noter est l'appel au helper de composant pour récupérer les paramètres objet (params) dans le rendu html.php, et non pas en les intégrant ici. Nous pouvons le constater par l’appel $this->params dans la vue.

Etape 2 : le nettoyage du Code

Dans cette étape, nous allons rapidement nous pencher sur deux aspects du nettoyage de notre code.
D’une part, nous devons ajouter la faculté de supprimer des objets, et d'autre part, nous devons proposer une vue de liste pour afficher tous les livres présents dans le système.

Les suppressions de données

La suppression d'objets peut se faire de différentes façons. Dans un premier cas, nous n'allons pas réellement supprimer les données de la base de données (même si cela peut se faire assez facilement) puis dans un second cas, nous allons effectivement supprimer totalement les données.

En effet, il est fréquemment utile de masquer des informations à l'affichage sans réellement supprimer les données du site. Cela nous permet de restaurer un élément que nous aurions accidentellement supprimé. Dans Lendr, le moyen le plus rapide et le plus efficace pour "supprimer" un élément est de définir tout simplement la variable 'publier' à 0 (zéro). Pour certains autres composants, un 'publier' sur 0 n'implique pas forcément une suppression "réversible", c'est pourquoi il est plus fréquent de voir un paramètre -1 comme valeur de publication. Dans notre cas d'utilisation spécifique, nous n'utilisons pas de publier = 0 si bien qu’en indiquant la variable 0, nous obtiendrons effectivement une suppression 'réversible' de l'affichage de l'élément.

joomla_root/components/com_lendr/controllers/delete.php

<?php defined( '_JEXEC' ) or die( 'Restricted access' ); 
 
class LendrControllersDelete extends JControllerBase
{
  public function execute()
  {
    $app = JFactory::getApplication();
    $return = array("success"=>false);
    
    $type = $app->input->get('type','waitlist');
   
    $modelName = 'LendrModels'.ucfirst($type);    
    $model = new $modelName();
    if ( $row = $model->delete() )
    {
      $return['success'] = true;
      $return['msg'] = JText::_('COM_LENDR_BOOK_DELETE_SUCCESS');
    }else{
      $return['msg'] = JText::_('COM_LENDR_BOOK_DELETE_FAILURE');
    }
    echo json_encode($return);
  }
}

Dans notre contrôleur de suppression (car chaque contrôleur se doit d’exécuter une tâche unique), nous avons la commande qui va transmettre les données au modèle approprié pour traitement. Ici, nous configurons le nom du modèle basé sur une valeur située dans la variable JInput. Le modèle est à l'endroit où nous allons réellement supprimer l'élément.

joomla_root/components/com_lendr/models/book.php

 /**
  * Delete a book
  * @param int      ID of the book to delete
  * @return boolean True if successfully deleted
  */
  public function delete($id = null)
  {
    $app  = JFactory::getApplication();
    $id   = $id ? $id : $app->input->get('book_id');
    $book = JTable::getInstance('Book','Table');
    $book->load($id);
    $book->published = 0;
    if($book->store()) 
    {
      return true;
    } else {
      return false;
    }
  }

La suppression d'un livre est un des exemples où nous utiliserons une suppression 'réversible' plutôt que la suppression définitive d'un objet. Comme vous pouvez le constater ci-dessus, le code est assez simple. Nous allons localiser l'ID du livre que nous souhaitons supprimer, nous allons ensuite obtenir une instance de la table Book et charger la ligne appropriée. Une fois la ligne chargée, nous pouvons aisément définir son statut de publication sur 0 puis stocker le résultat. Si la ligne est stockée avec succès, nous renvoyons alors une valeur 'true' au javascript, dans le cas contraire et si le stockage échoue, nous retournerons une valeur 'false'.

Le deuxième emplacement où nous allons traiter de la suppression d'un élément sera dans le modèle de liste d'attente (waitlist).

joomla_root/components/com_lendr/models/waitlist.php

/**
  * Delete a book from a waitlist
  * @param int      ID of the book to delete
  * @return boolean True if successfully deleted
  */
  public function delete($id = null)
  {
    $app  = JFactory::getApplication();
    $id   = $id ? $id : $app->input->get('waitlist_id');
    if (!$id)
    {
      if ($book_id = $app->input->get('book_id')) 
      {
        $db = JFactory::getDbo();
        $user = JFactory::getUser();
        $query = $db->getQuery(true);
        $query->delete()
            ->from('#__lendr_waitlists')
            ->where('user_id = ' . $user->id)
            ->where('book_id = ' . $book_id);
        $db->setQuery($query);
        if($db->query()) {
          return true;
        }
      } 
    } else {
      $waitlist = JTable::getInstance('Waitlist','Table');
      $waitlist->load($id);
      if ($waitlist->delete()) 
      {
        return true;
      }      
    }
    return false;
  }

Dans cet exemple, nous allons supprimer définitivement la ligne dans la table de la base de données.
La raison pour laquelle nous le faisons dans ce cas est simple : il n'existe pas de colonne dans la base de données pour la publication. L'option d’une suppression définitive est ainsi la plus appropriée.

Comme dans l'exemple précédent sur la uppression d'un livre, nous regardons si nous avons une ID spécifique dans la liste d'attente. Nous pouvons alors charger cet objet en particulier et le supprimer directement. Si toutefois, nous n'avons pas d'ID spécifique dans notre liste d'attente, nous pouvons rechercher la ligne nécessaire en utilisant l'ID du livre et l'ID de l'utilisateur puis nous supprimons la ligne associée.

Dans Lendr, nous traitons la suppression de livres au travers d’appels AJAX, et par conséquent lorsque le bouton de suppression est actionné, nous voulons supprimer automatiquement et immédiatement la ligne associée sur la page que nous consultons.
Voici le javascript utilisé pour traiter l'appel AJAX et la suppression de la ligne.

joomla_root/components/com_lendr/assets/js/lendr.js

function deleteBook(book_id,type) 
{
  jQuery.ajax({
    url:'index.php?option=com_lendr&controller=delete&format=raw&tmpl=component',
    type:'POST',
    data: 'book_id='+book_id+'&type='+type,
    dataType: 'JSON',
    success:function(data)
    {
      alert(data.msg);
      if(data.success)
      {
        jQuery("tr#bookRow"+book_id).hide();
      }
    }
  });
}

Ici, nous passons le book_id mais également le type. Comme nous l'avons vu précédemment, le type est important pour une utilisation par le contrôleur de suppression (rappelez-vous : c'est ainsi que nous dirigeons la tâche vers le modèle approprié). Ensuite, nous allons afficher le message d'alerte résultant et généré par le contrôleur de suppression et si la suppression est réussie, nous allons supprimer la ligne correspondante de la vue de liste. Nous retirons la ligne simplement en la cachant via jQuery. L'ID de la ligne dans la table a été définie par bookRow et par l'ID de ce livre en particulier (qui est un identifiant unique).

La vue de la liste de livres

Le second élément que nous avons besoin de reprendre est la vue de liste de tous les livres. Cette étape est assez simple et ne nécessite que peu de code. En premier lieu, il nous faut modifier la classe de la vue html.php des livres. Cela peut se faire par la mise à jour suivante :

joomla_root/components/com_lendr/views/book/html.php

// Lines 8 - 19
    $layout = $this->getLayout();
    $this->params = JComponentHelper::getParams('com_lendr');
    //retrieve task list from model
    $model = new LendrModelsBook();
    if($layout == 'list')
    {
        $this->books = $model->listItems();
        $this->_bookListView = LendrHelpersView::load('Book','_entry','phtml');
    } else {
  …

Ici nous avons ajouté un appel afin d’obtenir la variable de mise en page puis nous vérifions pour déterminer la vue que nous chargerons. Si nous sommes dans la vue de liste, alors nous souhaitons afficher une liste de tous les éléments disponibles. Sinon, nous chargerons la vue de la même manière que précédemment.

Ensuite, nous allons ajouter une nouvelle mise en page de la liste pour l’affichage de tous les livres.

joomla_root/components/com_lendr/views/book/tmpl/list.php

<table cellpadding="0" cellspacing="0" width="100%" class="table table-striped">
  <thead>
    <tr>
      <th><?php echo JText::_('COM_LENDR_DETAILS'); ?></th>
      <th><?php echo JText::_('COM_LENDR_STATUS'); ?></th>
      <th><?php echo JText::_('COM_LENDR_ACTIONS'); ?></th>
    </tr>
  </thead>
  <tbody id="book-list">
    <?php for($i=0, $n = count($this->books);$i<$n;$i++) { 
            $this->_bookListView->book = $this->books[$i];
            $this->_bookListView->type = 'book';
            echo $this->_bookListView->render();
    } ?>
  </tbody>
</table>

Vous remarquerez la similitude entre cette vue et les vues de bibliothèque que nous avons réalisées précédemment. La seule différence est qu’ici nous chargerons l’intégralité des livres du système et non pas les livres associés à une bibliothèque en particulier.

Etape 3 : les Menus et nettoyage de fichiers

Dans cette étape, nous allons passer en revue deux parties.
La première consiste à créer et définir de possibles points d’entrée qui seront utilisés lors de la création des liens de menu dans le panneau d’administration.
La seconde partie consistera en la suppression de quelques fichiers et/ou fonctions inutiles.

La création des liens de menu

Il est souvent indispensable de créer un point d’entrée sous la forme d’un lien de menu afin de permettre l’affichage en frontend. Les liens de menu sont ajoutés dans l’administration via le gestionnaire de menu. Lors de l’ajout d’un nouvel élément de menu, vous sélectionnez le type de lien de menu que vous désirez ajouter. Il nous faut donc définir les vues que nous souhaitons afficher dans la fenêtre de sélection de lien de menu. Il existe deux différents types d’affichages que nous souhaitons ajouter aux options de type de menu. Premièrement, nous voulons que les utilisateurs puissent créer un lien vers une liste de tous les profils, et deuxièmement, nous souhaitons pouvoir créer un lien vers la liste de tous les livres.

Les liens de menu sont basés sur des fichiers associés metadata.xml placés dans différents dossiers de vue du composant. Voici l’exemple pour l’affichage du profil :

joomla_root/components/com_lendr/views/profile/tmpl/list.xml

<?xml version="1.0" encoding="utf-8"?>
<metadata>
  <layout title="COM_LENDR_PROFILE_LIST">
    <message><![CDATA[COM_LENDR_PROFILE_LIST_DESC]]></message>
  </layout>
</metadata>
Note : le nom de ce fichier doit être coordonné avec le nom du fichier de rendu d’affichage situé dans le même répertoire.

Vous remarquerez que puisque que nous souhaitons créer un lien vers un rendu d’affichage (layout), nous définissons un objet <layout>. Si nous avions voulu un lien vers une vue, nous aurions défini un objet <view>. Les chaînes de langue sont stockées dans le fichier de langue du système d'administration.

Le fichier langue système pour Lendr est présenté ci-dessous.

joomla_root/administrator/languages/en-GB/en-GB.com_lendr.sys.ini

COM_LENDR = Lendr
COM_LENDR_SETTINGS = Lendr Settings
COM_LENDR_PROFILE_LIST = Profile List
COM_LENDR_PROFILE_LIST_DESC = Display list of all profiles
COM_LENDR_BOOK_LIST = Book List
COM_LENDR_BOOK_LIST_DESC = Display list of all books

Ces chaînes seront utilisées pour les éléments en référence à Lendr en dehors du composant lui-même. Cela signifie que ces chaînes seront toujours chargées par votre site Joomla! et non pas uniquement à l’intérieur de index.php?option=com_lendr. Par exemple, la fenêtre du choix de type de lien de menu est un des cas où ces chaînes pourront êtres utilisées. Le menu d’administration du composant est un deuxième exemple.

En ajoutant ce fichier metadata.xml dans le dossier approprié, nous pouvons maintenant voir cet affichage dans la liste de menu. Le fichier de métadonnées peut également contenir des options avancées pour l'ajout de paramètres supplémentaires. Par exemple, en ajoutant la possibilité de sélectionner un livre ou un profil en particulier à associer un lien de menu.

La suppression des fichiers et fonctions inutiles

Nous avons plutôt fait du bon travail tout au long de ce tutoriel en évitant d'ajouter des fonctions ou fichiers inutiles. Ainsi, il existe très peu d'éléments à supprimer. Il y a bien quelques contrôleurs de la partie frontend puisque nous ne les avons pas mis en œuvre dans le cadre de ce tutoriel. Il existe également quelques vues que nous devrons nettoyer.
En fait, cette étape n'est principalement relatée ici que pour servir de pense-bête pour vos développements futurs afin de toujours vous rappeler de devoir nettoyer votre code.

Pour des raisons de sécurités, de poids, et plus généralement pour respecter les normes de codage, il est préférable de s'assurer qu'il n'existe pas de fichiers, dossiers ou fonctions inutiles qui pourraient poser problème à l'avenir.
N'oubliez pas également qu'il est toujours une bonne idée de penser que vous codez pour un tiers. Cela vous forcera à commenter suffisamment et correctement votre code et à supprimer tout ce qui n'est pas nécessaire et pourrait être source de confusion pour l'avenir.

Etape 4 : suggestions complémentaires

Voici quelques suggestions supplémentaires qui pourraient être explorées dans de futurs articles en complément de cette série. Certaines de ces idées permettraient d’offrir de nouvelles fonctionnalités à tout composant Joomla!3.x. Si vous êtes intéressés par un article sur l’une ou l’autre de ces idées, n’hésitez pas à me poster un message en commentaire.

Les Tags

Les tags sont une toute nouvelle fonctionnalité native proposée avec la version Joomla! 3.1. Grâce aux tags (NDT : parfois nommés étiquettes ou mots-clés), nous pourrions désormais attribuer des mots-clés à des livres, et ainsi être en mesure de les rechercher et les regrouper selon ces mêmes mots-clés. Les tags permettent également de lier des livres à de multiples mots-clés, chacun pouvant être filtré et trié.

Les Catégories

Les catégories permettent l’ajout de livres à des catégories spécifiques. Cela permettrait des regroupements thématiques poussés, et de nous intéresser à l’utilisation de la structure de catégories sous Joomla! ainsi qu’à la méthode adéquate pour l'utilisation de ces catégories.

Les services Web / JSON

En utilisant un modèle de base de services Web, nous pourrions décrire des méthodes pour la récupération directe de données depuis le composant Lendr sans utiliser les vue et mises en page standards du composant. La récupération de données dans un flux JSON permet une utilisation dans d'autres systèmes.

Téléchargement

Téléchargez le composant (tel qu'il existe à cette étape) depuis le dépôt GitHub

Téléchargement

Article suivant: le suivi des versions

Comme je l'ai déjà mentionné, cet article est le dernier de cette série sur le codage. Cependant, dans la prochaine publication, nous allons discuter de quelques idées pour le suivi des versions et le support du composant. Nous découvrirons GitHub et les méthodes de distribution ainsi que les conventions de numérotation de version, les calendriers de mises à jour et bien plus encore.

Visitez le site tutoriel complet: http://lendr.sparkbuilt.com/

Ressources :

lendr.sparkbuilt.com

Dans la série :

 

0
Post your Haikus for July
Module Modernization
 

Comments

Already Registered? Login Here
No comments made yet. Be the first to submit a comment

By accepting you will be accessing a service provided by a third-party external to https://magazine.joomla.org/