Quadro dei componenti sociali

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

I vantaggi del quadro di riferimento:

  • Funzionale: Semplicità di integrazione con poca o nessuna personalizzazione per l’80% dei casi d’uso.
  • Pelle: Uso coerente degli attributi di HTML per lo stile CSS.
  • Estendibile: L’implementazione dei componenti è orientata agli oggetti e si basa sulla logica di business: facile da aggiungere all’accesso incrementale di business sul 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.

Esplora un’istanza di authoring o pubblicazione utilizzando l’interfaccia interattiva Guida ai componenti della community.

Panoramica

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

Un modello JS Handlebars può estendere il modello/visualizzare i componenti JS 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 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

rendering scf-page

Personalizzazione ed estensione dei componenti

Per personalizzare o estendere i componenti, scrivi solo le sovrapposizioni e le estensioni nella directory /apps per semplificare 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 astratte e interfacce facilmente ereditate o sottoclassificate.

Le classi principali sono descritte nella sezione Personalizzazione lato server pagina.

Visita Panoramica del provider di risorse di storage 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 community di essere eseguito 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 componente Social, il framework fornisce un endpoint API basato su HTTP. L’endpoint è accessibile inviando una richiesta GET alla risorsa con un selettore + estensione '.social.json'. Utilizzando Sling, la richiesta viene trasmessa al DefaultSocialGetServlet.

DefaultSocialGetServlet

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

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

  3. Richiama il 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 SocialComponent risponde con JSON personalizzabile.

quadro di scf

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

È presente un’operazione Sling POST:operation per ogni operazione SocialComponent. Il codice di logica di business e manutenzione per ogni operazione è racchiuso in un OperationService accessibile tramite l’API HTTP o da un’altra posizione come servizio OSGi. Sono forniti hook che supportano le estensioni del funzionamento collegabili per le azioni prima/dopo.

scf-post-richiesta

Provider di risorse di storage (SRP)

Per informazioni sulla gestione di UGC memorizzati nel archivio dei contenuti della community, vedi:

Personalizzazioni lato server

Visita Personalizzazioni lato server per informazioni su come personalizzare la logica di business e il comportamento di un componente Communities sul lato server.

Handlebar JS Lingua Di Modello

Una delle modifiche più evidenti nel nuovo framework è l'utilizzo del Handlebars JS (HBS)linguaggio di modellazione, 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 quadro fornisce diversi Helper manubri utili nello sviluppo di componenti social.

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 riceve quindi il SocialComponent dalla SocialComponentFactory appropriata, crea un contesto ed esegue il rendering di HTML.

Nessuna limitazione di accesso

I file modello Handlebars (HBS) (.hbs) sono analoghi ai file modello .jsp e .html , tranne per il fatto che possono essere utilizzati per il rendering sia nel browser client che sul server. Pertanto, un browser client che richiede un modello lato client riceverà un file .hbs dal server.

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

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

Aggiungere o includere un componente Community

La maggior parte dei componenti di Communities deve essere aggiunto come risorsa indirizzabile Sling. Alcuni dei componenti di Communities possono essere 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).

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

Aggiungere un componente

L’aggiunta di un componente si riferisce al processo di aggiunta di un’istanza di una risorsa (componente), ad esempio se 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.

Includere 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 nel modo autore *design *.

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

La Guida ai componenti della community consente di attivare o disattivare l’aggiunta dei componenti inclusi all’inclusione.

Quando si utilizzano le barre manuali linguaggio di template, la risorsa non esistente è inclusa utilizzando includi aiuto specificando il relativo 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, consulta Caricamento laterale componente.

Helper manubri

Vedi Helper manubrio SCF per un elenco e una descrizione degli helper personalizzati disponibili in SCF.

Framework lato client

Framework Javascript Vista Modello

Il quadro include un'estensione del Backbone.js, un framework JavaScript per la visualizzazione 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 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 ad HTML generate dai modelli Handlebars e forniscono interattività.

Convenzioni CSS

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

  • Utilizza nomi di selettore classe CSS chiaramente spaccati ed evita nomi generici come "intestazione", "immagine", ecc.
  • Definisci stili di selettore classe specifici in modo che i fogli di stile CSS funzionino bene con altri elementi e stili sulla pagina. Esempio: .social-forum .topic-list .li { color: blue; }
  • Separa 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, fai riferimento a Personalizzazioni lato client, che include informazioni su:

Funzionalità e componenti di base

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

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

Risoluzione dei problemi

Le preoccupazioni comuni e i problemi noti sono descritti nella Risoluzione dei problemi sezione .

In questa pagina