Show Menu
SUJETS×

Développement sur AEM – Conseils et meilleures pratiques

Conseils pour l’utilisation des modèles et des composants

Les composants et les modèles AEM représentent un ensemble d’outils très puissants. Ils peuvent être utilisés par les développeurs afin de fournir aux utilisateurs, éditeurs et administrateurs de sites web la capacité d’adapter leurs sites web en fonction de l’évolution des besoins de l’entreprise (agilité du contenu) tout en conservant la mise en page uniforme des sites (protection de la marque).
Pour une personne chargée d’un site web ou d’un ensemble de sites web (par exemple, dans une succursale d’une entreprise globale), il est souvent difficile d’introduire un nouveau type de présentation de contenu sur sess sites web.
Supposons qu’il soit nécessaire d’ajouter sur les sites web une page de liste d’actualités qui répertorie des extraits d’autres articles déjà publiés. La page doit avoir la même conception et structure que le reste du site web.
La méthode recommandée pour y arriver consiste à :
  • réutiliser un modèle existant pour créer un type de page ; Le modèle définit la structure de page dans les grandes lignes (éléments de navigation, volets, etc.), qui est ensuite peaufinée par sa conception (CSS, graphismes).
  • utiliser le système de paragraphe (parsys/iparsys) sur les nouvelles pages.
  • Définissez le droit d’accès au mode Création des systèmes de paragraphe, afin que seules les personnes autorisées (généralement l’administrateur) puissent les modifier.
  • Définissez les composants autorisés dans le système de paragraphe donné afin que les éditeurs puissent ensuite définir les composants requis sur la page. Dans notre exemple, il peut s’agir d’un composant de liste, qui peut parcourir une sous-arborescence de pages et extraire des informations selon des règles prédéfinies.
  • Les éditeurs ajoutent et configurent les composants autorisés, sur les pages dont ils ont la charge, afin de fournir la fonctionnalité demandée (information) à l’entreprise.
Cela illustre comment cette approche permet aux administrateurs et aux utilisateurs contribuant au site web de répondre aux besoins de leur entreprise rapidement, sans impliquer les équipes de développement. Les méthodes alternatives, telles que la création d’un modèle, sont généralement coûteuses, car elles requièrent un processus de gestion de modification et la participation de l’équipe de développement. Cela rend le processus beaucoup plus long et coûteux.
Les développeurs des systèmes basés sur AEM doivent donc utiliser :
  • des modèles et le contrôle d’accès à la conception de système de paragraphe pour assurer l’uniformité et protéger la marque ;
  • le système de paragraphe, y compris ses options de configuration pour plus de souplesse.
Les règles générales suivantes sont pertinentes pour les développeurs dans la majorité des projets habituels :
  • Garder un petit nombre de modèles, correspondant au nombre de structures de pages fondamentalement différentes sur les sites web.
  • Fournir la souplesse et les capacités de configuration requises à vos composants personnalisés.
  • Optimiser l’usage de la puissance et de la souplesse du système de paragraphe AEM : les composants parsys et iparsys.

Personnalisation des composants et d’autres éléments

Lors de la création de vos propres composants ou de la personnalisation d’un composant existant, il est souvent plus simple (et plus sûr) de recycler les définitions existantes. Les mêmes principes s’appliquent également à d’autres éléments dans AEM, par exemple le gestionnaire d’erreurs.
Cela peut être effectué en copiant et en remplaçant la définition existante. In other words, copying the definition from /libs to /apps/<your-project> . This new definition, in /apps , can be updated according to your requirements.
Voir Utilisation des recouvrements pour plus de détails.
Par exemple :
  • Cela impliquait de superposer une définition de composant :
    • Créez un dossier de composants dans /apps/<website-name>/components/<MyComponent> en copiant un composant existant :
      • Par exemple, pour personnaliser le composant Texte, copiez :
        • de /libs/foundation/components/text
        • vers /apps/myProject/components/text
  • Ce cas implique le recouvrement d’une servlet :
    • Dans le référentiel, copiez le(s) script(s) par défaut :
      • de /libs/sling/servlet/errorhandler/
      • vers /apps/sling/servlet/errorhandler/
You must not change anything in the /libs path.
This is because the content of /libs is overwritten the next time you upgrade your instance (and may well be overwritten when you apply either a hotfix or feature pack).
Pour la configuration et les autres modifications :
  1. copy the item in /libs to /apps
  2. make any changes within /apps

Quand utiliser ou non les requêtes JCR

Lorsqu’elles sont utilisées correctement, les requêtes JCR sont un puissant outil. Elles conviennent aux :
  • requêtes des utilisateurs finaux, telles que les recherches en texte intégral sur le contenu ;
  • les occasions où le contenu structuré doit pouvoir être recherché sur le référentiel entier.
    Dans ce cas, assurez-vous que les requêtes ne s’exécutent que lorsque cela est absolument nécessaire, par exemple sur l’activation des composants ou l’invalidation du cache (par opposition aux étapes des processus, aux gestionnaires d’événements qui se déclenchent lors des modifications de contenu, aux filtres, etc.).
Les requêtes JCR ne devraient jamais être employées pour des requêtes de rendu pures. Par exemple, les requêtes JCR ne sont pas utiles pour :
  • le rendu de navigation ;
  • la création d’un aperçu des dix actualités les plus récentes ;
  • affichage du nombre d’éléments de contenu
Pour effectuer le rendu du contenu, utilisez l’accès de navigation à l’arborescence de contenu au lieu d’effectuer une requête JCR.
Si vous utilisez Query Builder , vous utilisez des requêtes JCR, car Query Builder génère des requêtes JCR en interne.

Considérations relatives à la sécurité

It is also worthwhile to reference the security checklist .

Sessions (de référentiel) JCR

Vous devez utiliser la session utilisateur, et non la session administrative. Cela signifie que vous devriez utiliser :
slingRequest.getResourceResolver().adaptTo(Session.class);

Protection contre les scripts de site à site (XSS)

Les scripts de site à site (XSS) permettent aux pirates d’injecter du code dans des pages web consultées par d’autres utilisateurs. Cette faille de sécurité peut être exploitée par des internautes malveillants pour contourner les contrôles d’accès.
AEM applique le principe de filtrage de l’ensemble du contenu fourni par l’utilisateur lors de la sortie. La prévention du script intersite (XSS) se voit accorder la priorité la plus élevée lors des phases de développement et de test.
Additionally, a web application firewall, such as mod_security for Apache , can provide reliable, central control over the security of the deployment environment and protect against previously undetected cross-site scripting attacks.
L’exemple de code fourni avec AEM peut ne pas protéger contre de telles attaques et repose généralement sur le filtrage des requêtes par un pare-feu pour applications web.
L’aide-mémoire de l’API XSS contient les informations dont vous avez besoin pour utiliser l’API XSS et renforcer la sécurité d’une application AEM. Vous pouvez le télécharger ici :
L’aide-mémoire de l’API XSS.

Sécurisation de la communication pour des informations confidentielles

Comme pour toute application Internet, lors du transport d’informations confidentielles, vérifiez que :
  • le trafic est sécurisé via SSL ;
  • HTTP POST est utilisé, le cas échéant.
Cela s’applique aux informations confidentielles au sein du système (comme la configuration ou l’accès administrateur), ainsi qu’aux informations confidentielles pour ses utilisateurs (comme leurs détails personnels).

Tâches distinctes de développement

Personnalisation des pages d’erreur

Les pages d’erreur peuvent être personnalisées pour AEM. Cela est recommandé de sorte que l’instance ne révèle pas de traces Sling sur les erreurs de serveur interne.

Fichiers ouverts dans le processus Java

Étant donné qu’AEM peut accéder à un grand nombre de fichiers, il est recommandé que le nombre de fichiers ouverts pour un processus Java soit configuré explicitement pour AEM.
Pour minimiser ce problème, vous devriez vous assurer lors du développement que tout fichier ouvert est correctement fermé dès que possible (de manière raisonnable).