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 se basa en la lógica empresarial: 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 interactiva de componentes de comunidad.

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 extender 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.

• Para la apariencia:
  • Solo el CSS necesita edición.
• Para apariencia:
  • Cambie la plantilla JS y la CSS.
• Para Look, Feel y UX:
  • Cambie la plantilla JS, CSS y extienda/sobrescriba Javascript.
• Para modificar la información disponible en la plantilla JS o en el extremo de GET:
  • Extienda el componente de Social.
• Para agregar procesamiento personalizado durante las operaciones:
  • Escriba OperationExtension.
• Para agregar una nueva operación personalizada:
  • Cree una nueva Operación posterior de Sling.
  • Utilice los OperationServices existentes según sea necesario.
  • Añada el código Javascript para invocar la operación desde el cliente según sea necesario.

Módulo del lado del 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 para obtener información sobre cómo trabajar con UGC.

API HTTP

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 de GET

Para cada componente de Social, la estructura proporciona un extremo de API basado en HTTP. Se accede al extremo enviando una solicitud de GET al recurso con un selector '.social.json' + extensión. Con Sling, la solicitud se entrega a DefaultSocialGetServlet.

DefaultSocialGetServlet

1. Pasa el recurso (resourceType) a SocialComponentFactoryManager y recibe un SocialComponentFactory capaz de seleccionar un SocialComponent que representa el recurso.

2. Invoca la fábrica y recibe un SocialComponent capaz de administrar 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 de GET predeterminado escucha las solicitudes .social.json a las que SocialComponent responde con JSON personalizable.

API HTTP - Solicitudes de POST

Además de las operaciones de GET (lectura), la estructura 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 Sling POST:para cada operación 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 administración de UGC almacenada en el almacén de contenido de la comunidad, consulte:

• Almacenamiento Resource Provider Overview : Introducción y uso del repositorio.
• SRP y UGC Essentials - Métodos y ejemplos de utilidad de la API de SRP.
• Acceso a UGC con SRP - Directrices de codificación.

Personalizaciones del lado del servidor

Visite Personalizaciones del lado del servidor para obtener información sobre cómo personalizar la lógica y el comportamiento de negocios de un componente de comunidades en el lado del servidor.

Lenguaje de plantillas JS de controladores

Uno de los cambios más notables en el nuevo marco de trabajo es el uso del lenguaje de plantilla JS Handlebars (HBS), 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 ayuda que son útiles al desarrollar SocialComponents.

En el servidor, cuando Sling resuelve una solicitud de 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.

Añadir o incluir un componente de comunidades

La mayoría de los componentes de Communities deben agregarse como recurso direccionable de Sling. Algunos de los componentes de Communities 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.

Añadir un componente

Añadir un componente se refiere al proceso de agregar 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

La inclusión de un componente se refiere al proceso de agregar una referencia a un recurso "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 AEM Communities seleccionados. Son:

• Comentarios
• Clasificación
• Críticas
• Votación

La Guía de componentes de la comunidad permite que los componentes incluibles no se agreguen a la inclusión.

Al utilizar el lenguaje Handlebarstemplating, 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" />

Ayudas para manillares

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

Client-Side Framework

Modelo-Vista Javascript Framework

La estructura incluye una extensión de Backbone.js, un marco de trabajo 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; }
• Mantenga las clases CSS para estilos separados de las clases CSS para UX impulsadas por JavaScript.

Personalizaciones del lado del cliente

Para personalizar la apariencia y el comportamiento de un componente Communities en el cliente, consulte Personalizaciones del cliente, que incluye información sobre:

• Superposiciones
• Extensiones
• Código HTML
• Aplicación de apariencia a CSS
• Ampliación de Javascript
• Clientlibs para SCF

Elementos esenciales de funciones y componentes

La información esencial para los desarrolladores se describe en la sección Funciones y elementos esenciales.

Puede encontrar información adicional para desarrolladores en la sección Pautas de codificación.

Solución de problemas

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