(version de Jelix supportée 1.1.x)
En PHP, si une classe ou API existante vous plait mais que vous souhaitez y apporter votre touche personnelle vous inclurez cette dernière et la surchargerez pour éviter d'y toucher.
Exactement le même principe s'applique avec les modules Jelix. On parlera alors “d'overload”.
Un module n'étant pas une simple classe (mais composé de contrôleurs, daos, forms, template, zones, classes, fichiers de traductions) tout ne peut être surchargé.
Qu'est ce qui peut faire l'objet d'overload ?
Avantages de l'“Overload” :
Ainsi prenons comme exemple concret le module Jelix, jCommunity, et voyons ce que l'on peut en tirer.
jCommunity est le module de gestion des utilisateurs pour tout type de site web. Il inclut une gestion complète du workflow de :
Question
Ok c'est cool mais je veux adapter le rendu des templates de jCommunity aux thèmes de mon site. comment faire ?
Réponse
Par défaut le nom du thème se nomme default. Ainsi donc pour surcharger un template on placera tout simplement la version modifiée de ce dernier dans le dossier var/themes/default/jcommunity
Ainsi quand Jelix appellera le template du module, il ira voir d'abord si une version existe dans le dossier des thèmes et l'utilisera.
Comparer : le template de la page de consultation d'un membre :
Question
La table jCommunity ne contient pas assez d'informations pour gérer mes utilisateurs, comment “étendre” celle-ci ?
Réponse
Copions la Dao jcommunity/dao/user.dao.xml dans le dossier var/overload/jcommunity/daos
Changeons à l'intérieur tout ce dont on a besoin :
tout cela en respectant à minima le nom des méthodes existantes dans la DAO d'origine.
Comparer : la Dao account.dao.xml :
3) Overload de forms :
Question : Le formulaire gérant les données des utilisateurs est trop léger à votre goût ?
Réponse :
Qu'à cela ne tienne on crée une copie du forms jcommunity/forms/account.form.xml dans le dossier var/overload/jcommunity/forms Ensuite on y rajoute les champs qu'il nous sied de voir afficher (correspondant à notre DAO modifiée). Comme précédemment Jelix ira voir d'abord si un forms existe dans ce dossier.
Comparer : le Forms account.forms.xml :
Ok tout fonctionne nickel
On a pu tout surcharger comme souhaité
Subsiste un dernier détail, après la surcharge de la couche de présentation,
on a besoin d'étendre la couche fonctionnelle.
Et cela est rendu possible grâce aux events Jelix.
Par exemple, lors de l'inscription d'un membre, je souhaite vérifier que celui ci n'est pas banni du site.
Pour cela jCommunity, génère un événement jcommunity_registration_prepare_save, envoyé juste avant l'enregistrement de l'e-mail du membre.
En répondant à cet événement (via un listener) on est en mesure de procéder à cette vérification puis retourner au module jCommunity la réponse, positive ou non. (petit rappel sur les Events Jelix dans un article précédent )
Ainsi, lors de l'appel à jCommunity, et grâce aux divers orverload, ce sont bien vos propres ressources qui sont utilisées, tout en exploitant pleinement le core/workflow de jCommunity.