Cadre des composants sociaux

Le cadre des composants sociaux (SCF) simplifie le processus de configuration, de personnalisation et d’extension des composants de communautés côté serveur et côté client.

Les avantages du cadre :

• Fonctionnel : Facilité d'intégration immédiate avec peu ou pas de personnalisation pour 80 % des cas d'utilisation.
• Skinnable : Utilisation cohérente des 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 d'entreprise incrémentielle 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 toute page Web construite sur n'importe quelle technologie.

Explorez une instance d’auteur ou de publication à l’aide du guide interactif Composants de la communauté.

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/l’enregistrement de données similaires aux objets de modèle/de données dans les applications Web traditionnelles. En outre, des opérations (contrôleurs) et un service d'opérations 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 pour fournir les données requises par un client pour une couche de vue ou un client HTTP.

Mode de rendu des pages pour le client

Personnalisation des composants et extension

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

• Pour l'habillage :
  • Seul le fichier CSS doit être modifié.
• Pour la recherche et le ressenti :
  • Modifiez le modèle JS et le fichier CSS.
• Pour Look, Feel et UX :
  • Modifiez le modèle JS, CSS et étendre/remplacer Javascript.
• Pour modifier les informations disponibles pour le modèle JS ou pour le point de terminaison GET :
  • Étendez le composant social.
• Pour ajouter un traitement personnalisé pendant les opérations :
  • Écrivez un OperationExtension.
• Pour ajouter une nouvelle opération personnalisée :
  • Créez une opération Sling Post .
  • Utilisez OperationServices existant si nécessaire.
  • Ajoutez le code JavaScript pour appeler votre opération du côté client si nécessaire.

Structure côté serveur

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

API Java

Les API Java offrent 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 d’Enregistrement pour en savoir plus sur l’utilisation de l’UGC.

API HTTP

L’API HTTP facilite la personnalisation et le choix des plates-formes clientes pour les applications PhoneGap, les applications natives, ainsi que d’autres intégrations et applications hybrides. 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 la structure puissent être intégrés à n'importe quelle page Web construite sur n'importe quelle technologie.

API HTTP - Demandes de GET

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

DefaultSocialGetServlet

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

2. Appelle l'usine et reçoit un SocialComponent capable de gérer la ressource et la demande.

3. Appelle le 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

Une servlet de GET par défaut écoute les requêtes .social.json auxquelles le SocialComponent répond avec un JSON personnalisable.

API HTTP - Demandes du POST

Outre les 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 un code d’état HTTP ou un objet de réponse JSON.

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

POST Request

Il existe une opération POST:Sling pour chaque opération SocialComponent. La logique métier et le code de maintenance de chaque opération sont encapsulés dans un OperationService accessible via l'API HTTP ou depuis un autre service OSGi. Des crochets sont fournis pour la prise en charge des extensions d'opération enfichables pour les actions avant/après.

Fournisseur de ressources d'Enregistrement

Pour en savoir plus sur la gestion des fichiers UGC stockés dans la boutique de contenu de la communauté, voir :

• Présentation du fournisseur de ressources d'Enregistrement - Présentation et présentation de l'utilisation du référentiel.
• SRP et UGC Essentials - Exemples et méthodes d'utilitaire d'API SRP.
• Accès à l'UGC avec des directives de codage SRP .

Personnalisations côté serveur

Visitez Personnalisations côté serveur pour plus d'informations sur la personnalisation de la logique métier et du comportement d'un composant Communities côté serveur.

Handlebars JS Template Language

L'un des changements les plus notables dans la nouvelle structure est l'utilisation du langage de modèle JS Handlebars (HBS), une technologie open source populaire pour le rendu serveur-client.

Les scripts HBS sont simples, sans logique, compilent sur le serveur et le client, sont faciles à recouvrir et à personnaliser, et sont naturellement liés au client UX parce que HBS prend en charge le rendu côté client.

La structure fournit plusieurs barres d’outils utiles lors du développement de SocialComponents.

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 SocialComponent 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 HBS (Handlebars) (.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 demandant un modèle côté client recevra 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) peuvent être extraits par tout utilisateur de l'auteur ou de la publication.

L'accès HTTP aux fichiers .hbs n'est pas interdit.

Ajouter ou inclure un composant Collectivités

La plupart des composants Communities doivent être ajoutés en tant que ressource adressable Sling. Certains composants de communautés 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 le contenu généré par l'utilisateur (UGC).

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

Ajouter un composant

L’Ajoute 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 du navigateur de composants (sidekick) sur une page en mode d’édition de l’auteur.

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" (aucun noeud JCR) dans le modèle, par exemple en utilisant un langage de script.

A partir de AEM 6.1, lorsqu’un composant est inclus dynamiquement au lieu d’être ajouté, il est possible de modifier ses propriétés en mode création *design *.

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

• Commentaires
• Évaluation
• Révisions
• Vote

Le Guide des composants de la communauté permet d'éviter que des composants inclusifs ne soient ajoutés à l'inclusion.

Lors de l'utilisation du langage Handlebarstemplating, la ressource non existante est incluse à l'aide de l' option inclure helperen spécifiant son type de ressource :

{{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

Voir Aide-barres de poignées SCF pour obtenir une liste et une description des aides personnalisées disponibles dans SCF.

Cadre côté client

Cadre JavaScript de Vue de modèle

La structure comprend une extension de Backbone.js, une structure JavaScript modèle-vue, afin de faciliter le développement de composants interactifs riches. La nature orientée objet prend en charge un cadre 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 de barres de contrôle côté serveur pour générer les 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 la définition et l’utilisation des classes CSS :

• Utilisez des noms de sélecteur de classe CSS clairement espacés dans les 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 séparées des classes CSS pour UX pilotées par JavaScript.

Personnalisations côté client

Pour personnaliser l'apparence et le comportement d'un composant Communities côté client, consultez la section Personnalisations côté client, qui contient des informations sur :

• Recouvrements
• Extensions
• Marquage HTML
• Esquisse de CSS
• Extension de JavaScript
• Clientlibs pour SCF

Fonctionnalités et composants essentiels

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

Vous trouverez des informations supplémentaires sur les développeurs dans la section Lignes directrices sur le codage.

Résolution des incidents

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