Concetti di base dell’AEM

Prerequisiti per lo sviluppo sull’AEM

Per sviluppare in aggiunta all’AEM, ha bisogno delle seguenti competenze:

• Conoscenza di base delle tecniche di applicazione web, tra cui:

  • ciclo request-response (XMLHttpRequest / XMLHttpResponse)
  • HTML
  • CSS
  • JavaScript

• Conoscenza operativa di Experience Server (CRX), incluso Content Explorer

• Per lo sviluppo nell’interfaccia classica, è necessaria anche una conoscenza di base di JSP (JavaServer Pages), inclusa la possibilità di comprendere e modificare semplici esempi JSP.

Si consiglia inoltre di leggere e seguire i Linee guida e best practice.

Archivio dei contenuti Java™

Lo standard Java™ Content Repository (JCR), JSR 283specifica un modo indipendente dal fornitore e indipendente dall’implementazione per accedere al contenuto in modo bidirezionale a livello granulare all’interno di un archivio di contenuti.

Il piombo delle specifiche è detenuto da Adobe Research (Switzerland) AG.

Il API JCR 2.0 pacchetto, javax.jcr.* viene utilizzato per l'accesso diretto e la manipolazione del contenuto del repository.

Experience Server (CRX) e Jackrabbit

Experience Server fornisce i servizi di esperienza su cui si basa l’AEM, che possono essere utilizzati per creare applicazioni personalizzate e incorpora il Content Repository basato su Jackrabbit.

Apache Jackrabbit è un’implementazione open source, pienamente conforme, dell’API 2.0 JCR.

Elaborazione richiesta Sling

Introduzione a Sling

L’AEM viene creato utilizzando Sling: framework di applicazioni web basato sui principi REST che consente di sviluppare facilmente applicazioni orientate ai contenuti. Sling utilizza come archivio dati un archivio JCR, come Apache Jackrabbit o, nel caso dell’AEM, l’archivio contenuti CRX. Sling ha contribuito alla Apache Software Foundation; ulteriori informazioni sono disponibili su Apache.

Utilizzando Sling, il tipo di contenuto di cui eseguire il rendering non è la prima considerazione di elaborazione. Al contrario, la considerazione principale è se l’URL viene risolto in un oggetto di contenuto per il quale è possibile trovare uno script per eseguire il rendering. Questo fornisce un supporto eccellente agli autori di contenuti web per creare pagine facilmente personalizzate in base alle loro esigenze.

I vantaggi di questa flessibilità sono evidenti nelle applicazioni con un’ampia gamma di elementi di contenuto diversi o quando servono pagine facilmente personalizzabili. In particolare, quando si implementa un sistema di gestione dei contenuti web come WCM nella soluzione AEM.

Consulta Scopri Sling in 15 minuti per i primi passaggi per lo sviluppo con Sling.

Il diagramma seguente spiega la risoluzione dello script Sling: mostra come passare da una richiesta HTTP a un nodo di contenuto, da un nodo di contenuto a un tipo di risorsa, da un tipo di risorsa a uno script e quali variabili di script sono disponibili.

Il diagramma seguente spiega tutti i parametri di richiesta nascosti ma potenti che è possibile utilizzare quando si tratta di SlingPostServlet, il gestore predefinito per tutte le richieste di POST che offre opzioni infinite per la creazione, la modifica, l’eliminazione, la copia e lo spostamento di nodi nell’archivio.

Sling è incentrato sui contenuti

Sling è incentrato sui contenuti. Ciò significa che l’elaborazione si concentra sul contenuto, in quanto ogni richiesta (HTTP) è mappata sul contenuto sotto forma di risorsa JCR (un nodo dell’archivio):

• la prima destinazione è la risorsa (nodo JCR) contenente il contenuto
• in secondo luogo, la rappresentazione, o script, si trova dalle proprietà della risorsa combinate con alcune parti della richiesta (ad esempio, selettori e/o estensione)

Sling RESTful

Grazie alla filosofia incentrata sui contenuti, Sling implementa un server orientato a REST e quindi presenta un nuovo concetto nei framework delle applicazioni web. I vantaggi sono i seguenti:

• molto RESTful, non solo in superficie; le risorse e le rappresentazioni sono modellate correttamente all'interno del server

• rimuove uno o più modelli di dati

  • in precedenza erano necessari i seguenti elementi: struttura URL, oggetti di business, schema DB;
  • ora è ridotto a: URL = risorsa = struttura JCR

Scomposizione URL

In Sling, l’elaborazione è guidata dall’URL della richiesta dell’utente. Questo definisce il contenuto da visualizzare con gli script appropriati. A questo scopo, le informazioni vengono estratte dall’URL.

Se analizziamo il seguente URL:

https://myhost/tools/spy.printable.a4.html/a/b?x=12

Possiamo suddividerlo nelle sue parti composite:

protocollo HTTP

host Nome del sito web.

percorso contenuto Percorso che specifica il contenuto da riprodurre. Viene utilizzato in combinazione con l’estensione; in questo esempio vengono tradotti in tools/spy.html.

selettore/i Utilizzato per metodi alternativi di rendering del contenuto; in questo esempio, una versione in formato A4 compatibile con la stampante.

estensione Formato contenuto; specifica anche lo script da utilizzare per il rendering.

suffisso Può essere utilizzato per specificare informazioni aggiuntive.

param(s) Qualsiasi parametro necessario per il contenuto dinamico.

Da URL a contenuto e script

Utilizzando questi principi:

• la mappatura utilizza il percorso del contenuto estratto dalla richiesta per individuare la risorsa
• quando si trova la risorsa appropriata, il tipo di risorsa sling viene estratto e utilizzato per individuare lo script da utilizzare per il rendering del contenuto

La figura seguente illustra il meccanismo utilizzato, che verrà descritto più dettagliatamente nelle sezioni seguenti.

Con Sling, puoi specificare quale script esegue il rendering di una determinata entità (impostando il sling:resourceType nel nodo JCR. Questo meccanismo offre maggiore libertà rispetto a uno in cui lo script accede alle entità di dati (come farebbe un’istruzione SQL in uno script PHP) in quanto una risorsa può avere diverse rappresentazioni.

Mappatura delle richieste alle risorse

La richiesta è suddivisa ed è possibile estrarre le informazioni necessarie. Nell’archivio viene eseguita la ricerca della risorsa richiesta (nodo del contenuto):

• primo Sling controlla se un nodo esiste nella posizione specificata nella richiesta; ad esempio ../content/corporate/jobs/developer.html
• se non viene trovato alcun nodo, l’estensione viene rilasciata e la ricerca ripetuta; ad esempio ../content/corporate/jobs/developer
• Se non viene trovato alcun nodo, Sling restituirà il codice http 404 (Not Found).

Sling consente anche di utilizzare come risorse elementi diversi dai nodi JCR, ma si tratta di una funzione avanzata.

Individuazione dello script

Quando si trova la risorsa appropriata (nodo di contenuto), il tipo di risorsa sling viene estratto. Questo è un percorso che individua lo script da utilizzare per il rendering del contenuto.

Percorso specificato da sling:resourceType può essere:

• assoluto

• relativo, a un parametro di configurazione

  I percorsi relativi sono consigliati da Adobe in quanto aumentano la portabilità.

Tutti gli script Sling vengono memorizzati nelle sottocartelle di /apps o /libs, che verranno cercati in questo ordine (vedi Personalizzazione di componenti e altri elementi).

Altri punti da notare sono:

• quando il metodo (GET, POST) è obbligatorio, viene specificato in maiuscolo in base alla specifica HTTP, ad esempio jobs.POST.esp (vedi sotto)

• sono supportati vari motori di script:

  • HTL (HTML Template Language, sistema di modelli lato server preferito e consigliato di Adobe Experience Manager per HTML): .html
  • Pagine ECMAScript (JavaScript) (esecuzione lato server): .esp, .ecma
  • Pagine Java™ Server (esecuzione lato server): .jsp
  • Java™ Servlet Compiler (esecuzione lato server): .java
  • Modelli JavaScript (esecuzione lato client): .jst

L'elenco dei motori di script supportati dall'istanza di AEM specificata è elencato nella console di gestione Felix ( http://<host>:<port>/system/console/slingscripting).

Inoltre, Apache Sling supporta l’integrazione con altri motori di script popolari (ad esempio Groovy, JRuby, Freemarker) e offre un modo per integrare nuovi motori di script.

Utilizzando l'esempio precedente, se sling:resourceType è hr/jobs quindi per:

• Richieste GET/HEAD e URL con estensione html (tipi di richiesta predefiniti, formato predefinito)

  Lo script è /apps/hr/jobs/jobs.esp; l’ultima sezione di sling:resourceType forma il nome del file.

• Richieste POST (tutti i tipi di richiesta tranne GET/HEAD, il nome del metodo deve essere in maiuscolo)

  POST viene utilizzato nel nome dello script.

  Lo script è /apps/hr/jobs/jobs.POST.esp.

• URL in altri formati, che non terminano con .html

  Ad esempio ../content/corporate/jobs/developer.pdf

  Lo script sarà /apps/hr/jobs/jobs.pdf.esp; il suffisso viene aggiunto al nome dello script.

• URL con selettori

  I selettori possono essere utilizzati per visualizzare lo stesso contenuto in un formato alternativo. Ad esempio una versione stampabile, un feed rss o un riepilogo.

  Se si considera una versione della stampante in cui il selettore potrebbe essere stampa; come in ../content/corporate/jobs/developer.print.html

  Lo script sarà /apps/hr/jobs/jobs.print.esp; il selettore viene aggiunto al nome dello script.

• Se non è stato definito sling:resourceType:

  • il percorso del contenuto verrà utilizzato per cercare uno script appropriato se ResourceTypeProvider basato sul percorso è attivo.

    Ad esempio, lo script per ../content/corporate/jobs/developer.html genera una ricerca in /apps/content/corporate/jobs/.

  • verrà utilizzato il tipo di nodo principale.

• Se non viene trovato alcuno script, verrà utilizzato lo script predefinito.

  La rappresentazione predefinita è attualmente supportata come testo normale (.txt), HTML (.html) e JSON (.json), che elencheranno tutte le proprietà del nodo (formattate in modo appropriato). La rappresentazione predefinita per l’estensione .res, o per le richieste senza estensione di richiesta, consiste nello spool della risorsa (ove possibile).

• Per la gestione degli errori http (codici 403 o 404), Sling cercherà uno script in:

  • la posizione /apps/sling/servlet/errorhandler per script personalizzati
  • o la posizione degli script standard /libs/sling/servlet/errorhandler/403.esp o 404.esp rispettivamente.

Se per una determinata richiesta sono applicabili più script, viene selezionato lo script con la corrispondenza migliore. Più specifica è una corrispondenza, migliore sarà; in altre parole, più il selettore corrisponderà, indipendentemente da qualsiasi estensione di richiesta o corrispondenza del nome del metodo.

Ad esempio, considera una richiesta di accesso alla risorsa
/content/corporate/jobs/developer.print.a4.html
di tipo
sling:resourceType="hr/jobs"

Supponiamo di avere il seguente elenco di script nella posizione corretta:

1. GET.esp
2. jobs.esp
3. html.esp
4. print.esp
5. print.html.esp
6. print/a4.esp
7. print/a4/html.esp
8. print/a4.html.esp

Quindi l'ordine di preferenza sarebbe (8) - (7) - (6) - (5) - (4) - (3) - (2) - (1).

Oltre ai tipi di risorse (definiti principalmente dalla sling:resourceType proprietà) è inoltre disponibile il super tipo di risorsa. Questo è generalmente indicato dal sling:resourceSuperType proprietà. Questi super tipi vengono considerati anche quando si tenta di trovare uno script. Il vantaggio dei super-tipi di risorse è che possono formare una gerarchia di risorse in cui il tipo di risorsa predefinito sling/servlet/default (utilizzato dai servlet predefiniti) è effettivamente la radice.

Il super tipo di risorsa di una risorsa può essere definito in due modi:

• da sling:resourceSuperType della risorsa.
• da sling:resourceSuperType proprietà del nodo a cui è associato sling:resourceType punti.

Ad esempio:

• /

  • a

  • b

    • sling:resourceSuperType = a

  • c

    • sling:resourceSuperType = b

  • x

    • sling:resourceType = c

  • y

    • sling:resourceType = c
    • sling:resourceSuperType = a

Gerarchia dei tipi di:

• /x
  • è [ c, b, a, <default>]
• mentre per /y
  • la gerarchia è [ c, a, <default>]

Questo perché /y ha sling:resourceSuperType proprietà mentre /x does not e pertanto il relativo supertipo viene preso dal relativo tipo di risorsa.

Gli script Sling non possono essere chiamati direttamente

All’interno di Sling, gli script non possono essere chiamati direttamente in quanto ciò infrangerebbe il concetto rigoroso di server REST; è possibile combinare risorse e rappresentazioni.

Se chiami direttamente la rappresentazione (lo script), nascondi la risorsa all’interno dello script, pertanto il framework (Sling) non ne è più a conoscenza. In questo modo si perdono alcune funzionalità:

• gestione automatica di metodi http diversi da GET, tra cui:

  • POST, PUT e DELETE gestiti con un’implementazione sling predefinita
  • il POST.jsp script nel percorso sling:resourceType

• l'architettura del codice non è più pulita né strutturata in modo chiaro come dovrebbe essere; di primaria importanza per lo sviluppo su larga scala

API Sling

Questo utilizza il pacchetto API Sling, org.apache.sling.* e le librerie di tag.

Riferimento a elementi esistenti mediante sling:include

Un'ultima considerazione è la necessità di fare riferimento agli elementi esistenti all'interno degli script.

Gli script più complessi (aggregazione di script) potrebbero dover accedere a più risorse (ad esempio navigazione, barra laterale, piè di pagina, elementi di un elenco) includendo resource.

A questo scopo puoi utilizzare sling:include("/<path>/<resource>"). Ciò includerà effettivamente la definizione della risorsa di riferimento, come nell’istruzione seguente che fa riferimento a una definizione esistente per il rendering delle immagini:

%><sling:include resourceType="geometrixx/components/image/img"/><%

OSGI

OSGi definisce un’architettura per lo sviluppo e la distribuzione di librerie e applicazioni modulari (nota anche come Dynamic Module System per Java). I contenitori OSGi ti consentono di suddividere l’applicazione in singoli moduli (file jar con metadati aggiuntivi e denominati bundle nella terminologia OSGi) e di gestire le dipendenze incrociate tra di essi con:

• servizi implementati all’interno del contenitore
• un contratto tra il contenitore e l’applicazione

Questi servizi e contratti forniscono un’architettura che consente ai singoli elementi di scoprirsi dinamicamente a vicenda per collaborare.

Un framework OSGi offre quindi operazioni dinamiche di caricamento/scaricamento, configurazione e controllo di questi bundle, senza richiedere il riavvio.

Questa architettura consente di estendere Sling con moduli specifici per le applicazioni. Sling, e quindi CQ5, utilizza Apache Felix implementazione di OSGI (Open Services Gateway initiative) basata sulle specifiche della piattaforma di servizi OSGi Release 4 Version 4.2. Sono entrambe raccolte di bundle OSGi in esecuzione all’interno di un framework OSGi.

Questo consente di eseguire le azioni seguenti su uno qualsiasi dei pacchetti all’interno dell’installazione:

• installare
• inizio
• stop
• aggiorna
• disinstalla
• visualizzare lo stato corrente
• accedere a informazioni più dettagliate (ad es. nome simbolico, versione, posizione, ecc.) sui bundle specifici

Consulta la console web, Configurazione OSGI e Impostazioni configurazione OSGi per ulteriori informazioni.

Oggetti di sviluppo nell’ambiente AEM

Di seguito sono riportati gli elementi di maggiore interesse per lo sviluppo:

Elemento Un elemento è un nodo o una proprietà.

Per informazioni dettagliate sulla manipolazione degli oggetti Item, consultare JavaScript dell’interfaccia javax.jcr.Item

Nodo (e relative proprietà) I nodi e le loro proprietà sono definiti nella specifica JCR API 2.0 (JSR 283). Memorizzano il contenuto, le definizioni degli oggetti, gli script di rendering e altri dati.

I nodi definiscono la struttura del contenuto e le relative proprietà memorizzano il contenuto effettivo e i metadati.

I nodi di contenuto guidano il rendering. Sling ottiene il nodo del contenuto dalla richiesta in ingresso. La proprietà sling:resourceType di questo nodo punta al componente di rendering Sling da utilizzare.

Un nodo, che è un nome JCR, è anche chiamato risorsa nell’ambiente Sling.

Ad esempio, per ottenere le proprietà del nodo corrente, puoi utilizzare il seguente codice nello script:

PropertyIterator properties = currentNode.getProperties();

Con currentNode come oggetto nodo corrente.

Per ulteriori informazioni sulla manipolazione degli oggetti Node, consultare JavaScript.

Widget In AEM tutti gli input dell'utente sono gestiti da widget. Queste vengono spesso utilizzate per controllare la modifica di un contenuto.

Le finestre di dialogo vengono create combinando widget.

L’AEM è stato sviluppato utilizzando la libreria ExtJS di widget.

Finestra di dialogo Una finestra di dialogo è un tipo speciale di widget.

Per modificare il contenuto, l’AEM utilizza le finestre di dialogo definite dallo sviluppatore dell’applicazione. Combinano una serie di widget per presentare all’utente tutti i campi e le azioni necessari per modificare il contenuto correlato.

Le finestre di dialogo vengono utilizzate anche per la modifica dei metadati e da vari strumenti di amministrazione.

Componente Un componente software è un elemento di sistema che offre un servizio o un evento predefinito e in grado di comunicare con altri componenti.

All’interno dell’AEM un componente viene spesso utilizzato per riprodurre il contenuto di una risorsa. Quando la risorsa è una pagina, il rendering del componente viene denominato Componente di livello principale o Componente pagina. Tuttavia, un componente non deve eseguire il rendering del contenuto né essere collegato a una risorsa specifica; ad esempio, un componente di navigazione visualizza informazioni su più risorse.

La definizione di un componente comprende:,

• il codice utilizzato per il rendering del contenuto
• una finestra di dialogo per l’input dell’utente e la configurazione del contenuto risultante.

Modello Un modello è la base per un tipo specifico di pagina. Quando si crea una pagina nella scheda Siti Web, l'utente deve selezionare un modello. La nuova pagina viene quindi creata copiando questo modello.

Un modello è una gerarchia di nodi con la stessa struttura della pagina da creare, ma senza alcun contenuto effettivo.

Definisce il componente Pagina utilizzato per eseguire il rendering della pagina e il contenuto predefinito (contenuto principale di primo livello). Il contenuto definisce il modo in cui viene riprodotto poiché l’AEM è incentrato sui contenuti.

Componente Pagina (Componente Di Livello Superiore) Componente da utilizzare per il rendering della pagina.

Pagina Una pagina è un’istanza di un modello.

Una pagina ha un nodo di gerarchia di tipo cq:Page e un nodo di contenuto di tipo cq:PageContent. La proprietà sling:resourceType del nodo di contenuto punta al componente Pagina utilizzato per il rendering della pagina.

Ad esempio, per ottenere il nome della pagina corrente, è possibile utilizzare il codice seguente nello script:

String pageName = currentPage.getName();

Con currentPage come oggetto della pagina corrente. Per ulteriori informazioni sulla manipolazione degli oggetti Page, consultare JavaScript.

Gestione pagine Il gestore pagine è un'interfaccia che fornisce metodi per le operazioni a livello di pagina.

Ad esempio, per ottenere la pagina contenitore di una risorsa, puoi utilizzare il seguente codice nello script:

Page myPage = pageManager.getContainingPage(myResource);

PageManager è l'oggetto di gestione pagina e myResource un oggetto risorsa. Per ulteriori informazioni sui metodi forniti dal gestore della pagina, consulta JavaScript.

Struttura all’interno del repository

L’elenco seguente offre una panoramica della struttura visualizzata all’interno dell’archivio.

• /apps

  Relativo all’applicazione; include definizioni di componenti specifiche del sito web. I componenti sviluppati possono essere basati sui componenti predefiniti disponibili all’indirizzo /libs/foundation/components.

• /content

  Contenuto creato per il sito web.

• /etc

• /home

  Informazioni su utenti e gruppi.

• /libs

  Librerie e definizioni che appartengono al nucleo dell'AEM. Le sottocartelle in /libs rappresenta le funzioni predefinite dell’AEM, ad esempio ricerca o replica. Il contenuto in /libs non deve essere modificato in quanto influisce sul modo in cui funziona l’AEM. Le funzioni specifiche del sito web devono essere sviluppate in /apps (vedere Personalizzazione di componenti e altri elementi).

• /tmp

  Area di lavoro temporanea.

• /var

  File che vengono modificati e aggiornati dal sistema, ad esempio registri di controllo, statistiche e gestione degli eventi.

Ambienti

Con l’AEM, un ambiente di produzione è spesso costituito da due diversi tipi di istanze: Creazione e pubblicazione di istanze.

Dispatcher

Dispatcher è uno strumento di Adobe per il caching e/o il bilanciamento del carico. Ulteriori informazioni sono disponibili nella sezione Dispatcher.

FileVault (sistema di revisione sorgente)

FileVault fornisce all’archivio JCR la mappatura del file system e il controllo della versione. Può essere utilizzato per gestire progetti di sviluppo AEM con supporto completo per l’archiviazione e il controllo delle versioni del codice del progetto, del contenuto, delle configurazioni e così via, nei sistemi di controllo delle versioni standard (ad esempio, Subversion).

Consulta la Strumento FileVault per informazioni dettagliate.

Flussi di lavoro

I contenuti sono spesso soggetti a processi organizzativi, tra cui passaggi quali l’approvazione e l’approvazione da parte di vari partecipanti. Questi processi possono essere rappresentati come flussi di lavoro, definito e sviluppato nell’ambito dell’AEM, quindi applicato al pagine di contenuto appropriate o risorse digitali secondo necessità.

Il motore dei flussi di lavoro consente di gestire l’implementazione dei flussi di lavoro e della successiva applicazione ai contenuti.

Gestione multisito

Multi Site Manager (MSM) consente di gestire facilmente più siti Web che condividono contenuti comuni. MSM consente di definire relazioni tra i siti in modo che le modifiche al contenuto in un sito vengano automaticamente replicate in altri siti.

Ad esempio, i siti web sono spesso disponibili in più lingue per il pubblico internazionale. Quando il numero di siti nella stessa lingua è basso (da tre a cinque), è possibile un processo manuale per la sincronizzazione dei contenuti tra siti diversi. Tuttavia, quando il numero di siti aumenta o sono coinvolte più lingue, diventa più efficiente automatizzare il processo.

• Gestire in modo efficiente le diverse versioni linguistiche di un sito Web.

• Aggiorna automaticamente uno o più siti in base a un sito di origine:

  • Applicazione di una struttura di base comune e utilizzo di contenuti comuni su più siti.
  • Ottimizzare l’utilizzo delle risorse disponibili.
  • Mantenere un aspetto comune.
  • Concentrare gli sforzi sulla gestione dei contenuti che differiscono tra i siti.

Per ulteriori informazioni, consulta Gestore multisito.

Risorse Business.Adobe.com

Auto Form Fill Targeted Content Document Generation Managed Cloud Dynamic Media Headless Cms