Personalizzazione lato client

Ultimo aggiornamento: 2023-05-04
  • Argomenti:
  • Communities
    Visualizza ulteriori informazioni su questo argomento
  • Creato per:
  • User
ATTENZIONE

AEM 6.4 ha raggiunto la fine del supporto esteso e questa documentazione non viene più aggiornata. Per maggiori dettagli, consulta la nostra periodi di assistenza tecnica. Trova le versioni supportate qui.

⇐ funzioni di base Informazioni sulla personalizzazione lato server
Helpers Handlebars SCF

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

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

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

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:

  • data-component-id="{{id}}"

    viene risolto nella proprietà id dal contesto

  • data-scf-component="<resourcetype>

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

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

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:

  1. Identifica gli elementi che desideri modificare (ad esempio area compositore, pulsanti della barra degli strumenti, font del messaggio, ecc.).

  2. Identifica le classi/regole CSS che influiscono su questi elementi.

  3. Creare un file foglio di stile (.css).

  4. Includere il foglio di stile in una cartella della libreria client (clientlibs) per il sito e accertati che sia incluso nei modelli e nelle pagine con ui:includeClientLib.

  5. Ridefinire le classi e le regole CSS identificate (#2) nel foglio di stile e aggiungere stili.

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

ATTENZIONE

Qualsiasi nome di classe CSS con prefisso scf-js-* ha un uso specifico nel codice javascript. Queste classi influiscono sullo stato di un componente (ad esempio, per passare da nascosto a visibile) e non devono essere né ignorate né rimosse.

Mentre scf-js-js-ast; le classi non influiscono sugli stili, i nomi delle classi possono essere utilizzati in fogli di stile con la consapevolezza che, dato che controllano gli stati degli elementi, ci possono essere effetti collaterali.

Estensione Javascript

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

  1. Crea un componente per l’app con un jcr:resourceSuperType impostato sul valore del jcr:resourceType del componente esteso, ad esempio social/forum/components/hbs/forum
  2. Esamina il codice Javascript del componente SCF predefinito per determinare quali metodi devono essere registrati utilizzando SCF.registerComponent()
  3. Copia il codice JavaScript del componente esteso o inizia da zero
  4. Estendere il metodo
  5. Utilizzare SCF.registerComponent() per registrare tutti i metodi con le impostazioni predefinite o con gli oggetti e le viste personalizzati.

forum.js: Estensione di esempio del 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

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

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:

Variante Clientlib Pattern per la proprietà Categorie
clientlib completo cq.social.hbs.<component name>
clientlib autore cq.social.author.hbs.<component name>

Clientlibs completi

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

Queste versioni si trovano in:

  • /etc/clientlibs/social/hbs/<component name="">

Ad esempio:

  • Nodo cartella client: /etc/clientlibs/social/hbs/forum
  • Proprietà Categorie: cq.social.hbs.forum

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

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:

  • /libs/social/<feature>/components/hbs/<component name="">/clientlibs

Ad esempio:

  • Nodo cartella client: /libs/social/forum/hbs/forum/clientlibs
  • Proprietà Categorie: cq.social.author.hbs.forum

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

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

  • Velocità complessiva: Forse il desiderio è che il sito sia reattivo, ma è accettabile che la prima pagina sia un po' lenta da caricare. Se molte pagine utilizzano lo stesso JavaScript, i vari Javascript possono essere incorporati in un clientlib e citati dalla prima pagina da caricare. Il codice JavaScript in questo singolo download rimane memorizzato nella cache, riducendo al minimo la quantità di dati da scaricare per le pagine successive.
  • Tempo breve per la prima pagina: Forse il desiderio è che la prima pagina si carichi rapidamente. In questo caso, il codice Javascript si trova in più file di piccole dimensioni a cui fare riferimento solo laddove necessario.
  • Un equilibrio tra il primo caricamento della pagina e i successivi download.
⇐ funzioni di base Informazioni sulla personalizzazione lato server
Helpers Handlebars SCF

In questa pagina