El marco de componentes sociales (SCF) simplifica el proceso de configuración, personalización y ampliación de componentes de Communities en el lado del servidor y del lado del cliente.
Ventajas del marco:
Explore en una instancia de autor o publicación mediante la Guía interactiva de componentes de comunidad.
En SCF, un componente está formado por un POJO de componente social, una plantilla de JS de controladores (para procesar el componente) y CSS (para aplicar estilo al componente).
Una plantilla de JS de Handlebars puede ampliar los componentes de JS de modelo/vista para gestionar 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 SocialComponent se puede escribir para admitir la edición o guardado de datos similares a los objetos de datos o modelos en aplicaciones web tradicionales. Además, se pueden añadir operaciones (controladores) y un servicio de operación para gestionar solicitudes de operación, realizar lógica empresarial e invocar las API en los objetos de modelo/datos.
La API SocialComponent se puede ampliar para proporcionar los datos que un cliente necesita para una capa de vista o un cliente HTTP.
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 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 página Personalización del lado del servidor.
Visite Información general del proveedor de recursos de almacenamiento para obtener más información sobre cómo trabajar con UGC.
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 puedan integrar en cualquier página web creada a partir de cualquier tecnología.
Para cada SocialComponent, el marco proporciona un extremo de API basado en HTTP. Se accede al extremo enviando una solicitud de GET al recurso con un selector '.social.json' y una extensión. Con Sling, la solicitud se entrega a DefaultSocialGetServlet
.
DefaultSocialGetServlet
Pasa el recurso (resourceType) a SocialComponentFactoryManager
y recibe un SocialComponentFactory capaz de seleccionar un SocialComponent
que represente el recurso.
Invoca la fábrica y recibe un SocialComponent
capaz de administrar 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 SocialComponent responde con JSON personalizable.
Además de las operaciones de GET (lectura), la estructura define un patrón de extremo para habilitar otras operaciones en un componente, incluidas 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 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 mediante la API HTTP o desde cualquier otra parte como servicio OSGi. Se proporcionan enlaces que admiten extensiones de operación conectables para acciones anteriores/posteriores.
Para obtener más información sobre la administración de UGC almacenado en el almacén de contenido de la comunidad, consulte:
Visite 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 de trabajo es el uso del lenguaje de plantilla Handlebars JS
(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 usuario cliente, ya que HBS admite el procesamiento en el lado del cliente.
La estructura proporciona varios Handlebars helpers 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 SocialComponentFactory apropiado, creará un contexto y renderizará el HTML.
Los archivos de plantilla Handlebars (HBS) (.hbs) son análogos a los archivos de plantilla .jsp y .html , excepto que pueden utilizarse para procesar tanto en el explorador del cliente como en el servidor. Por lo tanto, un explorador 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 el autor o la publicación.
El acceso HTTP a archivos .hbs puede no estar prohibido.
La mayoría de los componentes de Communities deben añadirse como recurso direccionable de Sling. Algunos de los componentes de Communities pueden estar incluidos en una plantilla como un recurso no existente para permitir la inclusión dinámica y la personalización de la ubicación en la que escribir el contenido generado por el usuario (UGC).
En cualquier caso, las bibliotecas de cliente necesarias del componente también deben estar presentes.
Agregar 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 Sling.
Incluir un componente
Incluir un componente hace referencia al proceso de añadir 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 añadirse, es posible editar las propiedades del componente en el modo *diseño *.
Solo se pueden incluir dinámicamente algunos de los componentes de AEM Communities. Son:
La Community Components Guide permite que los componentes incluibles no se agreguen a la inclusión.
Al utilizar el lenguaje Handlebarstemplating, el recurso no existente se incluye utilizando el asistente include especificando su resourceType:
{{include this.id path="comments" resourceType="social/commons/components/hbs/comments"}}
Al utilizar JSP, se incluye un recurso utilizando 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 agregarlo o incluirlo en una plantilla, consulte Carga de componentes.
Consulte SCF Handlebars Helpers para obtener una lista y una descripción de los asistentes personalizados disponibles en SCF.
El marco de trabajo incluye una extensión de Backbone.js, un marco 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 representar los componentes del cliente. Los modelos se basan en las respuestas JSON generadas por la API HTTP. Las vistas se vinculan a HTML generado por las plantillas Handlebars y proporcionan interactividad.
Las siguientes son convenciones recomendadas 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 sección Feature and Component Essentials .
Encontrará información adicional para desarrolladores en la sección Directrices de codificación.
Las preocupaciones comunes y los problemas conocidos se describen en la sección Resolución de problemas.