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 du guide des composants de la communauté interactif.
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.
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.
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.
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.
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.
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
Transmet la ressource (resourceType) à SocialComponentFactoryManager
et reçoit un SocialComponentFactory capable de sélectionner une SocialComponent
représentant la ressource.
Appelle la fabrique et reçoit une SocialComponent
capable de gérer la ressource et la requête.
Appelle la balise SocialComponent
, qui traite la requête et renvoie une représentation JSON des résultats.
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.
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.
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 :
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.
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.
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.
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" />
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.
Voir Aide-mémoire SCF pour obtenir la liste et la description des assistants personnalisés disponibles dans SCF.
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é.
Les conventions suivantes sont recommandées pour définir et utiliser des classes CSS :
.social-forum .topic-list .li { color: blue; }
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 :
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 .
Les problèmes courants et les problèmes connus sont décrits dans la section Dépannage .