Framework componenti social

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:

  • Funzionale: facilità di integrazione preconfigurata con poca o nessuna personalizzazione per l’80% dei casi d’uso.
  • Skinnable: utilizzo coerente degli attributi HTML per lo stile CSS.
  • Estendibile: l’implementazione dei componenti è orientata agli oggetti e semplice da usare per la logica di business, per aggiungere facilmente un accesso aziendale incrementale al server.
  • Flessibile: semplici modelli JavaScript senza logica facilmente sovrapposti e personalizzati.
  • Accessibile: l’API HTTP supporta la pubblicazione da qualsiasi client, incluse le app mobili.
  • Portatile: integra/incorpora in qualsiasi pagina web basata su qualsiasi tecnologia.

Esplorare in un’istanza di authoring o pubblicazione utilizzando il Guida ai componenti della community.

Panoramica

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

scf-page-rendering

Personalizzazione ed estensione dei componenti

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

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

API Java

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

Le classi principali sono descritte nella Personalizzazione lato server pagina.

Visita Panoramica del provider di risorse di archiviazione per scoprire come utilizzare UGC.

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 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

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 al DefaultSocialGetServlet.

DefaultSocialGetServlet

  1. Passa la risorsa (resourceType) al SocialComponentFactoryManager e riceve un oggetto SocialComponentFactory in grado di selezionare SocialComponent che rappresenta la risorsa.

  2. Richiama la fabbrica e riceve un SocialComponent in grado di gestire la risorsa e la richiesta.

  3. Richiama SocialComponent, che elabora la richiesta e restituisce una rappresentazione JSON dei risultati.

  4. Restituisce la risposta JSON al client.

GET Request

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

scf-framework

API HTTP - Richieste POST

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.

scf-post-request

Provider risorsa di archiviazione (SRP)

Per informazioni sulla gestione di contenuti generati dagli utenti archiviati in archivio contenuti community, vedi:

Personalizzazioni lato server

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

Uno dei cambiamenti più significativi del nuovo assetto è l'uso del Handlebars JS (HBS), un popolare linguaggio 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 Handlebars Helpers utili per lo sviluppo di SocialComponents.

Sul server, quando Sling risolve una richiesta GET, identifica lo script che verrà 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

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 riceverà 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

La maggior parte dei componenti di Communities deve essere aggiunto come risorsa indirizzabile Sling. È possibile che alcuni dei componenti di Communities siano incluso in un modello come risorsa non esistente per consentire l’inclusione dinamica e la personalizzazione della posizione in cui scrivere il contenuto generato dall’utente (UGC, User Generated Content).

In entrambi i casi, i librerie client richieste deve essere presente anche.

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 un risorsa "non esistente" (nessun nodo JCR) all’interno del modello, ad esempio utilizzando 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 in modalità author *design *.

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

Il Guida ai componenti della community consente di impostare l’aggiunta o l’inclusione di componenti inclusi.

Quando si utilizza Handlebars lingua dei modelli, la risorsa non esistente viene inclusa utilizzando include helper 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" />
NOTA

Per aggiungere un componente a una pagina in modo dinamico, invece di aggiungerlo o includerlo in un modello, vedi Caricamento laterale componente.

Helper Handlebars

Consulta Helper Handlebars SCF per un elenco e una descrizione degli helper personalizzati disponibili in SCF.

Framework lato client

Framework JavaScript Visualizzazione Modello

Il quadro comprende un'estensione Backbone.js, 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 tramite l’API HTTP.

Il framework sfrutta 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 visualizzazioni si associano a HTML generate dai modelli Handlebars e forniscono interattività.

Convenzioni CSS

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

  • Utilizza nomi selettori di classi CSS con spazi chiari ed evita nomi generici come "intestazione", "immagine", ecc.
  • Definisci stili selettori di classe specifici in modo che i fogli di stile CSS funzionino correttamente con altri elementi e stili nella pagina. Esempio: .social-forum .topic-list .li { color: blue; }
  • Mantenere le classi CSS per lo stile separate dalle classi CSS per l'interfaccia utente guidata da JavaScript.

Personalizzazioni lato client

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

Funzionalità e componenti essenziali

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

Ulteriori informazioni per gli sviluppatori sono disponibili nella Linee guida per la codifica sezione.

Risoluzione dei problemi

I problemi comuni e quelli noti sono descritti nel Risoluzione dei problemi sezione.

In questa pagina