Show Menu
ARGOMENTI×

Contributo ad AEM

Metodologia di sviluppo

AEM è sviluppato seguendo metodologie collaudate comunemente utilizzate nei grandi progetti open source. Molti elementi fondamentali nello stack tecnologico di AEM vengono infatti mantenuti come progetti open source attivi, come Sling e Jackrabbit, che sono stati forniti alla Apache Software Foundation. Uno degli aspetti principali di questo spirito, presente in AEM, è che si consiglia di utilizzare le mailing list e i forum online disponibili per interazioni dirette con il team di sviluppo.
Se contribuisci ai componenti di AEM, devi avere familiarità con AEM come faresti per un progetto open source e comunicare con il team di base esistente come faresti se volessi contribuire a tale progetto.

Esperienza richiesta

Il protocollo HyperText Transfer Protocol (HTTP) è fondamentale per tutte le operazioni. Pertanto, prima di contribuire ad AEM, è necessario avere una conoscenza approfondita di HTTP, idealmente nella misura in cui si è in grado di scrivere la propria implementazione Java di un server HTTP multithread con thread-pooling. È inoltre necessario avere una conoscenza approfondita del comportamento di conservazione HTTP/1.1 e delle interazioni server/client con JavaScript, in particolare dello stile asincrono di interazione rappresentato da AJAX.
Poiché il dinamismo della pagina e il contenuto interattivo sono fondamentali per l'esperienza WM, è essenziale avere una conoscenza abbastanza approfondita del modello di oggetto documento e del suo potenziale di manipolazione programmatica in risposta agli eventi. Dovreste avere alcune conoscenze, ad esempio, della modifica DOM in tempo reale e del comportamento di trascinamento della selezione su più documenti del browser (ad esempio, utilizzando iframe).
Al livello più alto, quindi, dovreste avere una solida comprensione di:
  • il protocollo HTTP/1.1
  • HTML (preferibilmente HTML5 )
  • Cascading Style Sheets
  • Extensible Markup Language (XML)
  • Pattern di progettazione AJAX e JavaScript asincrono
  • JavaScript Object Notation (JSON)
  • il modello di oggetto documento
  • Interazioni statiche e senza stato
  • Cookie browser
  • e altri moderni concetti di sviluppo web
Lo stack tecnologico di Adobe Experience Manager si basa sul contenitore Apache Felix OSGI con il framework Web Apache Sling e incorpora un archivio di contenuti Java ( JCR ) basato su Apache Jackrabbit . È necessario acquisire familiarità con questi singoli progetti, nonché con qualsiasi altro componente open source (ad esempio, Apache Lucene) utilizzato nell'area in cui si intende contribuire.

Conoscenza tribale

Alcuni concetti e principi guida sono profondamente radicati nella cultura della prima giornata. Questa sezione elenca alcuni dei problemi "profondamente DNA-incorporati" di cui dovreste essere a conoscenza.

Tutto è contenuto

Il contenuto include non solo tutti i dati che l'applicazione Web persiste. Il codice del programma, le librerie, gli script, i modelli, HTML, CSS, le immagini e gli artefatti di tutti i tipi, qualsiasi cosa e qualsiasi cosa, vengono memorizzati nell'archivio dei contenuti e importati/esportati sotto forma di pacchetti tramite Gestione pacchetti e Condivisione pacchetti.

Il modello di David

Il modo in cui il contenuto deve essere modellato in un archivio di contenuti Java richiede un modo di pensare completamente diverso da quello che è prassi comune nel settore del software per la modellazione dei dati nel mondo relazionale. La lettura essenziale per qualsiasi nuovo arrivato alla gestione dei contenuti, il modello JCR è il modello di David: Guida alla modellazione dei contenuti.

RESTfulness

L'approccio REST è profondamente radicato in ciò che facciamo. Ciò significa, tra l'altro, evitare interazioni statiche e tenere presente che gli URI sono indirizzi definitivi per i contenuti e i servizi.
REST (REpresentational State Transfer) si riferisce allo stile architettonico del software su cui si basa il World Wide Web. Descrive gli elementi chiave che fanno funzionare il Web, e quindi fornisce un insieme di principi per come dovrebbe essere progettato il software basato su Web. Quando si progetta un'API da utilizzare sul Web, ha pertanto senso aderire a queste "best practice".
Poiché il REST fornisce la filosofia guida dietro a così tanto di ciò che facciamo, dovreste considerare essenziale diventare esperti nei principi del design RESTful. Un buon punto di partenza è con la tesi di Roy Fielding .

Risoluzione richiesta Sling

Un aspetto chiave da comprendere su AEM è il modo in cui le richieste in arrivo si relazionano al contenuto e al comportamento delle applicazioni, la struttura del contenuto nell’archivio dei contenuti e la ricerca della logica dell’applicazione da parte di AEM per gestire la richiesta. Scopri la decomposizione dell’URL Apache Sling e il modo in cui applica lo stile architettonico REST e i suoi vincoli di sistema stateless, cacheable e a più livelli.
Gli aspetti chiave per comprendere la risoluzione delle richieste di Apache Sling sono il modo in cui le richieste vengono associate principalmente a una risorsa specifica nell'archivio dei contenuti, il modo in cui le proprietà aggiuntive della richiesta, insieme alle proprietà di questi oggetti contenuto, determinano quale codice dell'applicazione verrà richiamato per eseguire il rendering del contenuto e come il codice in /apps sostituisce il codice in /libs.

Quickstart

No step tre: Per installare ed eseguire, è sufficiente scaricare e fare doppio clic sul file JAR di Quickstart. Non c'è un terzo passo. Qualsiasi funzionalità opzionale aggiuntiva non deve richiedere altro che l'installazione del pacchetto appropriato da Package Share.
Piccola dimensione di Avvio rapido: Mantenete al minimo le dimensioni del file JAR Quickstart. Utilizzo intelligente e ottimizzato delle librerie, spostamento delle funzionalità facoltative per la condivisione del pacchetto.
Tempo di avvio più rapido: Quando apportate una modifica che potrebbe influire sul tempo di avvio, accertatevi che sia più breve, non più lungo.

Lineare e Media

Favoriamo codici e progetti leggeri, piccoli, veloci ed eleganti. "Abbastanza buono" non è abbastanza buono.
Riuso del codice: La nostra architettura di prodotto basata su OSGi e la filosofia "tutto è contenuto" significa che abbiamo insolitamente buone opportunità per riutilizzare codice e artefatti. Cerchiamo di approfittare di questo fatto quando possibile per mantenere le caratteristiche magre e medie.
Attacco in sospensione: Favoriamo interazioni a stretto contatto con le persone a dipendenze strette e "indesiderata intimità". Il raccordo a scomparsa permette inoltre un maggiore riutilizzo del codice.

Non interrompere la demo

Acquisisci familiarità con gli script dimostrativi e le funzionalità dei prodotti che vengono visualizzate più spesso nelle demo. Comprendere che, almeno, nulla di ciò che si fa dovrebbe mai interrompere una funzione "demo script". Il prodotto di base deve essere sempre demo-ready, anche durante lo sviluppo.

Progettazione per affidabilità

Ci sforziamo di progettare e codificare le funzionalità in modo semplice, in modo che (ad esempio) un problema con un singolo elemento DOM non impedisca il rendering di un'intera pagina. In altre parole: Fare cose che dovrebbero essere fatali, fatali. Rendi tutto il resto sopravvissuto. Fare il prodotto "perdonare".

L'anomalo è il nuovo normale

Non dipendere dai ganci di arresto, assicurati che l'avvio sia pulito. Terminazione anomala è una normale terminazione.
shutdown == kill -9 == power outage

Preparati per il clustering elastico

Sempre pronto per il clustering elastico, sempre supporre che ci sia il clustering. Come regola generale, il rispetto di tutto ciò che si trova nell'archivio dei contenuti comporta il supporto del clustering integrato.

Progettazione per compatibilità con versioni precedenti

Niente di quello che fai dovrebbe interrompere il vecchio codice di un cliente. Considerare solo /libs il codice prodotto che può essere aggiornato durante un aggiornamento. La /apps sezione dell'archivio è il codice del progetto e la /etc sezione contiene configurazioni personalizzate che devono essere mantenute. In genere, non sovrascrivere nulla in /apps , /content e /home . Dopo un aggiornamento, il codice, le configurazioni e il contenuto del progetto precedente devono continuare a funzionare come prima dell'aggiornamento.
La progettazione della compatibilità con le versioni precedenti garantisce inoltre che l'esperienza di aggiornamento corrisponda alla semplicità dell'installazione iniziale. È sufficiente arrestare AEM, sostituire il file JAR di Avvio rapido e riavviare AEM. Con una base di installazione in rapida crescita, l'efficienza dell'aggiornamento sarà un vantaggio sempre più importante.
Anche se le API esistenti possono e devono essere contrassegnate come obsolete quando sono più recenti, una funzionalità migliore le sostituisce, tutte le API rese pubbliche in una versione precedente della versione 5.x devono rimanere funzionanti, poiché potrebbero essere utilizzate nel codice dell'applicazione personalizzato. Tali API non devono essere rimosse.
La compatibilità con le versioni precedenti dovrebbe essere tenuta presente anche per quanto riguarda la coerenza generale della struttura dei contenuti e l'esperienza dell'utente.

Concetti di base

Istanza di authoring - In genere, per motivi di sicurezza, governance e per altri motivi, un sito di produzione suddividerà le istanze di AEM in istanze Author e Publish. Per ulteriori informazioni sull'architettura di distribuzione (comprese le istanze Author/Publish), consultate la documentazione sulle istanze AEM.
Memorizzazione nella cache, frittura e cottura - Tradizionalmente, i concetti di cottura e frittura sono una distinzione importante tra i diversi sistemi di gestione dei contenuti Web. In linguaggio CMS, per "cottura" si intende il concetto di invio di dati a file statici in fase di pubblicazione, mentre per "frittura" si intende il concetto di elaborazione di dati per la presentazione finale in fase di richiesta (cioè, solo in tempo).
Clustering e bilanciamento del carico: per aumentare la disponibilità e migliorare le prestazioni di un ambiente di produzione, è comune combinare più istanze Author e/o Publish (in cluster), rendendole disponibili a diversi gruppi di utenti o bilanciandole in base al carico all'interno di una configurazione Dispatcher.
È inoltre possibile combinare più istanze del repository dei contenuti per creare una soluzione JCR ad alta disponibilità , che può essere poi integrata con la soluzione AEM per massimizzare la protezione contro i guasti hardware e software. Per ulteriori informazioni, consultate Implementazioni consigliate.
Componente - In AEM, un componente è un tipo di oggetto, le cui istanze possono in genere essere create trascinandole dalla barra laterale, ad esempio. Ad esempio, i componenti forniti con AEM includono i componenti Testo, Titolo, Tag Cloud, Carosello, Immagine ed Elenco, tutti disponibili dalla barra laterale in fase di esecuzione.
Content Finder - In modalità di authoring, Content Finder è un pannello speciale (fotogramma) a sinistra della pagina che, a seconda della scheda selezionata in alto, visualizza gli elenchi di immagini, documenti, risorse Flash, pagine, paragrafi o risorse del repository che è possibile trascinare da Content Finder alla pagina su cui si sta lavorando (a destra).
Risorse digitali - In AEM, le risorse digitali sono (solitamente) immagini e file multimediali avanzati. Per ulteriori informazioni, consulta Utilizzo delle risorse digitali in DAM.
Dispatcher - Il Dispatcher è sia uno strumento di caching che di bilanciamento del carico, oltre a fornire determinate garanzie di sicurezza.
widget ExtJS - La maggior parte degli elementi dell’interfaccia utente in AEM utilizza ExtJS, una libreria di widget di terze parti creata in JavaScript. ExtJS offre widget dell’interfaccia utente personalizzabili e prestazioni elevate e un modello di componenti estensibile.
JCR, Java Content Repository - La specifica Java Content Repository (JSR-283) fornisce sia un modello dati astratto che un'interfaccia di programmazione applicazioni per realizzare un archivio dati NoSQL scalabile che combina le funzionalità di un file system e di un database oggetti. Sebbene non sia necessario comprendere il JSR-283 in modo dettagliato, è necessario prendere tempo per acquisire familiarità con le funzionalità di base del JCR e con il modello dati sottostante, perché JCR è ciò che rende possibile la filosofia "Tutto è contenuto" di AEM.
In sostanza, JCR è un sistema di nodi e proprietà, in cui i nodi possono ereditare da altri nodi e tutto il contenuto viene memorizzato come valori di proprietà. Si noti che, oltre all'ereditarietà ordinaria, JCR consente un concetto di nodi "mixin", che consente la modellazione di più ereditarietà.
JCR ha una serie di tipi di nodi e di proprietà predefiniti, ma in generale il sistema di digitazione è abbastanza flessibile, e (in effetti) uno dei punti di forza di JCR è che consente di memorizzare e gestire con la stessa facilità contenuti strutturati e non strutturati. In altre parole, JCR può contenere dati altamente strutturati, ma può anche contenere strutture di dati dinamici arbitrarie senza vincoli di schema.
JavaDoc for JCR's Java API è qui .
Prima di provare a leggere la specifica JavaDoc o JCR stessa, potresti voler vedere questa spiegazione di alto livello di JCR implementata da Adobe Experience Services.
Multi-Site Manager (MSM) - La funzione MSM di AEM consente ai clienti di gestire contenuti multilingue e multinazionali, consentendo loro di bilanciare il branding centralizzato con contenuti localizzati.
OSGi - OSGi è la tecnologia runtime basata sui servizi che fornisce la base per lo sviluppo Java modularizzato in AEM. Si tratta di un framework che fornisce non solo un ambiente di caricamento ed esecuzione altamente dinamico (e sicuro) per le risorse di codice (note come pacchetti), ma anche il pieno controllo sulla visibilità e sul ciclo di vita dei vari servizi esposti dai bundle. Un registro dei servizi fornisce un modello di cooperazione per i bundle che tiene conto delle dinamiche del ciclo di vita (e dei requisiti di versione). OSGi risolve molti dei problemi che i server applicativi intendevano risolvere, ma lo fa in modo leggero e altamente dinamico, rendendo possibile, ad esempio, la distribuzione a caldo dei servizi (rendendo il nuovo codice immediatamente disponibile senza riavviare il server).
Parsys, Sistema paragrafi - Il sistema paragrafo (parsys) è un componente composto che consente agli autori di aggiungere a una pagina componenti di tipi diversi e contiene altri componenti paragrafo. Ciascun tipo di paragrafo è rappresentato da un componente. Anche il sistema paragrafo stesso è un componente, che contiene gli altri componenti paragrafo.
Microkernel - Ogni area di lavoro del repository può essere configurata separatamente per memorizzare i dati attraverso un microkernel specifico (una classe che gestisce la lettura e la scrittura dei dati). Analogamente, l'archivio delle versioni dell'archivio può essere configurato in modo indipendente per l'utilizzo di un particolare microkernel. Sono disponibili diversi microkernel, in grado di memorizzare i dati in diversi formati di file o database relazionali. (Ad esempio, esistono persistence manager per MongoDB, DB2 o Oracle) Il microkernel predefinito per AEM è TarMK (vedere di seguito).
Istanza di pubblicazione - Per motivi di sicurezza, governance e per altri motivi, un sito di produzione dividerà in genere le istanze di AEM in istanze Author e Publish. Per ulteriori informazioni sull'architettura di distribuzione (comprese le istanze Author/Publish), consultate la documentazione sulle istanze AEM.
Quickstart - A differenza di molti altri programmi, si installa AEM utilizzando un singolo file JAR autoestraente "Quickstart". Quando si fa doppio clic sul file JAR per la prima volta, tutto ciò che serve viene installato automaticamente. Il JAR di avvio rapido include tutti i file richiesti per l'archivio CRX (comprese le strutture amministrative), i servizi dell'archivio virtuale, i servizi di indice e di ricerca, i servizi del flusso di lavoro, la protezione e un server Web, oltre al CQ Servlet Engine (CQSE) e a tutti i servizi AEM. Nessun altro file da installare: il Quickstart è autonomo.
La prima volta che si avvia Quickstart, viene creato in background un intero repository compatibile con JCR, che può richiedere alcuni minuti. Dopo l'avvio iniziale, le avvii successivi sono molto più veloci in quanto l'infrastruttura del repository è già stata impostata.
Molte opzioni di avvio (ad esempio, il numero della porta attiva e se l’istanza di AEM in questione deve essere un’istanza Pubblica rispetto a un’istanza Author); e molto altro) può essere controllato rinominando in modo appropriato il file Quickstart. Per visualizzare un elenco delle opzioni, eseguire la JAR con "-help" sulla riga di comando:
java -jar <quickstartfilename>.jar -help

agenti di replica: gli agenti di replica sono fondamentali in AEM come meccanismo utilizzato per pubblicare (attivare) il contenuto da un autore a un ambiente di pubblicazione; cancellare il contenuto dalla cache del dispatcher; restituite all’ambiente Authoring il contenuto generato dall’utente (ad esempio, l’input del modulo) dall’ambiente di pubblicazione.
Scaffolding - Con la pagina di scaffolding è possibile creare un modulo (una pagina di scaffolding) con campi che riflettono la struttura desiderata per le pagine e quindi utilizzare questo modulo per creare facilmente pagine basate su questa struttura.
Segmentazione : i visitatori del sito hanno interessi e obiettivi diversi quando arrivano a un sito. Comprendere gli obiettivi dei visitatori e soddisfare le loro aspettative è un importante prerequisito per il successo del marketing online. La segmentazione consente di ottenere questo risultato analizzando e caratterizzando i dettagli di un visitatore.
Barra laterale - La barra laterale è una finestra mobile simile a una palette visualizzata sulla pagina modificabile, dalla quale è possibile trascinare nuovi componenti ed eseguire le azioni applicabili alla pagina.
SiteCatalyst - SiteCatalyst offre agli esperti di marketing un'unica soluzione per misurare, analizzare e ottimizzare i dati integrati da tutte le iniziative online attraverso più canali di marketing. Potete utilizzare Adobe SiteCatalyst per analizzare i dati dai siti Web AEM.
TarMK (TarMK) - TarMK è il sistema di persistenza predefinito in AEM. Anche se AEM può essere configurato per l’utilizzo di un sistema di persistenza diverso (come MongoDB), TarMK presenta alcuni vantaggi in quanto ottimizza le prestazioni per i casi di utilizzo JCR tipici (e quindi molto veloce), utilizza un formato dati standard di settore e può essere eseguito rapidamente e facilmente il backup.
Modello - In AEM, un modello specifica un particolare tipo di pagina. Definisce la struttura di una pagina (in genere specifica una miniatura e varie proprietà). Ad esempio, potete utilizzare modelli distinti per le pagine di prodotti, le mappe dei siti e le informazioni di contatto.
Flusso di lavoro - Il sistema AEM Workflow consente di creare processi automatizzati che coinvolgono pagine o risorse.