Structure des composants sociaux social-component-framework

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 :

Explorez une instance de création ou de publication à l’aide de l’option interactive Guide des composants de communauté.

Présentation overview

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 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 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 server-side-framework

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 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 dans la section Personnalisation côté serveur page.

Visite 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 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 http-api-get-requests

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 à la fonction DefaultSocialGetServlet.

La DefaultSocialGetServlet

GET Request

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

API HTTP - Demandes de POST http-api-post-requests

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.

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

Pour en savoir plus sur la gestion du contenu généré par l’utilisateur stocké dans la variable magasin de contenu communautaire, voir

Personnalisations côté serveur server-side-customizations

Visite 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’utilisation de la fonction Handlebars JS langage de modèle (HBS), une technologie Open Source populaire pour le rendu client-serveur.

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 Handlebars Helpers qui sont 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 HTML.

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

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 add-or-include-a-communities-component

La plupart des composants Communities doivent être ajouté en tant que ressource adressable Sling. Quelques-uns des composants de communauté peuvent être included dans un modèle en tant que ressource non existante pour permettre l’inclusion et la personnalisation dynamiques de l’emplacement où écrire le contenu généré par l’utilisateur.

Dans les deux cas, la variable bibliothèques clientes requises doit également être présent.

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, par exemple en utilisant 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 communauté permet d’empêcher l’ajout à des composants inclusibles.

Lors de l’utilisation de Guidons langue de modèle, la ressource non existante est incluse à l’aide du 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

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

Structure côté client client-side-framework

Structure JavaScript de l’affichage du modèle model-view-javascript-framework

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 HTML généré par les modèles Handlebars et offrent une 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 comprend des informations sur :

Fonctionnalités et composants essentiels feature-and-component-essentials

Les informations essentielles pour les développeurs sont décrites dans la section Fonctionnalités et composants essentiels .

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

Résolution des problèmes troubleshooting

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