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

I vantaggi del quadro:

Funzionale: Semplicità di integrazione con poca o nessuna personalizzazione per l'80% dei casi di utilizzo.
Skinnable: Uso coerente degli attributi HTML per lo stile CSS.
Estensibile: L'implementazione dei componenti è orientata agli oggetti e si basa sulla logica aziendale, per aggiungere facilmente accessi aziendali incrementali sul server.
Flessibilità: Semplici modelli javascript senza logica, facilmente sovrapposti e personalizzati.
Accessibile: L'API HTTP supporta la pubblicazione da qualsiasi client, incluse le app mobili.
Portatile: Integrare/incorporare in qualsiasi pagina Web basata su qualsiasi tecnologia.

Esplora un'istanza di creazione o pubblicazione utilizzando la Guida interattiva ai componenti della community.

Panoramica

In SCF, un componente è composto da un POJO SocialComponent, un Modello JS Handlebars (per il rendering del componente) e CSS (per lo stile del componente).

Un modello JS Handlebars può estendere i componenti JS model/view 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/il salvataggio di dati simili a oggetti modello/dati nelle applicazioni Web tradizionali. Inoltre, è possibile aggiungere operazioni (controller) e un servizio operativo per gestire le richieste di operazioni, eseguire business logic 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

rendering scf-pagina

Personalizzazione ed estensione dei componenti

Per personalizzare o estendere i componenti, potete scrivere solo le sovrapposizioni e le estensioni nella directory /apps per semplificare il processo di aggiornamento alle release future.

Per l'interfaccia:
- Solo il file CSS deve essere modificato.
Per aspetto:
- Modificate i modelli JS e CSS.
Per Look, Feel e UX:
- Modificate i modelli JS, CSS e estendete/modificate Javascript.
Per modificare le informazioni disponibili per il modello JS o per l'endpoint GET:
- Estendere SocialComponent.
Per aggiungere l'elaborazione personalizzata durante le operazioni:
- Scrivere un OperationExtension.
Per aggiungere una nuova operazione personalizzata:
- Create una nuova operazione post Sling.
- Utilizzare OperationServices esistente, se necessario.
- Aggiungete il codice JavaScript per richiamare l'operazione dal lato client in base alle esigenze.

Framework lato server

Il framework fornisce alle API l'accesso alle funzionalità sul server e il supporto dell'interazione tra client e server.

API Java

Le API Java forniscono classi e interfacce astratte che possono essere facilmente ereditate o sottoclassificate.

Le classi principali sono descritte nella pagina Personalizzazione lato server.

Per informazioni sull'utilizzo di UGC, visitare la Panoramica sui provider di risorse di storage.

API HTTP

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 community di essere eseguito come servizio senza client, in modo che i componenti framework possano essere integrati in qualsiasi pagina Web creata su qualsiasi tecnologia.

API HTTP - Richieste di GET

Per ogni componente Social, il framework fornisce un endpoint API basato su HTTP. L'accesso all'endpoint viene effettuato inviando una richiesta di GET alla risorsa con un selettore + estensione '.social.json'. Utilizzando Sling, la richiesta viene consegnata alla DefaultSocialGetServlet.

DefaultSocialGetServlet

Passa la risorsa (resourceType) alla SocialComponentFactoryManager e riceve una SocialComponentFactory in grado di selezionare una SocialComponent che rappresenta la risorsa.
Richiama la fabbrica e riceve un SocialComponent in grado di gestire la risorsa e la richiesta.
Richiama la SocialComponent, che elabora la richiesta e restituisce una rappresentazione JSON dei risultati.
Restituisce la risposta JSON al client.

GET Request

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

scf-framework

API HTTP - Richieste POST

Oltre alle operazioni di GET (lettura), il framework definisce un pattern di endpoint per abilitare altre operazioni su un componente, tra cui Crea, Aggiorna ed Elimina. Tali endpoint sono API HTTP che accettano l'input e rispondono con codici 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

Esiste un'operazione Sling POST:operation per ogni operazione SocialComponent. Il codice business logic e di manutenzione di ciascuna operazione è incluso in un servizio OperationService accessibile tramite l'API HTTP o da un'altra ubicazione come servizio OSGi. Sono disponibili blocchi che supportano le estensioni di funzionamento collegabili per le azioni prima/dopo.

scf-post-richiesta

Provider di risorse di storage (SRP)

Per informazioni sulla gestione di UGC memorizzati in store di contenuti della community , vedi:

Panoramica del provider delle risorse di storage - Introduzione e panoramica sull'utilizzo dell'archivio.
SRP e UGC Essentials - Metodi e esempi di utilità API SRP.
Accesso a UGC con linee guida SRP - Codifica.

Personalizzazioni lato server

Per informazioni su come personalizzare la logica aziendale e il comportamento di un componente Community sul lato server, visitare Personalizzazioni lato server.

Handlebars JS Template Language

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

Gli script HBS sono semplici, senza logica, compilati sia sul server che sul client, sono facili da sovrapporre e personalizzare e si legano naturalmente con l'UX client, perché HBS supporta il rendering lato client.

Il framework fornisce diversi aiutanti del manubrio utili per lo sviluppo di SocialComponents.

Sul server, quando Sling risolve una richiesta di GET, identifica lo script che verrà utilizzato per rispondere alla richiesta. Se lo script è un modello HBS (.hbs), Sling delegherà la richiesta al motore Handlebars. Il motore handlebars otterrà il SocialComponent dalla SocialComponentFactory appropriata, creerà un contesto ed eseguirà il rendering del codice HTML.

Nessuna limitazione di accesso

I file modello handlebars (HBS) (.hbs) sono analoghi ai file 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 riceverà un file .hbs dal server.

Ciò 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'autore o dalla pubblicazione.

L'accesso HTTP ai file .hbs potrebbe non essere vietato.

Aggiungere o includere un componente Community

La maggior parte dei componenti Community deve essere aggiunta come risorsa indirizzabile Sling. Alcuni componenti Community possono essere inclusi in un modello come risorsa non esistente per consentire l'inclusione e la personalizzazione dinamiche della posizione in cui scrivere il contenuto generato dall'utente (UGC).

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

Aggiunta di un componente

L’aggiunta di un componente fa riferimento al processo di aggiunta di un’istanza di una risorsa (componente), ad esempio quando viene trascinata dal browser Componenti (barra laterale) su 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 fa riferimento al processo di aggiunta di un riferimento a una risorsa "non esistente" (nessun nodo JCR) all'interno del modello, ad esempio l'uso di un linguaggio di script.

A partire da AEM 6.1, quando un componente viene incluso dinamicamente invece che aggiunto, è possibile modificare le proprietà del componente nel modo *design *authoring.

È possibile includere in modo dinamico solo alcuni dei componenti AEM Communities. Sono:

La Guida ai componenti della community consente di passare dall'aggiunta all'inclusione di componenti inclusi.

Quando si utilizza il linguaggio Handlebarstemplating, la risorsa non esistente viene inclusa utilizzando l' helpering include specificandone resourceType:

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

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

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

NOTA

Per aggiungere un componente a una pagina in modo dinamico, anziché aggiungerlo o includerlo in un modello, vedere Trasferimento locale componenti.

Helper manubrio

Per un elenco e una descrizione dei supporti personalizzati disponibili in SCF, vedere Helpers Handlebars.

Framework lato client

Framework Javascript vista modello

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

Il framework utilizza i 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 viste si legano al codice HTML generato dai modelli Handlebars e forniscono interattività.

Convenzioni CSS

Di seguito sono illustrate le convenzioni consigliate per definire e utilizzare le classi CSS:

Utilizzate nomi di selettore di classe CSS chiaramente associati al nome ed evitate nomi generici quali "heading", "image", ecc.
Definite stili di selettore di classe specifici in modo che i fogli di stile CSS funzionino correttamente con altri elementi e stili sulla pagina. Esempio: .social-forum .topic-list .li { color: blue; }
Separate le classi CSS per lo stile dalle classi CSS per gli UX guidate da JavaScript.

Personalizzazioni lato client

Per personalizzare l'aspetto e il comportamento di un componente Community sul lato client, fate riferimento a Client-Side Customizations, che include informazioni su: