Voilà, voilà... Fin de l'aventure...

 

Fermeture de kolossaldrupal.org dans...


Bonjour tout le monde,

Drupal évolue, les versions changent et Kolossaldrupal.org était essentiellement consacré à la version 6 de Drupal.

Autant dire que les infos présentées ici commencent à dater...

Faute de temps, je ne peux plus garder le site Kolossaldrupal à jour...

Je vous aurais bien proposé de reprendre le flambeau mais... c'est tellement simple de nos jours de se faire son propre site à soi...Pourquoi s'embêter alors ? :-)

Ce site restera donc en l'état, tel qu'il était en 2011...

Ah la la ! Cela ne nous rajeunit pas !

Manuel Vila - Avril 2016

Le registre de thèmes pour les cas particuliers

Traduction de la page http://drupal.org/node/223463
publiée/actualisée le 1 Mars 2011 sur drupal.org

Vous devez être familiarisé avec la raison d'être du registre de thème (purpose) avant de poursuivre la lecture de cette page. Les explications qui suivent portent sur l'enregistrement manuel d'un point d'entrée de thème et sur comment le manipuler (manipulated)

Le cas le plus fréquent demandant l'enregistrement manuel des points d'entrée sont les formulaires. Le design des éléments de formulaire est personnalisable mais il existe un autre aspect concernant la façon dont ils sont traités.

Dans un formulaire, on peut trouver des éléments génériques tels que cases à cocher, boutons radios, listes déroulantes, boutons, etc. Chacun de ces éléments est personnalisable et surcharger leurs styles n'implique pas de devoir enregistrer manuellement les points d'entrée qui leurs sont associés.

Le nouvel aspect dont il est question vient avec les formulaires personnalisés dans lesquels chaque élément est disposé de façon très particulière. Dans certains formulaires, ces éléments viennent déjà organisés, designés et enregistrés. Pour ces formulaires, l'enregistrement manuel n'est pas nécessaire.

The forms that are not explicitly themed will default to how form API renders them.

Exemple de formulaire enregistré :

Voici un exemple pour deux des formulaires de recherche enregistrés par le module Search, la boite de recherche et le bloc de recherche. Chaque formulaire est associé à un identifiant unique.

L'enregistrement des identifiants sert également de point d'entrée de thème. Dans cet exemple, il s'agit de search_theme_form et search_block_form.

<?php
function search_theme() {
  return array(
    
'search_theme_form' => array(
      
'arguments' => array('form' => NULL),
      
'template' => 'search-theme-form',
    ),
    
'search_block_form' => array(
      
'arguments' => array('form' => NULL),
      
'template' => 'search-block-form',
    ),
    ...
  );
}
?>

L'API Form passe le contrôle de sa présentation au handler du point d'entrée enregistré.

Form API passes control of its presentation along to the handler of the registered hook.

Dans cet exemple, il est enregistré avec le type de gabarit et ses arguments par défaut. La sortie sera facilement modifiée par le thème puisqu'il a déjà été déclaré comme gabarit (template).

L'auto-découverte des points d'entrée ne se produit qu'avec les points d'entré de thèmes enregistrés avant la couche du thème (voir illustration : http://www.kolossaldrupal.org/docs/la-surcharge-themes#theming-overrides)

Formulaires déclarés et non déclarés :

Il y a un autre formulaire de recherche qui n'est pas enregistré. C'est le formulaire avec l'identifiant search_form utilisé dans la page de recherche principale. Les données du formulaire sont construites dans une fonction (constructed in a function), tout comme n'importe quel autre formulaire, mais on laisse l'API Form s'occuper de la présentation en la basant sur la structure de données du formulaire.

Pour pouvoir la surcharger, vous devez l'enregistrer depuis votre thème avec un hook_theme. Mettez le code suivant dans votre fichier template.php en remplaçant le préfixe « drop » par le nom de votre thème. Le point d'entrée est l'identifiant du formulaire :

<?php
function drop_theme() {
  return array(
    
'search_form' => array(
      
'arguments' => array('form' => NULL),
    ),
  );
}
?>

Les formulaires au design personnalisé ont toujours un argument form. Puisque le gabarit n'a pas été spécifié, le point d'entrée sera vu comme une fonction de thème et non comme un gabarit. Une fonction de thème doit avoir un préfixe correspondant au thème qui l'a enregistré. phptemplate_* ne marchera pas. Aussi, avec la valeur précédente, la fonction de thème ressemblera à ceci :

<?php
function drop_search_form($form) {
  
$advanced '';
  
$simple '';
  foreach (
element_children($form) as $element) {
    if (
$element == 'advanced') {
      
$advanced .= drupal_render($form[$element]);
    }
    else {
      
$simple .= drupal_render($form[$element]);
    }
  }
  return 
$advanced $simple;
}
?>

La seule chose modifiée ici est le positionnement du formulaire de recherche avancé. 

  • Les sous-thèmes qui surchargent un formulaire enregistré dans leurs thèmes parents n'ont pas à redéclarer manuellement le formulaire. Rappelez-vous que l'enregistrement permet l'auto-découverte pour les couches situées au-dessus et que les sous-thèmes ne sont rien d'autre qu'une couche au-dessus des thèmes parents.
  • Ceci sera plus automatisé dans les version futures. Les développeurs sont conscient de la charge de travail que cela impose aux concepteurs de thèmes.

Manipulation manuelle

La manipulation manuelle du registre de thème est une fonctionnalité avancée. Vous pouvez en prendre connaissance en cliquant sur « Theme registry » dans le bloc fourni par le module Devel. Il peut également être retourné avec theme_get_registry.

A compléter...

(c'est la version anglaise qui indique : A compléter...)