Présentation du regroupeur de ressources

Lorsque la page s'affiche, le regroupeur de ressources traite tous les modules provenant du profil.

L'infrastructure de module est basée sur les modules qui sont spécifiés dans un profil, et un profil est affecté à une page. Elle prend toutes les ressources issues des modules et les regroupe/combine, dans un nombre le plus bas possible d'URI à lier sur la page afin d'optimiser les performances. Les modules non différés sont séparés des modules différés, par conséquent, deux ensembles d'URI sont obtenus.

Remarque : Vous pouvez activer le débogage distant pour diviser chaque ressource comme sa propre demande non compressée individuelle à des fins de débogage. Pour plus d'informations sur l'activation et la désactivation du débogage distant, voir Utilitaires d'analyseur d'optimisation de thème.

Pour plus d'informations sur la création de modules et de profils, voir Ecriture de modules. Pour plus d'informations sur l'affectation d'un profil, voir Spécification de profils.

Regroupement de ressources pour les portlets

Outre le traitement des modules issus du profil, le regroupeur de ressources peut également traiter tous les modules issus des dépendances de fonction de tous les portlets présents sur une page. Le regroupeur de ressources traite les modules de portlet des thèmes dont la propriété metadata resourceaggregation.autoLoadPortletCapabilities a pour valeur true. Pour plus d'informations sur la définition de cet indicateur de métadonnées, voir Modification du chargement automatique des fonctions de portlet.

Pour plus d'informations sur la spécification des dépendances de fonction de portlet, voir Dépendances de module dans les portlets.

Lorsque le chargement automatique des fonctions de portlet est activé, le regroupeur de ressources traite également tous les modules issus de toutes les dépendances de fonction de tous les portlets présents sur la page. Il les traite en même temps que les modules issus du profil. Si un même module ou une même sous-contribution est détecté plus d'une fois, le traitement s'effectue du premier au dernier dans l'ordre suivant :

section non différée du profil
section non différés des portlets
section différée du profil
section différée des portlets

Par exemple, si un profil utilise la section Dojo différée alors qu'un portlet utilise la section Dojo non différée, Dojo charge la section non différée dans le cadre de la demande ResourceAggregator combinée pour les portlets.

Lorsque toutes les informations sont triées dans l'un des quatre compartiments, le regroupeur de ressources prend toutes les ressources issues des modules de chaque compartiment et les regroupe/combine dans un nombre le plus bas possible d'URI à lier sur la page. Il existe quatre groupes d'URI ou jusqu'à deux fois plus d'URI ou de demandes pour la page en comparaison avec un scénario où le chargement automatique des fonctions de portlet est désactivé.

Performances

Le chargement automatique facilite l'utilisation d'un système. Les utilisateurs peuvent choisir n'importe quel portlet sur une page, si les portlets déclarent leurs fonctions, quel que soit le thème ou le profil. Un nombre moins élevé de profils s'avère nécessaire, et chaque profil peut être de plus petite taille.

Le chargement automatique utilise la mise en cache au niveau du client et du serveur, par conséquent, les performances de votre portail sont presque identiques à celles obtenues lorsque le chargement automatique est désactivé. Vous pouvez également diminuer la baisse légère des performances en ajoutant des modules au thème. Plus un module est commun ou partagé, plus il est judicieux de l'inclure dans un profil. Par exemple, si un module est souvent utilisé par des portlets sur un grand nombre de pages, indiquez-le dans le profil de manière à permettre sa mise en cache avec les URI de profil. Les URI de profil ne sont pas fréquemment modifiés et ils demeurent dans le cache.

API ResourceCombinerService

Lorsqu'un portlet doit établir un lien avec ses propres ressources spécifiques aux applications, dans le groupe de correctifs CF03, cette opération est possible via l'API publique ResourceCombinerService. Auparavant, ces ressources devaient être liées individuellement. L'API ResourceCombinerService peut être appelée pour combiner des ressources dans un seul URI optimisé afin d'obtenir des performances optimales. Pour plus d'informations, voir l'API publique ResourceCombinerService dans la documentation JavaDoc sur l'API.

L'API est aussi flexible que la syntaxe de définition de module de portail pour prendre en charge toutes les possibilités d'URI. Elle peut ainsi prendre en charge les URI de contenu HCL Web Content Manager, les classes d'unités et les équations pour les appareils mobiles, les environnements locaux de langue pour les systèmes de langue naturelle, un type de débogage pour la version non compressée des ressources et un type de RTL pour les langues bidirectionnelles.

Le portlet peut appeler l'API lors du traitement de portlet, comme dans doHead pour les contributions Head ou doRender pour les contributions Body. Le portlet doit gérer la liaison dynamique des URI dans la section head ou body de manière à pouvoir gérer l'ordre et le groupement des ressources. Le portlet doit gérer les en-têtes de cache au sein des sources de données. Les en-têtes de cache par défaut sont définis dans le cadre des paramètres REP IBM® WebSphere® Application Server globaux. Il s'agit de Cache-Control: public, max-age=86400.

Dans la plupart des cas, la liste renvoyée par l'API getCombinedURI contient un URI. Dans de rares cas, par exemple lorsque la taille de feuille de style en cascade est limitée dans Internet Explorer, plusieurs URI peuvent être renvoyés. Le portlet doit procéder au codage pour gérer 1 à n.

Remarque : Vous devez utiliser cette API uniquement avec des ressources spécifiques aux applications. Les ressources partagées non spécifiques aux applications doivent être définies en tant que modules ou fonctions et spécifiées comme dépendances de module de portlet, à l'aide des préférences de portlet de fonction. Cette méthode permet d'optimiser les performances. Elle permet de garantir que plusieurs portlets présents sur une page ne chargent pas les mêmes ressources. En outre, elle contrôle l'ordre de chargement des ressources, sachant que les ressources partagées doivent être chargées avant les ressources spécifiques aux applications.