Modules différés et non différés

L'infrastructure de module permet à un profil de déterminer si un module particulier doit être différé. Par défaut, un module est chargé lors du chargement de la page initiale mais les modules spécifiés comme modules différés sont chargés après le chargement de la page.

Les modules non différés sont activés à chaque fois qu'une demande de page est envoyée au servlet de portail, ce qui entraîne une actualisation complète de la page. Utilisez un module JavaScript côté client pour charger les ressources associées aux modules différés sur demande. Par exemple, chargez les modules différés lorsque vous entrez en mode édition pour une page. Les ressources qui ne sont pas requises dans le mode édition peuvent être chargées avec lenteur lorsque la page devient en mode édition. Pour plus d'informations, voir Spécification de l'API JavaScript i$.

Remarque : Si vous ouvrez le mode Edition tout en utilisant le profil différé disponible par défaut, l'erreur suivante s'affiche lorsque vous utilisez une console JavaScript : dojo.back.init() must be called before the DOM has loaded. If using xdomain loading or djConfig.debugAtAllCosts, include dojo.back in a build layer. Cette erreur est provoquée par Dojo car le package dojo.back est chargé de façon différée. Ce chemin de code n'est utilisé que par les anciens navigateurs qui ne sont plus pris en charge. Cette erreur JavaScript n'a aucun effet sur la fonction.

Si un module non différé requiert un module différé, la structure de combinaison côté serveur promeut le module différé en module non différé. Le module promu est ensuite chargé lors du processus d'affichage initial de la page. Le module n'est pas différé, et toutes ses contributions à chaque point d'extension sont affichées en mode affichage. De plus, ces dernières ne sont pas incluses lorsque des modules différés doivent être chargés ultérieurement.

Etant donné que les modules différés sont chargés séparément après le chargement de la page, les types de ressource pouvant être différés constituent obligatoirement un sous-ensemble des ressources pouvant être chargées. Les éléments CSS, le code JavaScript et le marquage peuvent être différés. Par conséquent, les règles ci-après définissent le moment auquel les contributions à divers emplacements sont chargées pour les modules différés.
  • Les contributions CSS à la zone head sont différées puis insérées dans l'élément <head>, si nécessaire, avec l'élément <link>.
  • La configuration JavaScript, statique et dynamique pour les zones head et config, est différée et chargée en tant que JavaScript.
  • Les contributions de code JavaScript statique aux zones head et config sont différées et chargées en tant que JavaScript.
  • Les contributions de marquage sont chargées lentement par le biais de la demande de données de marquage pour tous les modules différés qui contribuent à la section de marquage config ou head. Ces données sont insérées dans la page à l'emplacement approprié en fonction de l'emplacement de la zone défini par le modèle de thème.
Remarque : Etant donné que les contributions de marquage peuvent être chargées lentement lorsqu'un module est différé, certaines limites s'appliquent au marquage inséré dynamiquement à l'aide de JavaScript. Les éléments de script, par exemple, ne s'exécutent pas lorsqu'ils sont insérés dans le marquage en tant que chaîne HTML. Les modules qui peuvent être différés ne doivent pas générer d'éléments de script dans leur contribution de marquage à la zone config, sauf s'ils sont utilisés à d'autres fins sémantiques. Par exemple pour définir l'attribut type sur une valeur inconnue pour le navigateur client. L'infrastructure ne recherche ni ne traite les marquages générant des effets secondaires ou un comportement inattendu. Il revient au développeur du module de traiter les comportements inattendus.

N'utilisez pas d'attributs dépendants des requêtes pour le rendu des portails, car il arrive que ces attributs ne soient pas disponibles. Par exemple, en mode différé, le contexte de rendu n'est pas disponible.