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:
Esplora un'istanza di creazione o pubblicazione utilizzando la Guida interattiva ai componenti della community.
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.
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.
Il framework fornisce alle API l'accesso alle funzionalità sul server e il supporto dell'interazione tra client e server.
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.
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.
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.
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.
Per informazioni sulla gestione di UGC memorizzati in store di contenuti della community , vedi:
Per informazioni su come personalizzare la logica aziendale e il comportamento di un componente Community sul lato server, visitare Personalizzazioni lato server.
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.
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.
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" />
Per aggiungere un componente a una pagina in modo dinamico, anziché aggiungerlo o includerlo in un modello, vedere Trasferimento locale componenti.
Per un elenco e una descrizione dei supporti personalizzati disponibili in SCF, vedere Helpers Handlebars.
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à.
Di seguito sono illustrate le convenzioni consigliate per definire e utilizzare le classi CSS:
.social-forum .topic-list .li { color: blue; }
Per personalizzare l'aspetto e il comportamento di un componente Community sul lato client, fate riferimento a Client-Side Customizations, che include informazioni su:
Le informazioni essenziali per gli sviluppatori sono descritte nella sezione Feature and Component Essentials.
Ulteriori informazioni sugli sviluppatori sono disponibili nella sezione Linee guida sulla codifica.
I problemi comuni e i problemi noti sono descritti nella sezione Risoluzione dei problemi.