AEM Concetti di base aem-core-concepts

Prerequisiti per lo sviluppo su AEM prerequisites-for-developing-on-aem

Avrai bisogno delle seguenti competenze per sviluppare su AEM:

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

Archivio dei contenuti Java java-content-repository

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

Il piombo specifico è detenuto da Adobe Research (Svizzera) AG.

La API JCR 2.0 pacchetto, javax.jcr.* viene utilizzato per l’accesso diretto e la manipolazione del contenuto dell’archivio.

Experience Server (CRX) e Jackrabbit experience-server-crx-and-jackrabbit

Experience Server fornisce i servizi Experience AEM basati su e che possono essere utilizzati per creare applicazioni personalizzate e incorpora l’archivio dei contenuti basato su Jackrabbit.

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

Elaborazione delle richieste Sling sling-request-processing

Introduzione a Sling introduction-to-sling

AEM viene generato utilizzando Sling, un framework di applicazione web basato su principi REST che fornisce un facile sviluppo di applicazioni orientate ai contenuti. Sling utilizza un archivio JCR, come Apache Jackrabbit, o nel caso di AEM, il CRX Content Repository, come archivio dati. Sling è stato contribuito a Apache Software Foundation - ulteriori informazioni sono disponibili su Apache.

Utilizzando Sling, il tipo di contenuto di cui eseguire il rendering non è il primo aspetto di elaborazione. La considerazione principale è se l’URL viene risolto in un oggetto di contenuto per il quale è quindi possibile trovare uno script per eseguire il rendering. Questo offre 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 una vasta gamma di elementi di contenuto diversi, o quando è necessario personalizzare pagine facilmente. In particolare, quando si implementa un sistema di gestione dei contenuti web come WCM nella soluzione AEM.

Vedi Scopri Sling in 15 minuti per i primi passi per lo sviluppo con Sling.

Il diagramma seguente spiega la risoluzione dello script Sling: mostra come passare dalla richiesta HTTP al nodo del contenuto, dal nodo del contenuto al tipo di risorsa, dal tipo di risorsa allo script e quali variabili di script sono disponibili.

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

Sling è incentrato sul contenuto sling-is-content-centric

Sling è incentrato sul contenuto. Ciò significa che l’elaborazione è incentrata sul contenuto, in quanto ogni richiesta (HTTP) viene mappata sul contenuto sotto forma di una risorsa JCR (un nodo di archivio):

Sling RESTful restful-sling

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

Decomposizione URL url-decomposition

In Sling, l'elaborazione è guidata dall'URL della richiesta dell'utente. Definisce il contenuto da visualizzare dagli 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 del contenuto Percorso che specifica il contenuto di cui eseguire il rendering. è utilizzato in combinazione con l'estensione; in questo esempio si traducono in tools/spy.html.

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

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

suffisso Può essere utilizzato per specificare informazioni aggiuntive.

param(i) Eventuali parametri richiesti per il contenuto dinamico.

Da URL a contenuto e script from-url-to-content-and-scripts

Seguendo questi principi:

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

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

Mappatura delle richieste alle risorse mapping-requests-to-resources

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

Sling consente anche di usare risorse diverse dai nodi JCR, ma questa è una funzione avanzata.

Individuazione dello script locating-the-script

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

Il percorso specificato dal sling:resourceType può essere:

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

Alcuni altri punti da sottolineare sono:

L'elenco dei motori di script supportati dalla data istanza di AEM è 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 fornisce un modo per integrare nuovi motori di script.

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

Se per una determinata richiesta sono validi più script, viene selezionato lo script con la migliore corrispondenza. Più una partita è specifica, meglio è. in altre parole, più il selettore corrisponde meglio, indipendentemente da eventuali estensioni di richiesta o dalla corrispondenza del nome del metodo.

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

Presupponendo che il seguente elenco di script sia nella posizione corretta:

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

Oltre ai tipi di risorse (definiti principalmente da sling:resourceType (proprietà) esiste anche il super tipo di risorsa. Questo è generalmente indicato dal sling:resourceSuperType proprietà. Questi super tipi vengono considerati anche quando si cerca di trovare uno script. I super tipi di risorse consentono di creare 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 può essere definito in due modi:

Ad esempio:

La gerarchia dei tipi di:

Questo perché /y ha sling:resourceSuperType proprietà considerando /x non e quindi il relativo supertipo viene prelevato dal relativo tipo di risorsa.

Gli script Sling non possono essere chiamati direttamente sling-scripts-cannot-be-called-directly

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

Se chiami direttamente la rappresentazione (lo script), nascondi la risorsa all’interno dello script, in modo che il framework (Sling) non ne sia più a conoscenza. Così si perdono alcune caratteristiche:

API Sling sling-api

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

Riferimento a elementi esistenti utilizzando sling:include referencing-existing-elements-using-sling-include

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

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

A questo scopo puoi usare sling:include("/<path>/<resource>"). Questo 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

OSGi definisce un’architettura per lo sviluppo e la distribuzione di applicazioni e librerie modulari (noto anche come Sistema di moduli dinamici per Java). I contenitori OSGi ti consentono di suddividere l’applicazione in singoli moduli (sono file jar con metadati aggiuntivi e chiamati bundle nella terminologia OSGi) e di gestire le dipendenze trasversali tra di loro con:

Questi servizi e contratti offrono un'architettura che consente ai singoli elementi di scoprirsi l'un l'altro in modo dinamico per la collaborazione.

Un framework OSGi ti offre quindi il caricamento/scaricamento dinamico, la configurazione e il controllo di questi bundle, senza dover riavviare.

Questa architettura consente di estendere Sling con moduli specifici per le applicazioni. Sling, e quindi CQ5, utilizza il Apache Felix implementazione di OSGI (Open Services Gateway Initiative) basata sulle specifiche della versione 4.2 di OSGi Service Platform. Sono entrambe raccolte di bundle OSGi in esecuzione all'interno di un framework OSGi.

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

Vedi Console web, Configurazione OSGI e Impostazioni di configurazione OSGi per ulteriori informazioni.

Oggetti di sviluppo nell'ambiente AEM development-objects-in-the-aem-environment

Sono di interesse per lo sviluppo:

Elemento Un elemento è un nodo o una proprietà.

Per informazioni dettagliate sulla manipolazione degli oggetti Articolo, fare riferimento alla sezione Javadocs 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 loro proprietà memorizzano il contenuto e i metadati effettivi.

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

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

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

PropertyIterator properties = currentNode.getProperties();

Con currentNode come oggetto nodo corrente.

Per ulteriori informazioni sulla manipolazione degli oggetti Node, consulta Javadocs.

Widget In AEM tutti gli input dell’utente vengono gestiti tramite widget. Spesso sono utilizzati per controllare la modifica di un contenuto.

Le finestre di dialogo sono create combinando i Widget.

AEM è stato sviluppato utilizzando la libreria ExtJS di widget.

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

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

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

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 di AEM un componente viene spesso utilizzato per eseguire il rendering del contenuto di una risorsa. Quando la risorsa è una pagina, il rendering del componente è denominato Componente di primo livello o Componente di pagina. Tuttavia, un componente non deve eseguire il rendering del contenuto, né deve essere collegato a una risorsa specifica; ad esempio, un componente di navigazione visualizza informazioni su più risorse.

La definizione di un componente include:,

Modello Un modello è la base per un tipo specifico di pagina. Quando crei 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 del contenuto predefinito (contenuto principale primario). Il contenuto definisce il rendering come AEM è incentrato sul contenuto.

Componente pagina (componente di livello principale) Il componente da utilizzare per il rendering della pagina.

Pagina Una pagina è un'istanza di un modello.

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

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

String pageName = currentPage.getName();

Con currentPage come oggetto pagina corrente. Per ulteriori informazioni sulla manipolazione degli oggetti pagina, consulta Javadocs.

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

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

Page myPage = pageManager.getContainPage(myResource);

Con pageManager come oggetto page manager e myResource come oggetto risorsa. Per ulteriori informazioni sui metodi forniti dal gestore di pagine, consulta Javadocs.

Struttura all’interno dell’archivio structure-within-the-repository

L’elenco seguente fornisce una panoramica della struttura che verrà visualizzata all’interno dell’archivio.

Ambienti environments

Con AEM un ambiente di produzione spesso è costituito da due diversi tipi di istanze: un Creare e pubblicare istanze.

Dispatcher the-dispatcher

Dispatcher è lo strumento di Adobe per la memorizzazione in cache e/o il bilanciamento del carico. Ulteriori informazioni sono disponibili in Dispatcher.

FileVault (sistema di revisione sorgente) filevault-source-revision-system

FileVault fornisce al tuo 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 di progetto, del contenuto, delle configurazioni e così via, nei sistemi di controllo delle versioni standard (ad esempio, Subversion).

Consulta la sezione Strumento FileVault documentazione per informazioni dettagliate.

Flussi di lavoro workflows

Il contenuto è spesso soggetto a processi organizzativi, compresi passaggi quali l’approvazione e l’approvazione da parte di vari partecipanti. Tali processi possono essere rappresentati come flussi di lavoro, definiti e sviluppati in AEM, quindi applicato al pagine di contenuto appropriate o risorse digitali se necessario.

Il motore di flusso di lavoro viene utilizzato per gestire l’implementazione dei flussi di lavoro e la loro successiva applicazione ai contenuti.

Gestione multisito multi-site-management

Multi Site Manager (MSM) consente di gestire facilmente più siti web che condividono contenuti comuni. MSM consente di definire le relazioni tra i siti in modo che le modifiche di contenuto in un sito vengano replicate automaticamente 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 eseguire un processo manuale per la sincronizzazione dei contenuti tra siti diversi. Tuttavia, non appena il numero di siti cresce o quando sono coinvolte più lingue, diventa più efficiente automatizzare il processo.

Per ulteriori informazioni, consulta Multi Site Manager.