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

Fichiers inclus de traitement de pages

Référence en anglais sur drupal.org : 26 Avril 2008 - 14h01


Le système de menu introduit dans Drupal 6 supporte également le chargement conditionnel d'un fichier inclus pour chaque élément de menu. Cela permet aux développeurs de modules d'isoler leurs fonctions de manipulations de page dans des fichiers annexes qui ne seront chargés qu'en cas de besoin. Dans beaucoup de modules la majorité du code est constitué de traitement de pages, mais pour une requête de page donnée un seul page handler est appelé dans Drupal. Placer ces fonctions dans des fichiers conditionnels peut éviter une utilisation de ressources pour des fonctions qui ne seront pas utilisées.

Fichiers inclus pour traitement de pages

Pour indiquer à Drupal l'existence d'un traitement de page situé dans un fichier inclus, utilisez la clé file. Par exemple :

<?php
  $items
['admin'] = array(
    
'title' => 'Administer',
    
'access arguments' => array('access administration pages'),
    
'page callback' => 'system_main_admin_page',
    
'weight' => 9,
    
'file' => 'system.admin.inc',
  );
?>

La directive précédente, prise dans system_menu(), indique à Drupal d'inclure le fichier system.administrateur.inc, situé dans le même dossier que le fichier system.module, avant d'appeler system_main_administrateur_page(). Cette fonction system_main_administrateur_page() peut être placée dans le fichier system.administrateur.inc et elle n'aura pas à être parsée à moins qu'on en ait besoin.

Form page handlers

Un grand nombre de page handlers sont juste des appels à drupal_get_form(), avec l'ID du formulaire de la page comme argument callback. C'est notamment le cas pour les pages de configuration système. drupal_get_form() est toujours disponible, bien sûr, mais la fonction callback de formulaire peut être placée dans un fichier inclus. N'oubliez pas de déplacer la fonction de déclaration du formulaire ainsi que le code de l'envoi et de la validation, puisqu'ils ne seront nécessaires pour la page que si le formulaire est chargé.

Page handlers fournis par d'autres modules

Dans certains cas, vous voudrez utiliser un callback de page fourni par un autre module. Dans ce cas, vous devrez également spécifier une clé file path, comme celle-ci (prise dans node_menu() :

<?php
  $items
['admin/content'] = array(
    
'title' => 'Content management',
    
'description' => "Manage your site's content.",
    
'position' => 'left',
    
'weight' => -10,
    
'page callback' => 'system_admin_menu_block_page',
    
'access arguments' => array('administer site configuration'),
    
'file' => 'system.admin.inc',
    
'file path' => drupal_get_path('module''system'),
  );
?>

Drupal incluera le fichier situé dans "file path"/"fichier", avec une chemin de fichier basé sur le dossier de base de Drupal. Si aucun chemin de fichier n'est indiqué, le chemin du module déclarant le callback sera utilisé. Comme ceci :

<?php
example_menu
() {
  
$items['example/path'] = array(
    
'page callback' => 'example_page',
    
'file' => 'example.pages.inc',
    
'file path' => drupal_get_path('module''example'),
  );
}
?>

La clé file path dans l'exemple ci-dessus est inutile, puisque Drupal la déclare par défaut.

Héritage

Si un menu ne déclare pas de page callback, alors il héritera du callback de son parent. S'il le fait, il héritera également des directives fichier de son parent. Puisqu'elles définissent comment Drupal doit accéder à la fonction callback, cela semble logique.

Bonnes pratiques

Les développeurs sont libres de répartir les traitements de page pour leurs modules comme ils le veulent. Cependant, les normes et conseils suivants sont recommandés:

  • Tout module qui comporte plus de 50 lignes de code environ pour une fonction de traitement de page (y compris, le cas échéant, les fonctions de traitement de formulaire) devrait être scindé dans un fichier séparé. Cela réduit la charge de travail pour PHP lorsqu'il charge les modules et, par conséquent, accélère chaque requête sur le site.
  • Les fichiers inclus devraient être nommés sur le modèle nomdemodule.clé.incnomdemodule est le nom du module et clé est un descriptif, en un seul mot, pour le type de traitement de page que le fichier contient.
  • Pour beaucoup de modules, diviser les traitements de pages en deux fichiers - example.administrateur.inc (pour les pages administrateur seulement) et example.pages.inc (pour les pages accessibles aux non-administrateurs) - est suffisant, et c'est la pratique conseillée. Si un module n'a pas de pages non-administrateur, il aura un simple fichier example.administrateur.inc.file. Si un module n'a pas de pages administrateurs-seulement, il aura juste un simple fichier example.pages.inc.
  • Les modules qui ont un grand nombre de traitements de page pourront pousser la séparation en fichiers plus loin encore. Dans ce cas, chaque fichier devra logiquement être groupé par fonction (par exemple, les pages d'administration relatives au theming, les pages d'administration relatives à la connexion, d'autres pages d'administration, les pages accessibles aux utilisateurs) et clairement signalées. Souvenez-vous que subdiviser les fichiers complique la maintenance, et un seul fichier inclus est chargé, indépendamment du degré de séparation des fonctions de traitement.