Personalizzazione lato client client-side-customization

Per personalizzare l’aspetto e/o il comportamento di un componente AEM Communities sul lato client, esistono diversi approcci.

Due approcci principali sono la sovrapposizione o l’estensione di un componente.

Sovrapposizione un componente modifica il componente di default e influisce su ogni riferimento al componente.

Estensione un componente, denominato in modo univoco, limita l’ambito delle modifiche. Il termine 'extend' viene usato in modo intercambiabile con 'override'.

Sovrapposizioni overlays

La sovrapposizione di un componente è un metodo che consente di apportare modifiche a un componente di default e di influire su tutte le varianti che lo utilizzano.

La sovrapposizione viene eseguita modificando una copia del componente predefinito in /app anziché modificare il componente originale in /libs directory. Il componente è costruito con un percorso relativo identico, ad eccezione di 'libs' che viene sostituito con 'apps'.

La directory /apps è la prima posizione in cui viene eseguita la ricerca per risolvere le richieste e, se non viene trovata, viene utilizzata la versione predefinita nella directory/libs.

Il componente predefinito nella directory /libs non deve mai essere modificato in quanto le patch e gli aggiornamenti futuri sono liberi di modificare la directory /libs in qualsiasi modo necessario mantenendo le interfacce pubbliche.

Questo è diverso da estensione un componente predefinito in cui si desidera apportare modifiche per un uso specifico, creando un percorso univoco del componente e facendo riferimento al componente predefinito originale nella directory /libs come tipo di risorsa super.

Per un rapido esempio di sovrapposizione del componente Commenti, prova Esercitazione sul componente Commenti sovrapposizione.

Estensioni extensions

L’estensione (esclusione) di un componente è un metodo per apportare modifiche per un uso specifico senza influire su tutte le istanze che utilizzano l’impostazione predefinita. Il componente esteso ha un nome univoco nella cartella /apps e fa riferimento al componente predefinito nella cartella /libs, pertanto la progettazione e il comportamento predefiniti di un componente non vengono modificati.

Questo è diverso da sovrapposizione il componente predefinito in cui la natura di Sling risolve i riferimenti relativi alla cartella apps/ prima di eseguire ricerche nella cartella libs/, pertanto la progettazione o il comportamento di un componente viene modificato a livello globale.

Per un rapido esempio di estensione del componente Commenti, prova Tutorial sul componente Estendi commenti.

Associazione JavaScript javascript-binding

Lo script HBS per il componente deve essere associato agli oggetti, ai modelli e alle viste JavaScript che implementano questa funzione.

Il valore della proprietà data-scf-component può essere l'impostazione predefinita, ad esempio social/tally/components/hbs/rating o un componente esteso (personalizzato) per funzionalità personalizzate, ad esempio weretail/components/hbs/rating.

Per associare un componente, l’intero script del componente deve essere racchiuso in un <div> con i seguenti attributi:

Ad esempio, da /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>

Proprietà personalizzate custom-properties

Quando si estende o si sovrappone un componente, è possibile aggiungere proprietà a una finestra di dialogo modificata.

È possibile accedere a tutte le proprietà impostate su un componente o una risorsa facendo riferimento alle chiavi di proprietà nel modello Handlebars:

{{properties.<property_name>}}

CSS interfaccia skinning-css

Personalizzare i componenti in modo che corrispondano al tema generale del sito web può essere ottenuto "scuoiando": cambiando colori, font, immagini, pulsanti, collegamenti, spaziatura e persino posizionando in una certa misura.

È possibile eseguire lo skin sostituendo in modo selettivo gli stili del framework o scrivendo fogli di stile completamente nuovi. I componenti SCF definiscono classi CSS con spazio dei nomi, modulari e semantiche che influiscono sui vari elementi che compongono un componente.

Per applicare lo skin a un componente:

Gli stili personalizzati sovrascriveranno gli stili di framework predefiniti e il componente verrà renderizzato con il nuovo skin.

Estensione di JavaScript extending-javascript

Per estendere un’implementazione JavaScript dei componenti, devi:

forum.js: esempio di estensione del forum - 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);

Tag script script-tags

I tag script sono parte integrante del framework lato client. Sono l’associazione che consente di associare il markup generato sul lato server ai modelli e alle viste sul lato client.

I tag di script negli script SCF non devono essere rimossi quando si sovrappongono o si sovrascrivono i componenti. I tag script SCF creati automaticamente per l’inserimento di JSON nel HTML sono identificati con l’attributo data-scf-json=true.

Clientlibs per SCF clientlibs-for-scf

L'uso di librerie lato client (clientlibs), fornisce un mezzo per organizzare e ottimizzare JavaScript e CSS utilizzati per il rendering del contenuto sul client.

Le clientlibs per SCF seguono un pattern di denominazione molto specifico per due varianti, che varia solo in base alla presenza di "author" nel nome della categoria:

Clientlibs complete complete-clientlibs

Le clientlibs complete (non di authoring) includono dipendenze e sono comode da includere con ui:includeClientLib.

Queste versioni si trovano in:

Ad esempio:

Il Guida ai componenti della community elenca le clientlibs complete necessarie per ciascun componente SCF.

Clientlibs per i componenti Communities descrive come aggiungere clientlibs a una pagina.

Creatore Clientlibs author-clientlibs

Le clientlibs della versione di authoring sono ridotte al minimo JavaScript necessario per implementare il componente.

Queste clientlibs non devono mai essere incluse direttamente, ma sono disponibili per l’incorporamento in altre clientlibs, create a mano per un sito.

Queste versioni si trovano nella cartella SCF libs:

Ad esempio:

Nota: anche se author clientlibs non incorpora mai altre librerie, elenca effettivamente le loro dipendenze. Quando sono incorporate in altre librerie, le dipendenze non vengono inserite automaticamente e devono essere incorporate.

Le clientlibs dell’autore richieste possono essere identificate inserendo "author" nelle clientlibs elencate per ogni componente SCF in Guida ai componenti della community.

Considerazioni sull’utilizzo usage-considerations

Ogni sito è diverso nel modo in cui gestisce le librerie client. Vari fattori includono: