El marco de trabajo de componentes sociales (SCF) simplifica el proceso de configuración, personalización y ampliación de los componentes de las comunidades en el lado del servidor y del cliente.
Las ventajas del marco:
Explorar en una instancia de autor o publicación mediante el Guía de componentes de la comunidad.
En SCF, un componente consta de un POJO de componente social, una plantilla JS de Handlebars (para procesar el componente) y CSS (para aplicar estilo al componente).
Una plantilla JS de Handlebars puede ampliar los componentes JS de modelo/vista para administrar 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 o el guardado de datos similares a objetos de modelo/datos en aplicaciones web tradicionales. Además, se pueden agregar operaciones (controladores) y un servicio de operación para administrar solicitudes de operación, realizar lógica empresarial e invocar las API en el modelo u objetos de datos.
La API de SocialComponent se puede ampliar para proporcionar los datos requeridos por un cliente para una capa de vista o un cliente HTTP.
Para personalizar o ampliar los componentes, solo escribe las superposiciones y extensiones en el directorio /apps, lo que simplifica el proceso de actualización a futuras versiones.
El marco de trabajo proporciona API para acceder a la funcionalidad en el servidor y admitir la interacción entre el cliente y el servidor.
Las API de Java proporcionan clases e interfaces abstractas que se heredan o subclasifican fácilmente.
Las clases principales se describen en la Personalización del lado del servidor página.
Visita Resumen del proveedor de recursos de almacenamiento para aprender a trabajar con UGC.
La API HTTP admite la facilidad de personalización y la elección de plataformas de cliente para aplicaciones PhoneGap, aplicaciones nativas y otras integraciones y mezclas. Además, la API HTTP permite que un sitio de la comunidad se ejecute como un servicio sin un cliente, de modo que los componentes de marco de trabajo se puedan integrar en cualquier página web basada en cualquier tecnología.
Para cada SocialComponent, el marco de trabajo proporciona un extremo de API basado en HTTP. Se accede al extremo enviando una solicitud de GET al recurso con un selector + extensión '.social.json'. Con Sling, la solicitud se entrega al DefaultSocialGetServlet
.
DefaultSocialGetServlet
Pasa el recurso (resourceType) al SocialComponentFactoryManager
y recibe un SocialComponentFactory capaz de seleccionar un SocialComponent
que representa el recurso.
Invoca la fábrica y recibe un SocialComponent
capaz de gestionar el recurso y la solicitud.
Invoca el SocialComponent
, que procesa la solicitud y devuelve una representación JSON de los resultados.
Devuelve la respuesta JSON al cliente.
GET Request
Un servlet de GET predeterminado escucha solicitudes .social.json a las que el componente social responde con un JSON personalizable.
Además de las operaciones de GET (lectura), 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 extremo de marco de trabajo hace que las operaciones de CUD sean ampliables, reutilizables y comprobables.
POST Request
Hay una operación Sling POST:para cada operación de SocialComponent. La lógica empresarial y el código de mantenimiento de cada operación se encapsulan 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 enlaces que admiten extensiones de operación conectables para acciones antes/después.
Para obtener más información sobre la administración de UGC almacenados en almacén de contenido de la comunidad, consulte:
Visita Personalizaciones del lado del servidor para obtener información sobre cómo personalizar la lógica empresarial y el comportamiento de un componente de Communities en el lado del servidor.
Uno de los cambios más notables en el nuevo marco es el uso de la variable Handlebars JS
Lenguaje de creación de plantillas (HBS), una tecnología de código abierto popular para el procesamiento de clientes y servidores.
Los scripts HBS son simples, 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 UX del cliente porque HBS admite el procesamiento en el lado del cliente.
El marco de trabajo proporciona varios Ayudantes de manillar que son útiles al desarrollar SocialComponents.
En el servidor, cuando Sling resuelve una solicitud de GET, identifica el script que se utilizará para responder a la solicitud. Si el script es una plantilla HBS (.hbs), Sling delegará la solicitud al motor de Handlebars. El motor de Handlebars obtiene el SocialComponent desde el SocialComponentFactory adecuado, crea un contexto y procesa el HTML.
Los archivos de plantilla (.hbs) de Handlebars (HBS) son análogos a los archivos de plantilla .jsp y .html, excepto que se pueden utilizar para procesar tanto en el explorador del cliente como en el servidor. Por lo tanto, un explorador del cliente que solicite una plantilla del lado del cliente recibirá un archivo .hbs del servidor.
Esto requiere que cualquier usuario pueda recuperar todas las plantillas HBS en la ruta de búsqueda de Sling (cualquier archivo .hbs en /libs/ o /apps) desde Autor o Publicación.
Puede que no esté prohibido el acceso HTTP a los archivos .hbs.
La mayoría de los componentes de Communities deben ser añadido como un recurso direccionable de Sling. Es posible que algunos de los componentes de Communities sean incluido en una plantilla como recurso no existente para permitir la inclusión y personalización dinámicas de la ubicación en la que se va a escribir contenido generado por el usuario (UGC).
En cualquier caso, el componente bibliotecas de cliente requeridas también debe estar presente.
Añadir un componente
Añadir un componente hace referencia al proceso de añadir 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 por Sling.
Incluir un componente
La inclusión de un componente hace referencia al proceso de añadir una referencia a una recurso "no existente" (sin nodo JCR) dentro de la plantilla, como el uso de un lenguaje de script.
AEM A partir de la versión 6.1, cuando se incluye un componente de forma dinámica en lugar de añadirse, es posible editar las propiedades del componente en el modo autor *diseño *diseño.
Solo se pueden incluir dinámicamente algunos de los componentes de AEM Communities. Estos son:
El Guía de componentes de la comunidad permite que los componentes que se pueden incluir pasen de agregarse a incluirse.
Al utilizar Handlebars idioma de creación de plantillas, el recurso no existente se incluye mediante el incluir asistente 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 añadir un componente a una página de forma dinámica, en lugar de añadirlo o incluirlo en una plantilla, consulte Descarga de componentes.
Consulte SCF Handlebars Helpers para obtener una lista y una descripción de los ayudantes personalizados disponibles en SCF.
El marco de trabajo incluye una extensión de Backbone.js, un marco de trabajo JavaScript de vista de modelo para facilitar el desarrollo de componentes interactivos enriquecidos. La naturaleza orientada a objetos admite un marco de trabajo extensible/reutilizable. La comunicación entre el cliente y el servidor se simplifica mediante la API HTTP.
El marco de trabajo aprovecha las plantillas Handlebars 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 Handlebars y proporcionan interactividad.
Se recomiendan las siguientes convenciones para definir y utilizar clases CSS:
.social-forum .topic-list .li { color: blue; }
Para personalizar el aspecto y el comportamiento de un componente de Communities en el lado del cliente, consulte Personalizaciones del lado del cliente, que incluye información sobre:
La información esencial para los desarrolladores se describe en la Aspectos básicos de funciones y componentes sección.
Encontrará información adicional para desarrolladores en la Directrices de codificación sección.
Los problemas comunes y conocidos se describen en la Solución de problemas sección.