Show Menu
TEMAS×

Marco de componentes sociales

El marco de componentes sociales (SCF) simplifica el proceso de configuración, personalización y ampliación de los componentes de Communities tanto en el servidor como en el cliente.
Los beneficios del marco:
  • Funcional : Facilidad de integración predeterminada con poca o ninguna personalización para el 80 % de los casos de uso
  • Skinnable : Uso coherente de atributos HTML para estilos CSS
  • Extensible : La implementación de componentes está orientada a objetos y tiene una lógica empresarial clara: es fácil agregar inicios de sesión comerciales incrementales en el servidor
  • Flexible : Plantillas de javascript sencillas y sin lógica que se pueden superponer y personalizar fácilmente
  • Accesible : La API HTTP admite la publicación desde cualquier cliente, incluidas las aplicaciones móviles
  • Portátil : Integrar/integrar en cualquier página web creada con cualquier tecnología
Explore en una instancia de autor o publicación mediante la guía de componentes de comunidad interactiva.

Información general

En SCF, un componente está compuesto por un POJO de componente de Social, una plantilla JS de controladores (para representar el componente) y CSS (para aplicar estilo al componente).
Una plantilla JS de Handlebars puede ampliar los componentes JS de modelo o vista para manejar la interacción del usuario con el componente en el cliente.
Si un componente necesita admitir la modificación de datos, la implementación de la API de SocialComponent se puede escribir para admitir la edición/guardado de datos similares a objetos de modelo/datos en aplicaciones web tradicionales. Además, se pueden añadir operaciones (controladores) y un servicio de operación para gestionar solicitudes de operación, llevar a cabo lógica empresarial e invocar las API en objetos de modelo o datos.
La API de SocialComponent se puede ampliar para proporcionar los datos que un cliente necesita para una capa de vista o un cliente HTTP.

Cómo se procesan las páginas para el cliente

Personalización y extensión de componentes

Para personalizar o ampliar los componentes, solo debe escribir las superposiciones y extensiones en el directorio /apps, lo que simplifica el proceso de actualización a versiones futuras.

Módulo de servidor

La estructura proporciona API para acceder a la funcionalidad en el servidor y admite la interacción entre el cliente y el servidor.

API de Java

Las API de Java proporcionan clases e interfaces abstractas que se heredan o subclasifican fácilmente.
Las clases principales se describen en la página Personalización del lado del servidor.
Visite Información general del proveedor de recursos de almacenamiento de información para obtener información sobre cómo trabajar con UGC.

HTTP API

La API HTTP admite la facilidad de personalización y elección de plataformas de cliente para aplicaciones PhoneGap, aplicaciones nativas y otras integraciones y mashups. Además, la API de HTTP permite que un sitio de comunidad se ejecute como un servicio sin cliente, de modo que los componentes del marco se pueden integrar en cualquier página web creada con cualquier tecnología.

API HTTP: solicitudes GET

Para cada componente de Social, la estructura proporciona un extremo de API basado en HTTP. Se accede al extremo enviando una solicitud GET al recurso con un selector '.social.json' + extensión. Con Sling, la solicitud se entrega al DefaultSocialGetServlet .
El DefaultSocialGetServlet
  1. Pasa el recurso (resourceType) al recurso SocialComponentFactoryManager y recibe un SocialComponentFactory capaz de seleccionar un recurso SocialComponent que lo represente.
  2. Invoca la fábrica y recibe una SocialComponent capacidad para gestionar el recurso y la solicitud.
  3. Invoca el SocialComponent , que procesa la solicitud y devuelve una representación JSON de los resultados.
  4. Devuelve la respuesta JSON al cliente.
GET Request
Un servlet GET predeterminado escucha las solicitudes .social.json a las que SocialComponent responde con JSON personalizable.

API HTTP: solicitudes POST

Además de las operaciones GET (Leer), el marco define un patrón de extremo para habilitar otras operaciones en un componente, como Crear, Actualizar y Eliminar. Estos extremos son API HTTP que aceptan entradas y responden con códigos de estado HTTP o con un objeto de respuesta JSON.
Este patrón de punto final del marco hace que las operaciones de CUD sean extensibles, reutilizables y comprobables.
POST Request
Hay una operación POST:Sling para cada operación de SocialComponent. La lógica empresarial y el código de mantenimiento de cada operación están agrupados en un OperationService al que se puede acceder a través de la API HTTP o desde cualquier otro lugar como servicio OSGi. Se proporcionan ganchos que admiten extensiones de operación conectables para acciones anteriores y posteriores.

Proveedor de recursos de almacenamiento (SRP)

Para obtener más información sobre la gestión de UGC almacenada en el almacén de contenido de la comunidad, consulte

Personalizaciones del lado del servidor

Visite Personalizaciones del lado del servidor para obtener información sobre la personalización de la lógica empresarial y el comportamiento de un componente de Comunidades en el lado del servidor.

Lenguaje de plantillas JS de Handlebars

Uno de los cambios más notables en el nuevo marco de trabajo es el uso del lenguaje de plantilla JS (HBS) Handlebars, una tecnología de código abierto popular para el procesamiento servidor-cliente.
Los scripts HBS son sencillos, sin lógica, se compilan tanto en el servidor como en el cliente, son fáciles de superponer y personalizar, y se enlazan naturalmente con el cliente UX, ya que HBS admite el procesamiento en el cliente.
La estructura proporciona varios controladores de controladores que son útiles para el desarrollo de SocialComponents.
En el servidor, cuando Sling resuelve una solicitud GET, identifica la secuencia de comandos que se utilizará para responder a la solicitud. Si la secuencia de comandos es una plantilla HBS (.hbs), Sling delegará la solicitud al motor de controladores. El motor de controladores obtendrá el componente SocialComponent de la SocialComponentFactory adecuada, generará un contexto y representará el HTML.

Sin restricción de acceso

Los archivos de plantilla de las barras de administración (HBS) (.hbs) son análogos a los archivos de plantilla .jsp y .html, excepto que pueden utilizarse para procesar tanto en el navegador del cliente como en el servidor. Por lo tanto, un navegador cliente que solicite una plantilla de cliente recibirá un archivo .hbs del servidor.
Esto requiere que cualquier usuario pueda recuperar todas las plantillas HBS de la ruta de búsqueda sling (cualquier archivo .hbs en /libs/ o /apps) desde el autor o la publicación.
No se puede prohibir el acceso HTTP a los archivos .hbs.

Agregar o incluir un componente de comunidades

La mayoría de los componentes de Comunidades deben agregarse como un recurso direccionable Sling. Algunos de los componentes de Comunidades pueden incluirse en una plantilla como recurso no existente para permitir la inclusión dinámica y la personalización de la ubicación en la que se escribe contenido generado por el usuario (UGC).
En cualquier caso, también deben estar presentes las bibliotecas de cliente requeridas del componente.
Agregar un componente
La adición de un componente se refiere al proceso de adición de una instancia de un recurso (componente), como cuando se arrastra desde el navegador de componentes (barra de tareas) a una página en modo de edición de autor.
El resultado es un nodo secundario JCR bajo un nodo par, que es direccionable Sling.
Incluir un componente
Incluir un componente hace referencia al proceso de agregar una referencia a un recurso Para recursos no existentes (NER) "no existente" (sin nodo JCR) dentro de la plantilla, como el uso de un lenguaje de secuencias de comandos.
A partir de AEM 6.1, cuando un componente se incluye dinámicamente en lugar de agregarse, es posible editar las propiedades del componente en el *modo *diseño *del autor.
Solo se pueden incluir dinámicamente algunos de los componentes de Comunidades de AEM seleccionados. Son:
La Guía de componentes de comunidad permite que los componentes incluibles no se agreguen a la inclusión.
Al utilizar el lenguaje de plantilla Handlebars , el recurso no existente se incluye mediante el asistente include especificando su resourceType:
{{include this.id path="comments" resourceType="social/commons/components/hbs/comments"}}
Al utilizar JSP , se incluye un recurso con la etiqueta cq:include :
<cq:include path="votes" 
 resourceType="social/tally/components/voting" />

Para agregar un componente a una página de forma dinámica, en lugar de agregarlo o incluirlo en una plantilla, consulte Descarga de componentes.

Ayudantes de manillar

Consulte SCF Handlebars Helpers para obtener una lista y una descripción de los asistentes personalizados disponibles en SCF.

Client-Side Framework

Modelo-Ver Javascript Framework

La estructura incluye una extensión de Backbone.js , un marco de JavaScript de vista de modelo, para facilitar el desarrollo de componentes interactivos y enriquecidos. La naturaleza orientada a objetos admite un marco extensible/reutilizable. La comunicación entre cliente y servidor se simplifica mediante la API HTTP.
El marco aprovecha las plantillas de controladores del lado del servidor para procesar los componentes para el cliente. Los modelos se basan en las respuestas JSON generadas por la API HTTP. Las vistas se enlazan a HTML generado por las plantillas de controladores y proporcionan interactividad.

Convenciones CSS

Se recomiendan las siguientes convenciones para definir y utilizar clases CSS:
  • Utilice nombres selectores de clase CSS claramente con espacios de nombres y evite nombres genéricos como 'encabezado', 'imagen', etc.
  • Defina estilos de selector de clase específicos para que las hojas de estilo CSS funcionen correctamente con otros elementos y estilos de la página. Por ejemplo: .social-forum .topic-list .li { color: blue; }
  • Mantener las clases CSS para estilos independientes de las clases CSS para UX impulsadas por JavaScript

Personalizaciones del lado del cliente

Para personalizar el aspecto y el comportamiento de un componente de Comunidades en el lado del cliente, consulte Personalizaciones del lado del cliente, que incluye información sobre:

Funciones y componentes esenciales

La información esencial para los desarrolladores se describe en la sección Funciones y componentes esenciales .
Puede encontrar información adicional para desarrolladores en la sección Directrices de codificación.

Solución de problemas

Las preocupaciones comunes y los problemas conocidos se describen en la sección Resolución de problemas .