Structure des composants sociaux social-component-framework

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

Avantages du cadre :

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

Vue d’ensemble overview

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

Un modèle JS Handlebars peut étendre les composants JS de modèle/vue afin de 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 de manière à prendre en charge la modification/l’enregistrement de données similaires aux objets de modèle/données dans les applications web traditionnelles. En outre, des opérations (contrôleurs) et un service d’opération peuvent être ajoutés pour gérer les demandes d’opération, exécuter la logique commerciale et appeler les API sur les objets de modèle/données.

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

Rendu des pages pour le client how-pages-are-rendered-for-client

Personnalisation et extension des composants component-customization-and-extension

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

Framework Côté Serveur server-side-framework

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

API Java™ java-apis

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

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

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

API HTTP http-api

L’API HTTP prend en charge la personnalisation et le choix faciles des plateformes clientes pour les applications PhoneGap, les applications natives et d’autres intégrations et schémas. En outre, 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 dans n’importe quelle page web reposant sur n’importe quelle technologie.

API HTTP - Requêtes GET http-api-get-requests

Pour chaque composant social, le framework fournit un point d’entrée d’API basé sur HTTP. Le point d’entrée est accessible en envoyant une requête GET à la ressource avec un sélecteur « .social.json » + extension. Avec Sling, la requête est transmise au DefaultSocialGetServlet.

DefaultSocialGetServlet

GET Request

Un servlet GET par défaut écoute les requêtes .social.json auxquelles le composant social répond avec du code JSON personnalisable.

API HTTP - Requêtes POST http-api-post-requests

Outre les opérations GET (lecture), le framework définit un modèle de point d’entrée pour activer d’autres opérations sur un composant, y compris Créer, Mettre à jour et Supprimer. Ces points d’entrée sont des API HTTP qui acceptent des entrées et répondent avec un code d’état HTTP ou un objet de réponse JSON.

Ce modèle de point d’entrée de framework rend les opérations CUD extensibles, réutilisables et testables.

POST Request

Il existe un POST Sling:operation pour chaque opération de SocialComponent. La logique commerciale et le code de maintenance de chaque opération sont enveloppés dans un OperationService accessible via l’API HTTP ou depuis un autre emplacement en tant que service OSGi. Des crochets sont fournis pour prendre en charge les extensions d’opération enfichables pour les actions avant/après.

Fournisseur de ressources de stockage (SRP) storage-resource-provider-srp

Pour en savoir plus sur la gestion du contenu créé par l’utilisateur stocké dans le magasin de contenu de la communauté, voir :

Personnalisations côté serveur server-side-customizations

Consultez 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 handlebars-js-templating-language

L’un des changements les plus remarquables du nouveau cadre est l’utilisation du langage de modèle Handlebars JS (HBS), une technologie open source populaire pour le rendu serveur-client.

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

Le framework fournit plusieurs assistants Handlebars qui sont utiles lors du développement de SocialComponents.

Sur le serveur, lorsque Sling résout une requête GET, il identifie le script utilisé pour répondre à la requête. Si le script est un modèle HBS (.hbs), Sling délègue la requête au moteur Handlebars. Le moteur Handlebars récupère ensuite le SocialComponent dans le SocialComponentFactory approprié, crée un contexte et effectue le rendu de l’HTML.

Aucune restriction d’accès no-access-restriction

Les fichiers de modèle Handlebars (HBS) (.hbs) sont analogues 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 qui demande un modèle côté client reçoit un fichier .hbs du serveur.

Pour ce faire, tous les modèles HBS du chemin de recherche Sling (tous les fichiers .hbs situés sous /libs/ ou /apps) doivent pouvoir être récupérés par n’importe quel utilisateur à partir de l’instance de création ou de publication.

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

Ajouter ou inclure un composant de communautés add-or-include-a-communities-component

La plupart des composants de Communities doivent être ajoutés comme ressource adressable Sling. Certains composants de Communities peuvent être inclus dans un modèle en tant que ressource non existante afin de permettre l’inclusion dynamique et la personnalisation de l’emplacement d’écriture du contenu créé par l’utilisateur.

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

Ajouter un composant

L’ajout d’un composant fait référence au processus d’ajout d’une instance d’une ressource (composant), par exemple lorsqu’elle est glissée depuis le navigateur de composant (sidekick) sur une page en mode d’édition création.

Le résultat est un nœud enfant JCR sous un nœud 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 » (aucun nœud JCR) dans le modèle, par exemple à l’aide d’un langage de script.

Depuis Adobe Experience Manager (AEM) 6.1, lorsqu’un composant est inclus dynamiquement au lieu d’être ajouté, il est possible de modifier les propriétés du composant en mode de création conception.

Seuls quelques-uns des composants AEM Communities sélectionnés peuvent être inclus dynamiquement. Il s’agit des éléments suivants :

Le Guide des composants de communauté permet d’activer/désactiver les composants inclusibles de leur ajout à leur inclusion.

Lors de l’utilisation de Handlebars le langage de modèle, la ressource non existante est incluse à l’aide de l’assistant d’inclusion en 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" />

Handlebars Helpers handlebars-helpers

Consultez Assistant Handlebars SCF pour obtenir une liste et une description des assistants personnalisés disponibles dans SCF.

Framework Côté Client client-side-framework

Framework JavaScript de vue de modèle model-view-javascript-framework

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

La structure utilise des 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 à HTML générées par les modèles Handlebars et offrent de l’interactivité.

Conventions CSS css-conventions

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

Personnalisations côté client client-side-customizations

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

Principes de base des fonctionnalités et composants feature-and-component-essentials

Les informations essentielles pour l’équipe de développement sont décrites dans la section Principes de base des fonctionnalités et des composants.

Pour plus d’informations sur le développeur, consultez la section Consignes de codage.

Résolution des problèmes troubleshooting

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