Portal Mapper est un module concu pour JCMS.
Son but : Fournir un mécanisme alternatif pour l’attribution des Portails pour l’affichage en Front Office.
J’ai constaté, pendant la réalisation de divers projets mettant en oeuvre JCMS, la nécessité d’avoir recours à l’API, lorsqu’il s’agit de personnaliser le comportement d’attribution des Portails.
Ce module est (le début) de la concrétisation de ce constat : Fournir une interface utilisateur pratique et intuitive, permettant à un utilisateur qui n’a pas le profil développeur de personnaliser l’attribution des Portails de JCMS. L’ergonomie générale est sûrement mauvaise : Il reste des améliorations à apporter, des bugs à corriger, des incohérences…
Une nouvelle règle (Scheduled Rule) et de nouvelles options. De nombreuses corrections également. Voir le changelog en fin de page.
Les Portails sont affectés selon le mécanisme suivant :
Pour afficher une catégorie, JCMS vérifie si un Portail est affecté à celle-ci.
Sinon, JCMS recherche un Portail affecté à une catégorie parente.
Pour afficher une publication, il est nécessaire qu’un Porlet Selection soit présent sur le Portail.
Si le comportement souhaité le nécessite, on peut aisément détourner ce comportement en utilisant l’API, et créer un PortalFilter, pour modifier de façon programmatique l’attribution des Portails.
Portal Mapper fournit une mécanique différente, basé sur la création par l’utilisateur d’un ensemble de règles.
Ces règles sont de différents type, en fonction du besoin, et peuvent être combinées grâce à des liens logiques (ET, OU, NON…).
Une interface d’administration accessible depuis le back office permet la création des règles à la volée, sans aucune modification de code.
Il est possible cependant pour un développeur d’utiliser les objets de Portal Mapper pour des fonctionnalités encore plus spécifiques.
Portal Mapper s’appuie sur 3 types d’objets :
Objet Portal Rule : Défini un Portail à sélectionner, et contient 1 ou plusieurs objet(s) Group Rule. L’ensemble des Group Rules composant un Rule sont associés par un opérateur OR ou AND.
Objet Group Rule : Contient 1 ou plusieurs objet(s) Rule. L’ensemble des Rules composant un Group Rule sont associés par un opérateur OR ou AND.
Rule : Contient la définition d’une règle. Il existe plusieurs types d’objet Rule.
Voici les différents types d’objets Rule disponibles :
Publication Rule : Teste le contenu Full Display ou les contenus de la catégorie courante
Match Rule : Teste la catégorie courante
Parent Rule : Teste la catégorie parente de la catégorie courante
Ancestor Rule : Teste les ancêtres de la catégorie courante
Leaf Rule : Teste si la catégorie courante est une feuille
Node Rule : Teste si la catégorie courante est un noeud
Level Rule : Teste le niveau de la catégorie courante
Scheduled Rule : Permet de définir une plage de dates / heures. Utile pour afficher un portail spécifique pour une offre limitées dans le temps.
Déployer le module Portal Mapper comme décrit dans la documentation de JCMS.
Se connecter au Back Office de JCMS avec les droits d’administrateur central.
Se rendre dans l’espace d’administration. Dans le bloc "Organisation", le lien "Portal Mapper" conduit à la page de configuration du plugin Portal Mapper
Commencer par créer un objet Portal Rule . Sélectionner un Portail.
Ensuite, créer un objet Group Rule .
Puis, créer une règle avec un objet Rule , en choisissant au préalable le type de règle adéquat. Chaque Group Rule peut contenir autant de Rules que nécessaire.
Il en va de même pour les objets Portal Rules.
Les Group Rules sont liés par un opérateur logique paramétrable au niveau du Portal Rule les contenants.
Avec l’opérateur AND (ET logique), tous les Group Rules doivent être vérifiés pour que le Portal Rule le soit aussi.
Avec l’opérateur OR (OU logique), si l’un des Group Rule est vérifié, le Portal Rule l’est également.
De même, les Rules sont liés par un opérateur logique paramétrable au niveau du Group Rule les contenants.
Par défaut, les Group Rule sont liés ensemble par l’opérateur OR, les Rules par l’opérateur AND.
Les objets Portal Rule, Group Rule et Rule peuvent être inversé en sélectionnant l’option ad hoc.
Affichage du portail courant :
Affiche le portail courant en Front Office, afin de faciliter la vérification des règles
Portails natifs prioritaires :
Donne la priorité à un Portail si il est affecté à une catégorie (Portail "Natif") Si une règle est effective dans le même contexte, le Portail Natif sera prioritaire, sauf s’il porte le flag overrideNative
Forcer le rafraîchissement :
A chaque refresh en Front Office, les règles seront totalement relues depuis les objets Type de contenus. Conception
Les règles sont décrites à l’aide d’un modèle de données simple qui s’appuie Types de Contenus JCMS.
Le moteur de règles de PortalMapper s’appuie sur le pattern "Specification", dont je ne suis pas l’inventeur. Cependant je l’ai adapté aux besoins de PortalMapper, afin notamment de le rendre dynamique, et il est probable que certaines portions de code soient peu académiques pour un Guru Java :)
Cette règle permet de définir une plage temporelle. La règle est valide si l’on se situe dans l’intervalle de temps défini. Permet d’attribuer un portail pendant une plage donnée.
Permet de définir le contexte d’application de la règle : Contexte d’une catégorie, Contexte d’une publication ou Tous
Permet de matcher la catégorie cible en plus de ses descendantes, évite l’utilisation d’une règle Match Rule supplémentaire
Affichage des règles dans la vue TreeView plus pertinent : Affichage des portails natifs, détails des règles
Liens depuis l’admin vers Tree View
Liens depuis / vers Tree View dans la vue Portal Mapper
Operateur Not retiré, redondance avec option Invert
Les conteneurs PortalItem / GroupItem sont dorénavant dérivés de PortalRuleItem (Comme tout les autres conteneurs)
Refactoring, rationnalisation
Correction de plusieurs bugs
JCMS appartient à la société Jalios, dont je salue les collaborateurs :)
Jalios n’est pas responsable du développement de ce module.