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 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 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 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 es necesario editar la CSS.
  • Para apariencia:
    • Cambie la plantilla JS y la CSS.
  • Para Look, Feel y UX:
  • Para modificar la información disponible en la plantilla JS o en el extremo de GET:
  • Para agregar procesamiento personalizado durante las operaciones:
  • Para agregar una nueva operación personalizada:
    • Crear una nueva operación de publicación de Sling.
    • Utilice OperationServices existente según sea necesario.
    • Añada el código Javascript para invocar la operación desde el cliente según sea necesario.

Módulo de servidor

El marco 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.

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 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 al DefaultSocialGetServlet .
DefaultSocialGetServlet
  1. Pasa el recurso (resourceType) al recurso SocialComponentFactoryManager y recibe un SocialComponentFactory capaz de seleccionar un SocialComponent recurso.
  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 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 información sobre la gestión de UGC almacenados 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 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 la representación 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 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.
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
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 AEM Communities 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 ayudantes personalizados disponibles en SCF.

Client-Side Framework

Modelo-Vista de Javascript Framework

La estructura incluye una extensión de Backbone.js , un marco JavaScript de vista de modelos, 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 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 .