Framework componenti social social-component-framework

Il framework dei componenti social (SCF) semplifica il processo di configurazione, personalizzazione ed estensione dei componenti Community sia sul lato server che sul lato client.

Vantaggi del quadro:

Esplora in un'istanza di authoring o pubblicazione utilizzando la guida interattiva ai componenti della community.

Panoramica overview

In SCF, un componente è composto da un POJO SocialComponent, un Modello JS Handlebars (per riprodurre il componente) e CSS (per formattare il componente).

Un modello JS Handlebars può estendere i componenti JS del modello/vista per gestire l’interazione dell’utente con il componente sul client.

Se un componente deve supportare la modifica dei dati, l’implementazione dell’API SocialComponent può essere scritta per supportare la modifica o il salvataggio di dati in modo simile agli oggetti modello/dati nelle applicazioni web tradizionali. Inoltre, è possibile aggiungere operazioni (controller) e un servizio operativo per gestire le richieste di operazioni, eseguire la logica di business e richiamare le API sugli oggetti modello/dati.

L’API SocialComponent può essere estesa per fornire i dati richiesti da un client per un livello di visualizzazione o un client HTTP.

Rendering delle pagine per il client how-pages-are-rendered-for-client

Personalizzazione ed estensione dei componenti component-customization-and-extension

Per personalizzare o estendere i componenti, scrivi solo le sovrapposizioni e le estensioni nella directory /apps, semplificando il processo di aggiornamento alle versioni future.

Framework lato server server-side-framework

Il framework fornisce API per accedere alle funzionalità sul server e supportare l’interazione tra client e server.

API Java™ java-apis

Le API Java™ forniscono classi e interfacce astratte che vengono facilmente ereditate o sottoclassificate.

Le classi principali sono descritte nella pagina Personalizzazione lato server.

Visita Panoramica del provider di risorse di archiviazione per informazioni sull'utilizzo di UGC.

API HTTP http-api

L'API HTTP supporta la facilità di personalizzazione e la scelta delle piattaforme client per le app PhoneGap, le app native e altre integrazioni e mashup. Inoltre, l’API HTTP consente a un sito della community di funzionare come servizio senza un client, in modo tale che i componenti del framework possano essere integrati in qualsiasi pagina web basata su qualsiasi tecnologia.

API HTTP - Richieste GET http-api-get-requests

Per ogni SocialComponent, il framework fornisce un endpoint API basato su HTTP. L’endpoint è accessibile inviando una richiesta GET alla risorsa con un selettore ".social.json" e un’estensione. Utilizzando Sling, la richiesta viene trasmessa a DefaultSocialGetServlet.

DefaultSocialGetServlet

GET Request

Un servlet di GET predefinito ascolta le richieste .social.json alle quali il componente Social risponde con JSON personalizzabile.

API HTTP - Richieste POST http-api-post-requests

Oltre alle operazioni di GET (lettura), il framework definisce un modello di endpoint per abilitare altre operazioni su un componente, tra cui Crea, Aggiorna ed Elimina. Questi endpoint sono API HTTP che accettano input e rispondono con un codice di stato HTTP o con un oggetto di risposta JSON.

Questo modello di endpoint framework rende le operazioni CUD estensibili, riutilizzabili e testabili.

POST Request

È disponibile un’operazione Sling POST:per ogni operazione SocialComponent. La logica di business e il codice di manutenzione per ogni operazione sono racchiusi in un OperationService accessibile tramite l’API HTTP o da altrove come servizio OSGi. Gli hook sono forniti con supporto di estensioni di operazioni collegabili per le azioni prima/dopo.

Provider risorsa di archiviazione (SRP) storage-resource-provider-srp

Per informazioni sulla gestione dei contenuti generati dagli utenti archiviati nell'archivio dei contenuti della community, vedere:

Personalizzazioni lato server server-side-customizations

Visita Personalizzazioni lato server per informazioni sulla personalizzazione della logica di business e del comportamento di un componente Communities sul lato server.

Linguaggio del modello JS Handlebars handlebars-js-templating-language

Una delle modifiche più rilevanti del nuovo framework è l'utilizzo del linguaggio di modelli Handlebars JS (HBS), una tecnologia open-source per il rendering server-client.

Gli script HBS sono semplici, senza logica, sono compilati sia sul server che sul client, sono facili da sovrapporre e personalizzare e si associano naturalmente all'interfaccia utente del client perché HBS supporta il rendering lato client.

Il framework fornisce diversi Helper Handlebars che sono utili per lo sviluppo di SocialComponents.

Sul server, quando Sling risolve una richiesta GET, identifica lo script utilizzato per rispondere alla richiesta. Se lo script è un modello HBS (con estensione hbs), Sling delegherà la richiesta al motore Handlebars. Il motore Handlebars otterrà quindi il componente SocialComponent dal SocialComponentFactory appropriato, creerà un contesto ed eseguirà il rendering del HTML.

Nessuna restrizione di accesso no-access-restriction

I file di modello Handlebars (HBS) sono simili ai file di modello .jsp e .html, ma possono essere utilizzati per il rendering sia nel browser client che nel server. Pertanto, un browser client che richiede un modello lato client riceve un file con estensione hbs dal server.

Questo richiede che tutti i modelli HBS nel percorso di ricerca sling (qualsiasi file .hbs in /libs/ o /apps) possano essere recuperati da qualsiasi utente dall’ambiente di authoring o pubblicazione.

L'accesso HTTP ai file con estensione hbs non può essere vietato.

Aggiungere o includere un componente community add-or-include-a-communities-component

La maggior parte dei componenti di Communities deve essere aggiunto come risorsa indirizzabile Sling. Alcuni componenti di Communities possono essere inclusi in un modello come risorsa non esistente per consentire l'inclusione e la personalizzazione dinamiche della posizione in cui scrivere contenuti generati dall'utente (UGC, User-Generated Content).

In entrambi i casi, devono essere presenti anche le librerie client richieste del componente.

Aggiungi un componente

L’aggiunta di un componente si riferisce al processo di aggiunta di un’istanza di una risorsa (componente), ad esempio quando viene trascinata dal browser Componenti (barra laterale) in una pagina in modalità di modifica dell’autore.

Il risultato è un nodo figlio JCR sotto un nodo par, che è indirizzabile Sling.

Includi un componente

L'inclusione di un componente si riferisce al processo di aggiunta di un riferimento a una risorsa "non esistente" (nessun nodo JCR) all'interno del modello, ad esempio l'utilizzo di un linguaggio di script.

A partire da Adobe Experience Manager (AEM) 6.1, quando un componente viene incluso dinamicamente anziché aggiunto, è possibile modificarne le proprietà in modalità di creazione progettazione.

Solo alcuni componenti di AEM Communities possono essere inclusi in modo dinamico. Sono:

La Guida ai componenti della community consente di impedire l'aggiunta e l'inclusione di componenti inclusi.

Quando si utilizza il linguaggio di modelli Handlebars, la risorsa non esistente viene inclusa utilizzando l'helper include specificando il relativo resourceType:

{{include this.id path="comments" resourceType="social/commons/components/hbs/comments"}}

Quando si utilizza JSP, viene inclusa una risorsa utilizzando il tag cq:include:

<cq:include path="votes"
 resourceType="social/tally/components/voting" />

Helper Handlebars handlebars-helpers

Per un elenco e una descrizione degli helper personalizzati disponibili in SCF, consulta Helper Handlebars SCF.

Framework lato client client-side-framework

Framework JavaScript vista modello model-view-javascript-framework

Il framework include un'estensione di Backbone.js, un framework JavaScript per la visualizzazione del modello, per facilitare lo sviluppo di componenti avanzati e interattivi. La natura orientata agli oggetti supporta un framework estensibile/riutilizzabile. La comunicazione tra client e server è semplificata con l’API HTTP.

Il framework utilizza modelli Handlebars lato server per eseguire il rendering dei componenti per il client. I modelli si basano sulle risposte JSON generate dall’API HTTP. Le visualizzazioni si associano a HTML generate dai modelli Handlebars e forniscono interattività.

Convenzioni CSS css-conventions

Di seguito sono riportate le convenzioni consigliate per la definizione e l’utilizzo delle classi CSS:

Personalizzazioni lato client client-side-customizations

Per personalizzare l'aspetto e il comportamento di un componente Communities sul lato client, fare riferimento a Personalizzazioni sul lato client, che include informazioni su:

Funzionalità e componenti essenziali feature-and-component-essentials

Le informazioni essenziali per gli sviluppatori sono descritte nella sezione Funzionalità e componenti essenziali.

Ulteriori informazioni per gli sviluppatori sono disponibili nella sezione Coding Guidelines.

Risoluzione dei problemi troubleshooting

I problemi comuni e noti sono descritti nella sezione Risoluzione dei problemi.