Dojo et HCL Digital Experience :
HCL Digital Experience contient une instance du Toolkit Dojo, une bibliothèque JavaScript™ basée sur le Toolkit Dojo. Lors du développement de composants utilisant Dojo, vous devez connaître la façon dont le portail utilise Dojo, ainsi que les recommandations et restrictions liées à l'utilisation de Dojo.
- Dojo V1.9.x. Cette version est fournie dans sa propre application Web appelée Dojo_Resources. Vous pouvez la gérer dans WebSphere® Integrated Solutions Console. Par défaut, elle est déployée à la racine du contexte wps/portal_dojo. Le chemin d'accès aux fichiers Dojo V1.9.x est le suivant :
PortalServer_root/theme/wp.theme.dojo/installedApps/dojo.ear/dojo.war/V1.9
. - Dojo V1.7.x. Cette version est fournie dans sa propre application Web appelée Dojo_Resources. You can manage it in the WebSphere® Integrated Solutions Console. By default it is deployed at the context root wps/portal_dojo. Le chemin d'accès aux fichiers Dojo V1.7.x est le suivant :
PortalServer_root/theme/wp.theme.dojo/installedApps/dojo.ear/dojo.war/v1.7
. - Dojo V1.6.x. This version is packaged in its own web application named Dojo_Resources. You can manage it in the WebSphere® Integrated Solutions Console. By default it is deployed at the context root wps/portal_dojo. Le chemin d'accès aux fichiers Dojo V1.6.x est le suivant :
PortalServer_root/theme/wp.theme.dojo/installedApps/dojo.ear/dojo.war/v1.6
. - Dojo V1.4.x. This version is packaged in its own web application named Dojo_Resources. You can manage it in the WebSphere® Integrated Solutions Console. By default it is deployed at the context root /portal_dojo. Le chemin d'accès aux fichiers Dojo V1.4.x est le suivant :
PortalServer_root/theme/wp.theme.dojo/installedApps/dojo.ear/dojo.war/v1.4.3
. - Dojo V1.3.x. This version is packaged in its own web application named Dojo_Resources. You can manage it in the WebSphere® Integrated Solutions Console. By default it is deployed at the context root /portal_dojo. Le chemin d'accès aux fichiers Dojo V1.3.x est le suivant :
PortalServer_root/theme/wp.theme.dojo/installedApps/dojo.ear/dojo.war
. - Dojo V1.1.1. Cette version est fournie dans le répertoire
PortalServer_root/installer/wp.ear/installableApps/wps.ear/wps.war/themes/dojo/portal_dojo
PortalServer_root/installer/wp.ear/installableApps/wps_theme.ear/wps_theme.war/themes/dojo/portal_dojo
.
- Le thème de Portal 8.5 utilise Dojo V1.9.x par défaut dans HCL Digital Experience 8.5. Il s'agit de la seule version de Dojo prise en charge avec le thème de Portal 8.5.
- Le thème de Portal 8.0 utilise Dojo V1.7.x par défaut dans HCL Digital Experience 8.0. Il s'agit de la seule version de Dojo prise en charge avec le thème de Portal 8.0.
- Le thème de Portal 7.0.0.2 utilise Dojo V1.6.x par défaut dans HCL Digital Experience 7.0.0.2. Il s'agit de la seule version de Dojo prise en charge avec le thème de Portal 7.0.0.2.
- Le thème de Page Builder utilise Dojo V1.4.x par défaut dans HCL Digital Experience 7.0. Le thème de Page Builder est obsolète dans Portal 8.5 et ne sera plus pris en charge dans la prochaine édition.
- Le Toolkit Dojo fourni avec le portail sera mis à jour au fil du temps. Ce kit d'outils pourrait inclure des versions entièrement nouvelles de Dojo, ainsi que des correctifs spécifiques d'incidents. C'est le projet Dojo qui définit la compatibilité des futures versions de Dojo.
Où HCL HCL Digital Experience utilise Dojo
Le thème de Portal 8.5 utilise Dojo V1.9.x pour prendre en charge plusieurs portlets et composants d'interface utilisateur en mode édition. Les portlets et composants qui utilisent Dojo peuvent changer avec le temps. L'ensemble actuel de portlets qui utilise Dojo inclut les composants de l'interface utilisateur en mode édition pour les pages gérées, Centre de recherche, Résultats de recherches externes, Etiquetage et évaluations, Nuage d'étiquettes, Analyse de site actif, Liste des tâches unifiée, Portlet WidgetWrapper, Portlet d'affichage WCM, Bibliothèques de contenu Web, Abonnés Web Content, Syndicateurs Web Content, Planifications de flux, Portlet Web2Bookmarks et Boîte de dialogue CMIS Picker.
Utilisation de Dojo dans vos thèmes de portail personnalisés
Pour plus d'informations sur l'utilisation de Dojo dans les thèmes de portail personnalisés que vous créez, reportez-vous à la rubrique Création d'un thème.
- Thème de Portal 7.0.0.2, Dojo V1.6.x -> thème de Portal 8.0, Dojo V1.7.x : voir Mise à jour d'un thème Portal 7.0.0.2 pour utiliser Dojo 1.7.
- Thème de Page Builder, Dojo V1.4.x -> thème de Portal 7.0.0.2, Dojo V1.6.x : voir Mise à jour d'un thème de Page Builder pour utiliser Dojo 1.6.
- Dojo V1.3.x -> Dojo v1.4.x : voir Dojo et HCL Portal.wp7
- Dojo V1.1.x -> Dojo v1.3.x : voir Dojo et HCL Portal.wp7
Méthodes d'utilisation recommandées de Dojo
- Vous ne pouvez charger qu'une seule instance Dojo dans une page, et la règle actuelle de Dojo précise que le premier Dojo inclut dans la page prend la précédence. Donc :
- Dojo ne peut être chargé qu'une fois par espace nom. Vous pouvez charger plusieurs versions de Dojo dans la page à l'aide du support natif de Dojo pour les portées. Pour plus de détails, reportez-vous à la documentation de Dojo. Pour des raisons de performances, il est recommandé de charger une seule version de Dojo dans la page. Toutefois, les applications ou le thème peuvent charger des regroupements Dojo supplémentaires s'ils se rapportent uniquement aux espaces noms autres que ceux par défaut de Dojo. Vous devez vous assurer que les applications et portlets qui référencent Dojo dans une portée d'espaces noms particulière fonctionnent correctement avec la version de Dojo mappée sur cette portée.
- Des thèmes différents figurant dans le même portail peuvent utiliser des versions différentes de Dojo. Vous devez vous assurer que les portlets en cours d'exécution dans ces thèmes peuvent utiliser les deux versions de Dojo.
- Tous les portlets utilisant des widgets Dojo doivent appeler manuellement l'interpréteur Dojo lors du chargement. Le paramétrage de djConfig.parseOnLoad est sans effet. Sinon, aucun widget n'est analysé dans le portlet.
Tous les portlets doivent valider un élément de marquage pour l'interpréteur. L'élément de marquage ne doit exister que dans le DOM du portlet. Sinon, Dojo fait une analyse de la totalité du corps du document chaque fois que l'interpréteur est appelé sans élément de marquage. D'autres portlets pourraient être analysés deux ou trois fois générant ainsi un échec de l'interpréteur Dojo chaque fois qu'il est confronté à un widget déjà analysé.
Voici un exemple d'utilisation correcte :<script> dojo.addOnLoad( function () { dojo.parser.parse( "<%=namespace%>portletWidgetContainer" ); } ); </script> <div id="<%=namespace%>portletWidgetContainer"> <div dojoType="some.Widget"></div> </div>
- La classe
lotusui30dojo
est définie sur l'élément du corps dans les thèmes modularisés et ses fichiers CSS correspondants y sont liés également. Pour utiliser un thème différent dans un portlet particulier, ne modifiez pas les classes CSS de l'élément de corps depuis le portlet. Car cela aura une incidence sur tous les autres portlets et composants de thème qui utilisent des Dijits sur la page. Au lieu de cela, utilisez un noeud distinct dans le portlet afin de contenir tous les widgets utilisés par ce portlet. Attribuez ensuite un nom de classe différent au thème sur le noeud du conteneur dans le portlet. - Il est important de noter que le placement de la classe du thème (par exemple,
lotusui30dojo
,soria
) est vital pour que le thème soit affiché correctement dans des composants Dijit. Si un composant Dijit crée des éléments en tant qu'enfants directs de l'élément de corps, à la place de ou en plus de la même place dans le DOM auquel le composant Dijit a été attaché, il est alors important d'attribuer de façon explicite le nom de classe. Le nom de classe est affecté pour le thème secondaire au noeud DOM qui est un enfant direct du corps, et ceci en plus du noeud DOM contenant des widgets du portlet. Par exemple:<body class="tundra"> ... <!-- Portlet A --> <div class="wpsPortletBody"> <!-- Contents of this portlet --> <div class="soria"> <!-- Any Dijits here will use the soria theme instead of tundra --> <button class="dijit dijitReset dijitLeft dijitInline dijitDropDownButton"> ... </button> </div> </div> ... <!-- Portlet B --> <div class="wpsPortletBody"> <!-- Any Dijits created here will use the tundra theme --> ... </div> <!-- This table node was created for the dijit.Menu component as part of the dijit.form.DropDownButton from Portlet A --> <table class="dijit dijitMenu dijitReset dijitMenuTable soria"> <!-- This menu will use the soria theme instead of tundra, but needs to have it explicitly assigned since none of its ancestors have the soria class applied --> ... </table> </body>
Dans cet exemple, lorsque le Portlet crée un dijit.form.DropDownButton, le code servant à créer ce widget permet également de créer un composant de menu et un noeud DOM sous le corps. Mais le code n'attribue pas de classe CSS à ce noeud DOM. Si aucune autre action n'est menée après la création de DropDownButton par le portlet, DropDownButton utilise alors la classe
soria
. Mais le menu qui s'affiche au moment où l'utilisateur clique sur le bouton utilise la classetundra
. Dans de pareils cas, il est important de définir explicitement la classesoria
dans le noeud DOM contenant le menu. - Le cas échéant, chargez le code Javascript à la fin du marquage du thème lorsque le reste de la page est rendu, avec le contenu de page lui-même. La page initiale peut alors s'afficher rapidement sans bloquer le traitement des requêtes de grands fichiers JavaScript, notamment des fichiers de couche personnalisée. Toutefois, fournissez des fonctions Dojo de base dans la section d'en-tête de la page, afin que les composants de l'interface utilisateur tels que les portlets et les widgets puissent accéder à ces fonctions de base.
- S'agissant de charger les ressources à la fin du thème plutôt que de les charger toutes dans la section d'en tête, la pratique recommandée est d'inclure les instructions
dojo.require
des applications de portlet, des widgets et autres composants d'interface utilisateur juste avant que les objets ou le code des modules qu'ils chargent ne soient utilisés. Cela veut dire que si le code n'est utilisé qu'après le chargement de la page, par exemple par le biais d'un gestionnaire de chargement enregistré à l'aide dedojo.addOnLoad
, l'instructiondojo.require
est mieux traitée si elle figure dans le gestionnaire de chargement lui-même. Le thème peut alors charger d'autres ressources à la fin de la page dans les fichiers de couche quand tous les composants de la page ont été inclus. Au final, si le thème a déjà fourni ces modules dans les fichiers de couche à la fin du balisage, les instructionsdojo.require
sont traitées immédiatement lors du déclenchement des descripteurs de chargement. Ceci évite également les requête inutiles des modules que le thème charge mais qui ne sont pas encore chargés quand le composant d'interface utilisateur est inclus dans le marquage de la page.
Restriction d'utilisation de Dojo
- Vous ne pouvez charger qu'une seule instance Dojo dans une page.
- Ne comptez pas effectuer vos propres mises à jour sur le module d'offre groupée Dojo. Une prise en charge d'HCL Digital Experience est probable pour la mise à jour de fichiers individuels au fil du temps, et pourrait même remplacer le module complet.