Funzioni di base SRP e UGC

Introduzione

Se non avete familiarità con il provider delle risorse di storage (SRP) e il suo rapporto con il contenuto generato dall'utente (UGC), visitate Panoramica del provider delle risorse di storage e archiviazione di contenuto community.

Questa sezione della documentazione fornisce alcune informazioni essenziali sull'SRP e sull'UGC.

API StorageResourceProvider

L'API SocialResourceProvider (API SRP) è un'estensione di diverse API Sling Resource Provider. Include il supporto dell'impaginazione e dell'incremento atomico (utile per il conteggio e il punteggio).

Le query sono necessarie per i componenti SCF in quanto è necessario ordinare per data, disponibilità, numero di voti e così via. Tutte le opzioni SRP dispongono di meccanismi di query flessibili che non si affidano al bucketing.

La posizione di storage SRP incorpora il percorso del componente. L'API SRP deve sempre essere utilizzata per accedere a UGC, in quanto il percorso principale dipende dall'opzione SRP selezionata, come ASRP, MSRP o JSRP.

L'API SRP non è una classe astratta, è un'interfaccia. L'implementazione personalizzata non dovrebbe essere eseguita in modo leggero, in quanto i vantaggi dei futuri miglioramenti alle implementazioni interne non sarebbero stati apportati al momento dell'aggiornamento a una nuova versione.

I mezzi per utilizzare l'API SRP sono attraverso le utility fornite, come quelle presenti nel pacchetto SocialResourceUtilities.

Durante l'aggiornamento da AEM 6.0 o versioni precedenti, sarà necessario migrare UGC per tutti gli SRP, per i quali è disponibile uno strumento Open Source. See Upgrading to AEM Communities 6.3.

Nota

Storicamente, le utility per l'accesso a UGC sono state trovate nel pacchetto SocialUtils, che non esiste più.

Per le utility sostitutive, consultate Refactoring SocialUtils.

Metodo di utilità per accedere all'UGC

Per accedere a UGC, utilizzate un metodo del pacchetto SocialResourceUtilities che restituisce un percorso adatto per l'accesso a UGC da SRP e sostituisce il metodo obsoleto trovato nel pacchetto SocialUtils.

Di seguito è riportato un esempio minimo di utilizzo del metodo resourceToUGCStoragePath() in un servlet:

import com.adobe.cq.social.srp.utilities.api.SocialResourceUtilities;

@Reference
private SocialResourceUtilities socialResourceUtilities;

@Override
protected void doGet(final SlingHttpServletRequest request, final SlingHttpServletResponse response) throws ServletException, IOException {
  String ugcPath = socialResourceUtilities.resourceToUGCStoragePath(request.getResource());
  // rest of servlet
}

Per altre sostituzioni di SocialUtils, consultate Refactoring di SocialUtils.

Per le linee guida per la codifica, visitate Accesso a UGC con SRP.

ATTENZIONE

Il percorso resourceToUGCStoragePath() restituisce *non *adatto per il controllo ACL.

Metodo di utilità per accedere agli ACL

Alcune implementazioni SRP, come ASRP e MSRP, memorizzano il contenuto della community in database che non forniscono alcuna verifica ACL. I nodi shadow forniscono una posizione nell'archivio locale in cui è possibile applicare gli ACL.

Utilizzando l'API SRP, tutte le opzioni SRP eseguono lo stesso controllo della posizione dell'ombra prima di tutte le operazioni CRUD.

Per controllare gli ACL, utilizzare un metodo che restituisca un percorso adatto per verificare le autorizzazioni applicate all'UGC della risorsa.

Di seguito è riportato un semplice esempio di utilizzo del metodo resourceToACLPath() in un servlet:

import com.adobe.cq.social.srp.utilities.api.SocialResourceUtilities;

@Reference
private SocialResourceUtilities socialResourceUtilities;

@Override
protected void doGet(final SlingHttpServletRequest request, final SlingHttpServletResponse response) throws ServletException, IOException {
  String aclPath = socialResourceUtilities.resourceToACLPath(request.getResource());
  // rest of servlet
}
ATTENZIONE

Il percorso restituito da resourceToACLPath() non è *adatto per accedere all'UGC stesso.

Le seguenti descrizioni della posizione di storage possono essere di aiuto durante lo sviluppo con JSRP o forse MSRP. Attualmente non esiste alcuna interfaccia utente per accedere a UGC memorizzati in ASRP, in quanto esistono per gli strumenti JSRP (CRXDE Lite) e MSRP (MongoDB).

posizione del componente

Quando un membro accede a UGC nell’ambiente di pubblicazione, interagisce con un componente come parte di un sito AEM.

Un esempio di tale componente è il componente commenti presente nel sito Community Components Guide . Il percorso del nodo del commento nell'archivio locale è:

  • Percorso componente = /content/community-components/it/comments/jcr:content/content/incluso/comments

posizione nodo ombra

La creazione di UGC crea anche un nodo ombra a cui vengono applicati gli ACL necessari. Il percorso del nodo shadow corrispondente nell'archivio locale è il risultato della precedenza del percorso principale del nodo shadow al percorso del componente:

  • Percorso directory principale = /content/usergenerated
  • Nodo ombreggiatura commento = /content/usergenerated/content/community-components/it/comments/jcr:content/content/incluso/comments

UGC, posizione

L'UGC viene creato in nessuna di queste posizioni e dovrebbe essere accessibile solo utilizzando un metodo di utilità che richiama l'API SRP.

  • Percorso radice = /content/usergenerated/asi/srp-choice
  • Nodo UGC per JSRP = /content/usergenerated/asi/jcr/content/community-components/en/comments/jcr:content/content/includable/comments/srzd-let_it_be_

Attenzione: per JSRP, il nodo UGC sarà presente solo nell’istanza AEM (autore o pubblicazione) in cui è stato immesso. Se immessa in un’istanza di pubblicazione, la moderazione non sarà possibile dalla console di moderazione sull’autore.

  • Panoramica del provider di risorse di storage - Introduzione e panoramica sull'utilizzo del repository
  • Accesso a UGC con SRP - linee guida di codifica
  • Refactoring SocialUtils - Mappatura di metodi di utilità obsoleti ai metodi di utilità SRP correnti

In questa pagina