Personalizzazione lato client client-side-customization

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

Due approcci principali consistono nel sovrapporre o estendere un componente.

Sovrapposizione un componente modifica il componente predefinito e influenza ogni riferimento al componente.

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

Sovrapposizioni overlays

La sovrapposizione di un componente è un metodo per apportare modifiche a un componente predefinito e interessa tutte le istanze che utilizzano l’impostazione predefinita.

La sovrapposizione viene eseguita modificando una copia del componente predefinito nel /app anziché modificare il componente originale nel /libs directory. Il componente è costruito con un percorso relativo identico, ad eccezione di "libs" 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 presente 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 durante la manutenzione delle interfacce pubbliche.

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

Per un rapido esempio di sovrapposizione del componente commenti, prova il Esercitazione sul componente Sovrapponi commenti.

Estensioni extensions

L’estensione (override) 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 è denominato in modo 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 alle app/cartella prima di eseguire la ricerca nella cartella libs/ , in modo che la progettazione o il comportamento di un componente vengano modificati a livello globale.

Per un rapido esempio di estensione del componente commenti, prova la Esercitazione sul componente Estendi commenti.

Binding Javascript javascript-binding

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

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

Per eseguire un binding di 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/risorsa facendo riferimento alle chiavi di proprietà nel modello handlebars:

{{properties.<property_name>}}

Skin CSS skinning-css

La personalizzazione dei componenti in base al tema generale del sito web può essere ottenuta mediante la "skin": cambiare colori, font, immagini, pulsanti, collegamenti, spaziatura e persino posizionamento in una certa misura.

La skin può essere ottenuta ignorando selettivamente gli stili del framework o scrivendo fogli di stile completamente nuovi. I componenti SCF definiscono classi CSS con spazi dei nomi, modulari e semantiche che influiscono sui vari elementi che compongono un componente.

Per applicare uno skin a un componente:

Gli stili personalizzati sostituiranno gli stili del framework predefiniti; il componente verrà riprodotto con il nuovo skin.

Estensione Javascript extending-javascript

Per estendere un’implementazione di componenti JavaScript, è necessario solo

forum.js: Estensione di esempio 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 la colla che consente di associare il markup generato sul lato server ai modelli e alle visualizzazioni sul lato client.

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

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 dei contenuti sul client.

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

Clientlibs completi complete-clientlibs

Le clientlib complete (non di authoring) includono dipendenze e sono utili per l’inclusione con ui:includeClientLib.

Queste versioni si trovano in:

Ad esempio:

La Guida ai componenti della community elenca le clientlib complete richieste per ogni componente SCF.

Componenti Clientlibs for Communities descrive come aggiungere clientlibs a una pagina.

Autore Clientlibs author-clientlibs

Le clientlibs della versione dell’autore vengono ridotte al minimo JavaScript necessario per implementare il componente.

Queste clientlibs non dovrebbero mai essere incluse direttamente, ma sono invece disponibili per incorporarle in altri clientlibs, creati a mano per un sito.

Queste versioni si trovano nella cartella delle librerie SCF:

Ad esempio:

Nota: anche se le librerie client di authoring non incorporano mai altre librerie, elencano le loro dipendenze. Quando vengono incorporate in altre librerie, le dipendenze non vengono estratte automaticamente e devono essere incorporate.

Le clientlibs di authoring richieste possono essere identificate inserendo "author" nelle clientlibs elencate per ogni componente SCF nel Guida ai componenti della community.

Considerazioni sull’utilizzo usage-considerations

Ogni sito è diverso nelle modalità di gestione delle librerie client. Vari fattori includono: