Sling Mappings++ Grandes listes et tableaux de mappage / Blogs / Perficient

Comme tous les développeurs AEM le savent, AEM, et plus encore le JCR sous-jacent, a des limites sur le nombre d’enfants qu’un parent seul peut avoir avant que nous commencions à constater des problèmes de performances. D’abord dans l’interface utilisateur, puis, de manière plus critique, dans la capacité de rechercher et de gérer eux-mêmes les nœuds de contenu. Lors de la conception d’un nouveau site Web AEM, cela peut être planifié. Toutefois, lors d’une migration, il peut être nécessaire de conserver intacts les liens existants, ce qui peut nous mettre dans une situation où un grand appartement liste, du moins telle qu’elle est exposée à l’utilisateur final, est inévitable.

Dans cet article, je n’aborderai pas la question de savoir si 500, 1 000 ou 10 000 enfants commenceraient à avoir des problèmes de performance (même si j’ai certainement des opinions ici), et je me concentrerai plutôt sur les moyens de permettre à un parent seul, avoir l’air d’avoir beaucoup plus que le nombre maximum d’enfants.

Entrez les mappages d’élingues

Désormais, les mappages Sling ne sont pas nouveaux pour la plupart et sont couramment utilisés pour des choses comme supprimer le préfixe initial (/content/) des URL sortantes, mais ces mappages ont une puissance supplémentaire inexploitée que la documentation, à mon avis, ne fait pas clairement. souligner. Avant de commencer, parlons de quelques caractéristiques clés des mappages d’élingues dans leur ensemble.

Les mappages Sling sont configurés sur la base d’expressions régulières et sont souvent hérités par les noms de nœuds eux-mêmes, dans /etc/map. Au sein de chaque nœud, il existe des propriétés facultatives que nous pouvons ajouter pour définir le comportement des mappages. Par exemple, si nous souhaitons introduire une expression régulière plus complexe, nous ne pouvons pas nous fier uniquement au nom du nœud (les caractères requis pour les mappages d’expressions régulières ne peuvent pas être utilisés comme nom de nœud). Cela signifie que lorsque nous devons définir un mappage qui ne s’aligne PAS avec le nom du nœud, nous pouvons insérer la propriété suivante (valeur unique uniquement) :

Maintenant, ce qui précède est un exemple relativement simple, mais nous sommes ici pour en savoir plus sur les mappages, pas sur les expressions régulières. Notez que j’utilise ici un groupe de capture – plusieurs groupes de capture sont certainement également pris en charge, mais pour faciliter cet article, je reste assez simple.

L’autre élément à noter ci-dessus est que j’ai ajouté ce nœud en tant que nœud racine dans l’arborescence /etc/map/localhost. En tant que tel, le mappage commence à partir de l’élément racine. Si nous devions structurer le nœud /etc/map différemment, le point de départ de cette expression régulière changerait également, par exemple :

Dans le scénario ci-dessus, nous structurerions le sling:match en conséquence, car les nœuds content et wknd auraient déjà été comparés :

Eh bien, c’est la moitié du problème, c’est d’être capable de capturer la demande entrante. Ensuite, il faut le mapper à une autre ressource interne. C’est là que la « magie » entre en jeu : sur le même nœud, ajoutez une propriété supplémentaire, sling:internalRedirect, comme suit :

Dans ce qui précède, nous recherchons simplement du contenu au même endroit où il a été demandé. Le $1 dans internalRedirect fait référence au (.*) de la propriété sling:match et dit que tout ce qui y correspond doit d’abord regarder l’emplacement demandé pour trouver la ressource, techniquement parlant, nous n’avons pas vraiment quoi que ce soit cartographié à ce stade. indiquer. Maintenant, que se passe-t-il si la section magazine ci-dessus est un blog de longue date, dont toutes les URL sont publiées sous la même racine /magazine. Organisé en 1:1 avec la structure JCR, cela serait vite préoccupant ! C’est là que la prise en charge ARRAY, souvent négligée, de internalRedirect vient sauver la situation. À partir de là, nous pouvons proposer d’autres emplacements pour rechercher la même page. Par exemple, si nous devions archiver les publications sur une base annuelle, comme en 2023, les publications vivraient dans la structure JCR /content/wknd/us/en/magazine/2023/, tout en étant accessibles au public toujours sous /content/ wknd/us/en/magazine/, nous pourrions configurer cela en utilisant le tableau « internalRedirect », comme suit :

Désormais, lorsqu’une requête correspond, elle recherchera d’abord dans le dossier racine du magazine, et si elle n’y trouve pas de ressource, elle recherchera le dossier 2023, et ainsi de suite jusqu’à ce que tous les éléments du tableau aient été recherchés. Il effectue une recherche de haut en bas, ce qui signifie que l’ordre est important, surtout si des nœuds du même nom sont attendus. Si la liste entière est épuisée et qu’aucune ressource n’est trouvée, le comportement 404 normal est observé.

Supposons maintenant que nous ayons le contenu suivant (notez les dossiers 2023 et 2024 ajoutés, avec les enfants) :

Avec le mappage avancé appliqué, nous devrions pouvoir accéder directement aux fichiers « san-diego-surf-2023 » et « san-diego-surf-2024 » dans le dossier /magazine. Testons-le !

Génial. Nous accédons au contenu sans utiliser le dossier « 2023 » dans l’URL !

Super! Eh bien, cela résout le problème de l’accès au contenu, cependant, si nous regardons une page qui renvoie à ce contenu, nous constatons toujours un problème….

On dirait que nous avons encore une autre pièce du puzzle à résoudre. Une autre chose importante à savoir sur les expressions régulières (avec les groupes de capture) est que lorsqu’elles sont incluses dans un mappage sling, elles ne fonctionneront que dans une seule direction. Puisque nous l’avons configuré pour capturer du côté de la demande (correspondance), il ne gérera que la logique de traitement de la demande. Afin de créer une réécriture des URL sortantes, nous devrons également gérer le mappage inverse. Pour cela, j’utilise le suffixe « -reverse » avec le même nom de nœud que le mappage initial par souci de cohérence.

L’étape suivante consiste donc à copier le nœud que nous venons de créer et à le coller en tant que frère (sous le même parent). Nous inverserons ensuite la logique des expressions régulières pour avoir des groupes de capture dans la propriété « sling:internalRedirect » et les références dans la propriété de mappage sling, comme suit :

Cela se comporte à peu près de la même manière que l’autre nœud de mappage, mais comme nous avons remplacé la logique de correspondance par l’expression régulière, elle sera désormais également appliquée dans la réécriture d’URL ou dans le mappage de sling de sortie.

Revenons maintenant à nos liens vers ce contenu, et….

Nous sommes en or ! Le contenu est hébergé sous plusieurs nœuds JCR tout en étant exposé sous un seul parent à l’utilisateur final.

Je voudrais ajouter un avertissement ici : bien que cette méthode soit certainement une solution de contournement appropriée, une implémentation beaucoup plus souhaitable aurait la structure JCR correspondant plus étroitement au plan du site attendu.

J’espère que cette démonstration rapide vous a été utile !

Référence: