Structure des composants sociaux

La structure de composants sociaux (SCF) simplifie le processus de configuration, de personnalisation et d’extension des composants Communities côté serveur et côté client.

Les avantages du cadre :

  • Fonctionnel : Facilité d’intégration prête à l’emploi avec peu ou pas de personnalisation pour 80 % des cas d’utilisation.
  • Skinnable : Utilisation cohérente d’attributs HTML pour la mise en forme CSS.
  • Extensible : La mise en oeuvre des composants est orientée objet et s’appuie sur la logique métier : il est facile d’ajouter une connexion incrémentielle de l’entreprise sur le serveur.
  • Flexible : Modèles JavaScript simples sans logique, facilement superposés et personnalisés.
  • Accessible : L’API HTTP prend en charge la publication depuis n’importe quel client, y compris les applications mobiles.
  • Portable : Intégrez/incorporez dans n’importe quelle page web reposant sur n’importe quelle technologie.

Explorez une instance de création ou de publication à l’aide du guide des composants de la communauté interactif.

Présentation

Dans SCF, un composant est constitué d’un POJO SocialComponent, d’un modèle JS Handlebars (pour effectuer le rendu du composant) et de CSS (pour appliquer un style au composant).

Un modèle JS Handlebars peut étendre les composants JS de modèle/vue pour gérer l’interaction de l’utilisateur avec le composant sur le client.

Si un composant doit prendre en charge la modification des données, l’implémentation de l’API SocialComponent peut être écrite pour prendre en charge la modification/enregistrement de données similaires aux objets de modèle/données dans les applications web traditionnelles. En outre, les opérations (contrôleurs) et un service d’opération peuvent être ajoutés pour gérer les demandes d’opération, exécuter une logique métier et appeler les API sur les objets de modèle/données.

L’API SocialComponent peut être étendue afin de fournir les données requises par un client pour une couche d’affichage ou un client HTTP.

Rendu des pages pour le client

scf-page-rendering

Personnalisation et extension des composants

Pour personnaliser ou étendre les composants, vous écrivez uniquement les incrustations et les extensions dans votre répertoire /apps, ce qui simplifie le processus de mise à niveau vers les prochaines versions.

Structure côté serveur

La structure fournit des API pour accéder aux fonctionnalités du serveur et prendre en charge l’interaction entre le client et le serveur.

API Java

Les API Java fournissent des classes et des interfaces abstraites qui sont facilement héritées ou sous-classées.

Les classes principales sont décrites sur la page Personnalisation côté serveur .

Visitez Présentation du fournisseur de ressources de stockage pour en savoir plus sur l’utilisation du contenu créé par l’utilisateur.

API HTTP

L’API HTTP prend en charge la facilité de personnalisation et de choix des plateformes clientes pour les applications PhoneGap, les applications natives, ainsi que d’autres intégrations et applications monopages. De plus, l’API HTTP permet à un site communautaire de s’exécuter en tant que service sans client, de sorte que les composants de structure puissent être intégrés à n’importe quelle page web créée sur n’importe quelle technologie.

API HTTP - Demandes de GET

Pour chaque composant Social, la structure fournit un point de terminaison d’API HTTP. Le point de terminaison est accessible en envoyant une requête de GET à la ressource avec un sélecteur + extension '.social.json'. Avec Sling, la requête est transmise à DefaultSocialGetServlet.

DefaultSocialGetServlet

  1. Transmet la ressource (resourceType) à SocialComponentFactoryManager et reçoit un SocialComponentFactory capable de sélectionner une SocialComponent représentant la ressource.

  2. Appelle la fabrique et reçoit une SocialComponent capable de gérer la ressource et la requête.

  3. Appelle la balise SocialComponent, qui traite la requête et renvoie une représentation JSON des résultats.

  4. Renvoie la réponse JSON au client.

GET Request

Un servlet de GET par défaut écoute les demandes .social.json auxquelles le SocialComponent répond avec un JSON personnalisable.

scf-framework

API HTTP - Demandes de POST

En plus des opérations de GET (lecture), la structure définit un modèle de point de terminaison pour activer d’autres opérations sur un composant, notamment Créer, Mettre à jour et Supprimer. Ces points de terminaison sont des API HTTP qui acceptent les entrées et répondent avec des codes d’état HTTP ou avec un objet de réponse JSON.

Ce modèle de point de terminaison de structure rend les opérations CUD extensibles, réutilisables et testables.

POST Request

Il existe une opération Sling POST:operation pour chaque opération SocialComponent . La logique commerciale et le code de maintenance pour chaque opération sont encapsulés dans un OperationService accessible via l’API HTTP ou ailleurs en tant que service OSGi. Les hooks prennent en charge les extensions d’opération enfichables pour les actions avant/après.

scf-post-request

Fournisseur de ressources de stockage (SRP)

Pour en savoir plus sur la gestion du contenu généré par l’utilisateur stocké dans la boutique de contenu de la communauté, voir :

Personnalisations côté serveur

Visitez la page Personnalisations côté serveur pour plus d’informations sur la personnalisation de la logique commerciale et du comportement d’un composant Communities côté serveur.

Langage de modèle JS Handlebars

L’utilisation du langage de modèle Handlebars JS (HBS), une technologie Open Source populaire pour le rendu client-serveur, constitue l’un des changements les plus visibles dans la nouvelle structure.

Les scripts HBS sont simples, sans logique, compilés à la fois sur le serveur et le client, faciles à superposer et à personnaliser, et sont naturellement liés à l’UX du client, car HBS prend en charge le rendu côté client.

La structure fournit plusieurs assistants Handlebars utiles lors du développement de composants sociaux.

Sur le serveur, lorsque Sling résout une demande de GET, il identifie le script qui sera utilisé pour répondre à la demande. Si le script est un modèle HBS (.hbs), Sling déléguera la requête au moteur Handlebars. Le moteur Handlebars récupère ensuite le composant Social à partir de la SocialComponentFactory appropriée, crée un contexte et effectue le rendu du code HTML.

Aucune restriction d’accès

Les fichiers de modèle Handlebars (HBS) (.hbs) sont similaires aux fichiers de modèle .jsp et .html , sauf qu’ils peuvent être utilisés pour le rendu à la fois dans le navigateur client et sur le serveur. Par conséquent, un navigateur client demandant un modèle côté client recevra un fichier .hbs du serveur.

Pour ce faire, tous les modèles HBS dans le chemin de recherche Sling (tous les fichiers .hbs sous /libs/ ou /apps) peuvent être récupérés par n’importe quel utilisateur à partir de l’auteur ou de la publication.

L’accès HTTP aux fichiers .hbs peut ne pas être interdit.

Ajout ou inclusion d’un composant Communautés

La plupart des composants Communities doivent être ajoutés en tant que ressource adressable Sling. Un certain nombre de composants Communities peuvent être inclus dans un modèle en tant que ressource non existante afin de permettre l’inclusion et la personnalisation dynamiques de l’emplacement où écrire du contenu généré par l’utilisateur.

Dans les deux cas, les bibliothèques clientes requises du composant doivent également être présentes.

Ajout d’un composant

L’ajout d’un composant fait référence au processus d’ajout d’une instance d’une ressource (composant), par exemple lorsque vous faites glisser du navigateur de composants (sidekick) vers une page en mode d’édition de création.

Le résultat est un noeud enfant JCR sous un noeud par, qui est adressable à Sling.

Inclure un composant

L’inclusion d’un composant fait référence au processus d’ajout d’une référence à une ressource "non existante" (pas de noeud JCR) dans le modèle, comme l’utilisation d’un langage de script.

À compter de la version 6.1 d’AEM, lorsqu’un composant est inclus dynamiquement au lieu d’être ajouté, il est possible de modifier les propriétés du composant en mode création conception.

Seuls quelques-uns des composants AEM Communities peuvent être inclus dynamiquement. Ils sont :

Le Guide des composants de la communauté permet d’empêcher l’ajout de composants intégrables à l’inclusion.

Lors de l’utilisation du langage Handlebarstemplating, la ressource non existante est incluse à l’aide de l’ 🔗 inclusionhelperen spécifiant son resourceType :

{{include this.id path="comments" resourceType="social/commons/components/hbs/comments"}}

Lors de l’utilisation de JSP, une ressource est incluse à l’aide de la balise cq:include :

<cq:include path="votes"
 resourceType="social/tally/components/voting" />
REMARQUE

Pour ajouter dynamiquement un composant à une page, au lieu de l’ajouter ou de l’inclure dans un modèle, reportez-vous à la section Transfert de composant.

Handlebars Helpers

Voir Aide-mémoire SCF pour obtenir la liste et la description des assistants personnalisés disponibles dans SCF.

Structure côté client

Structure JavaScript de l’affichage du modèle

La structure comprend une extension de Backbone.js, une structure JavaScript d’affichage de modèle, pour faciliter le développement de composants interactifs riches. La nature orientée objet prend en charge une structure extensible/réutilisable. La communication entre le client et le serveur est simplifiée au moyen de l’API HTTP.

La structure utilise les modèles Handlebars côté serveur pour effectuer le rendu des composants pour le client. Les modèles sont basés sur les réponses JSON générées par l’API HTTP. Les vues se lient au code HTML généré par les modèles Handlebars et offrent une interactivité.

Conventions CSS

Les conventions suivantes sont recommandées pour définir et utiliser des classes CSS :

  • Utilisez des noms de classe CSS clairement espacés dans l’espace de noms et évitez les noms génériques tels que 'titre', 'image', etc.
  • Définissez des styles de sélecteur de classe spécifiques afin que les feuilles de style CSS fonctionnent correctement avec d’autres éléments et styles de la page. Par exemple : .social-forum .topic-list .li { color: blue; }
  • Conservez les classes CSS pour la mise en forme distinctes des classes CSS pour les classes UX pilotées par JavaScript.

Personnalisations côté client

Pour personnaliser l’aspect et le comportement d’un composant Communities côté client, reportez-vous à la section Personnalisations côté client, qui comprend des informations sur :

Fonctionnalités et composants essentiels

Les informations essentielles pour les développeurs sont décrites dans la section Notions fondamentales sur les fonctionnalités et les composants .

Vous trouverez des informations supplémentaires sur les développeurs dans la section Consignes de codage .

Résolution des problèmes

Les problèmes courants et les problèmes connus sont décrits dans la section Dépannage .

Sur cette page