Personalización del lado del cliente client-side-customization

Para personalizar el aspecto y/o el comportamiento de un componente de AEM Communities en el lado del cliente, existen varios enfoques.

Dos enfoques principales son superponer o ampliar un componente.

Superposición un componente cambia el componente predeterminado y afecta a todas las referencias al componente.

Ampliación un componente, al tener un nombre único, limita el alcance de los cambios. El término "ampliar" se utiliza de forma intercambiable con "anular".

Superposiciones overlays

Superponer un componente es un método para realizar modificaciones en un componente predeterminado y afectar a todas las instancias que lo utilicen.

La superposición se realiza modificando una copia del componente predeterminado en /apps en lugar de modificar el componente original en /libs directorio. El componente se construye con una ruta relativa idéntica, excepto que "libs" se sustituye por "apps".

El directorio /apps es el primer lugar en el que se busca para resolver las solicitudes y, si no se encuentra, se utiliza la versión predeterminada ubicada en el directorio /libs.

El componente predeterminado del directorio /libs nunca debe modificarse, ya que los parches y actualizaciones futuros son libres de alterar el directorio /libs de cualquier manera necesaria mientras se mantienen las interfaces públicas.

Esto es diferente de ampliar componente predeterminado en el que se desea realizar modificaciones para un uso específico, crear una ruta única al componente y confiar en hacer referencia al componente predeterminado original en el directorio /libs como tipo de superrecurso.

Para ver un ejemplo rápido de superposición del componente de comentarios, pruebe con la Tutorial del componente Comentarios de superposición.

Extensiones extensions

La ampliación (anulación) de un componente es un método para realizar modificaciones para un uso específico sin afectar a todas las instancias que utilizan el valor predeterminado. El componente extendido tiene un nombre único en la carpeta /apps y hace referencia al componente predeterminado en la carpeta /libs, por lo que el diseño y el comportamiento predeterminados de un componente no se modifican.

Esto es diferente de superposición el componente predeterminado en el que la naturaleza de Sling resuelve las referencias relativas a las aplicaciones/carpeta antes de buscar en la carpeta libs/ , por lo que el diseño o el comportamiento de un componente se modifican globalmente.

Para ver un ejemplo rápido de cómo ampliar el componente de comentarios, pruebe con la Tutorial del componente Extensión de comentarios.

Enlace De Javascript javascript-binding

El script HBS del componente debe enlazarse a los objetos, modelos y vistas de JavaScript que implementan esta función.

El valor de la variable data-scf-component puede ser el valor predeterminado, como social/tally/components/hbs/rating o un componente extendido (personalizado) para funciones personalizadas, como weretail/components/hbs/rating.

Para enlazar un componente, todo el script de componente debe estar dentro de un <div> con los siguientes atributos:

Por ejemplo, desde /apps/weretail/components/hbs/rating/rating.hbs:

<div class="we-Rating" data-component-id="{{id}}" data-scf-component="weretail/components/hbs/rating">

     <!-- HTML with HBS accessing the rating component -->

</div>

Propiedades personalizadas custom-properties

Al ampliar o superponer un componente, es posible añadir propiedades a un cuadro de diálogo modificado.

Se puede acceder a todas las propiedades establecidas en un componente/recurso haciendo referencia a las claves de propiedad de la plantilla de controladores:

{{properties.<property_name>}}

Skin CSS skinning-css

La personalización de componentes para que coincidan con el tema general del sitio web se puede lograr 'desollando': cambiando colores, fuentes, imágenes, botones, enlaces, espaciado e incluso posicionamiento en cierta medida.

El desollado se puede lograr anulando selectivamente los estilos de marco o escribiendo hojas de estilo completamente nuevas. Los componentes SCF definen clases CSS espaciadas por nombres, modulares y semánticas que afectan a los distintos elementos que conforman un componente.

Para deslizar un componente:

Los estilos personalizados ahora anulan los estilos de marco predeterminados y el componente se procesará con el nuevo aspecto.

Ampliación de Javascript extending-javascript

Para ampliar una implementación de JavaScript de componentes, solo es necesario

forum.js: Extensión de muestra del Foro - HBS forum-js-sample-extension-of-forum-hbs

(function($CQ, _, Backbone, SCF) {
    "use strict";
    var GMForumView = SCF.ForumView.extend({
        viewName: "GMForum",
        showComposer: function(e) {
            SCF.ForumView.prototype.toggleComposer.apply(this);
            var cancel = this.$el.find('.cancel-new-topic');
            cancel.toggle();
        },
        hideComposer: function(e) {
            SCF.ForumView.prototype.toggleComposer.apply(this);
            var cancel = this.$el.find('.cancel-new-topic');
            cancel.toggle();
        }
    });

    SCF.registerComponent('social/forum/components/hbs/post', SCF.Post, SCF.PostView);
    SCF.registerComponent('social/forum/components/hbs/topic', SCF.Topic, SCF.TopicView);
    SCF.registerComponent('social/forum/components/hbs/forum', SCF.Forum, GMForumView );
})($CQ, _, Backbone, SCF);

Etiquetas de secuencias de comandos script-tags

Las etiquetas de script son una parte inherente del marco del lado del cliente. Son el pegamento que ayuda a enlazar el marcado generado en el servidor con los modelos y vistas en el lado del cliente.

Las etiquetas de script de los scripts SCF no deben eliminarse al superponer o anular componentes. Las etiquetas de script de SCF creadas automáticamente para inyectar JSON en el HTML se identifican con el atributo . data-scf-json=true.

Clientlibs para SCF clientlibs-for-scf

El uso de bibliotecas del lado del cliente (clientlibs), proporciona un medio para organizar y optimizar el JavaScript y CSS utilizado para procesar contenido en el cliente.

Las clientlibs para SCF siguen un patrón de nomenclatura muy específico para dos variantes, que solo varía por la presencia de "autor" en el nombre de la categoría:

Clientlibs completos complete-clientlibs

Las clientlibs completas (no de autor) incluyen dependencias y resultan adecuadas para incluirlas con ui:includeClientLib.

Estas versiones se encuentran en:

Por ejemplo:

La variable Guía de componentes de comunidad enumera todas las clientlibs necesarias para cada componente SCF.

Clientlibs para componentes de Communities describe cómo agregar clientlibs a una página.

Author Clientlibs author-clientlibs

La versión de autor clientlibs se elimina al código Javascript mínimo necesario para implementar el componente.

Estos clientlibs nunca deben incluirse directamente, sino que están disponibles para incrustarse en otros clientlibs, que están diseñados a mano para un sitio.

Estas versiones se encuentran en la carpeta de bibliotecas de SCF:

Por ejemplo:

Nota: aunque clientlibs de autor nunca incrusta otras bibliotecas, sí enumeran sus dependencias. Cuando se incrustan en otras bibliotecas, las dependencias no se extraen automáticamente y también deben incrustarse.

Los clientlibs de autor requeridos se pueden identificar insertando "author" en los clientlibs enumerados para cada componente SCF en el Guía de componentes de comunidad.

Consideraciones de uso usage-considerations

Cada sitio es diferente en la forma en que administra las bibliotecas de cliente. Varios factores incluyen: