Bidrar till AEM

Utvecklingsmetod

AEM utvecklas enligt beprövade metoder som ofta används i stora öppen källkodsprojekt. Många centrala element AEM tekniklösningar underhålls i själva verket som aktiva öppen källkodsprojekt, som Sling och Jackrabbit, som har bidragit till Apache Software Foundation. En viktig aspekt av den här andan som finns i AEM är att du uppmuntras att använda de tillgängliga e-postlistorna och onlineforumen för direktinteraktion med utvecklingsteamet.

Om du bidrar till komponenter i AEM bör du bekanta dig med AEM på samma sätt som när du bidrar till ett öppen källkodsprojekt och kommunicera med det befintliga kärnteamet på samma sätt som när du skulle ha tänkt bidra till ett sådant projekt.

Nödvändig upplevelse

HTTP-protokollet (HyperText Transfer Protocol) är centralt för allt vi gör. Innan du bidrar till AEM bör du därför ha en djupgående förståelse för HTTP, helst i den utsträckning som du skulle kunna skriva en egen Java-implementering av en flertrådig HTTP-server med trådpooling. Du bör också ha en förståelse för HTTP/1.1 keep-alive-beteendet, och du bör ha djupgående kunskaper om interaktioner på server-/klientsidan med JavaScript, särskilt den asynkrona typ av interaktion som representeras av AJAX.

Eftersom siddynamik och interaktivt innehåll är avgörande för WM-upplevelsen är det viktigt att du har en tämligen djup förståelse för Document Object Model och dess potential för programmatisk manipulering som svar på händelser. Du bör känna till exempelvis DOM-manipulering i realtid och dra-och-släpp-beteenden över flera webbläsardokument (t.ex. användning av iframes).

På den högsta nivån bör du alltså ha en god förståelse för:

  • den HTTP/1.1-protokoll
  • HTML (helst HTML5)
  • Cascading Style Sheets
  • XML (Extensible Markup Language)
  • Asynkrona mönster för JavaScript- och XML-design (AJAX)
  • JavaScript-objektnotation (JSON)
  • Document Object Model
  • Tillståndskänslig eller tillståndslös interaktion
  • Identifierare för enhetliga resurser
  • Webbläsarcookies
  • och andra moderna webbutvecklingskoncept

Adobe Experience Manager teknikstack bygger på Apache Felix OSGI-behållare med Apache Sling webbaserat ramverk och bäddar in en Java-innehållsdatabas (JCR) baserat på Apache Jackrabbit. Du bör bekanta dig med dessa enskilda projekt, liksom med andra komponenter med öppen källkod (t.ex. Apache Lucene) som används i området där du tänker bidra.

Tribal Knowledge

Vissa koncept och vägledande principer är djupt inrotade i den tidigare dagskulturen. I det här avsnittet beskrivs några av de"djupt DNA-inbäddade" problemen som du bör känna till.

Allt är innehåll

Innehållet innehåller inte bara alla data som finns kvar i webbprogrammet. Programkoden, biblioteken, skripten, mallarna, HTML, CSS, bilder och artefakter av alla de slag, allt och allt finns kvar i Content Repository och importeras/exporteras i form av paket via Package Manager och Package Share.

David's Model

Det sätt på vilket innehåll ska modelleras i en Java Content Repository kräver ett helt annat sätt att tänka än vad som är vanligt inom programvarubranschen för datamodellering i relationsvärlden. Oumbärlig läsning för alla nykomlingar i content management är vägen för JCR David's Model: En guide för innehållsmodellering.

RESTfulness

REST-strategin är djupt inrotad i det vi gör. Detta innebär bland annat att man undviker tillståndskänsliga interaktioner och att man måste tänka på att URI:er är definitiva adresser för innehåll och tjänster.

REST (REpresentational State Transfer) avser den programarkitekturstil som World Wide Web bygger på. Den beskriver de viktigaste elementen som får webben att fungera och innehåller därför en uppsättning principer för hur webbaserade program ska utformas. När du utformar ett API som ska användas via webben är det därför klokt att följa dessa"bästa praxis".

Eftersom REST ger en vägledande filosofi bakom så mycket av det vi gör, bör ni se det som viktigt att bli väl insatt i de stora delarna av RESTful-design. Ett bra ställe att börja med är Roy Fielding's dissertation.

Sling Request Resolution

En viktig aspekt när det gäller AEM är hur inkommande begäranden relaterar till innehåll och programbeteende, hur innehåll struktureras i innehållsdatabasen och var AEM letar efter programlogiken som hanterar begäran. Läs mer om Apache Sling URL-disposition och hur den tillämpar REST-arkitekturen och dess tillståndslösa, cacheable- och lageruppbyggda systembegränsningar.

Viktiga aspekter att förstå om Apache Sling:s begäranupplösning är hur begäranden primärt mappas till en viss resurs i innehållsdatabasen, hur ytterligare egenskaper i begäran tillsammans med egenskaper för dessa innehållsobjekt avgör vilken programkod som ska anropas för att återge innehållet och hur kod i /apps åsidosätter kod i /libs.

Quickstart

Inget steg tre: Om du vill installera och köra programmet hämtar och dubbelklickar du på JAR-filen Quickstart. Det finns inget steg tre. Ytterligare valfria funktioner behöver bara installera rätt paket från paketresursen.

Liten snabbstartsstorlek: Behåll storleken på JAR-filen för QuickStart med ett minimum. Använd bibliotek på ett smart och optimerat sätt och flytta tillvalsfunktioner till paketdelning.

Snabbare starttid: När du gör en ändring som kan påverka starttiden måste du se till att den blir kortare, inte längre.

Medel

Vi föredrar kod och projekt som är lätta, små, snabba och eleganta. "Bra nog" är inte tillräckligt bra.

Återanvändning av kod: Vår OSGi-baserade produktarkitektur och"allt är innehåll"-filosofi innebär att vi har ovanligt goda möjligheter att återanvända kod och artefakter. Vi försöker dra nytta av detta när det är möjligt för att behålla funktioner som är både smala och tydliga.

Lös koppling: Vi föredrar löst kopplade interaktioner framför nära beroenden och"oönskad intimitet". Förlorad koppling möjliggör också mer återanvändning av kod.

Bryt inte demon

Bekanta dig med demoskript och produktfunktioner som oftast visas i demos. Förstå att i alla fall inget du gör någonsin bör bryta mot en"demomanusfunktion". Kärnprodukten bör alltid vara redo för demo, även under utvecklingen.

Design för tillförlitlighet

Vi strävar efter att designa och koda funktioner på ett icke-mjukt sätt så att (till exempel) ett problem med ett enskilt DOM-element inte gör att en hel sida inte återges. Med andra ord: Gör saker som borde vara dödliga. Gör allt annat överblivet. Gör produkten "förlåt".

Onormal är New Normal

Förlita dig inte på att du stänger av kopplingar. Se till att du rensar vid start. Onormal avslutning är normal avslutning.

shutdown == kill -9 == power outage

Var redo för elastisk klustring

Var alltid redo för elastisk klustring, anta alltid att det finns klustring. I allmänhet innebär en lösning med stöd för klustring att du följer allt som finns i innehållsdatabasen.

Design för bakåtkompatibilitet

Ingenting ni gör ska bryta mot en kunds gamla kod. Beakta endast /libs som innehåller produktkod som kan uppdateras under en uppgradering. The /apps -avsnittet i databasen är projektkod och /etc -avsnittet innehåller anpassade konfigurationer som måste bevaras. Skriv inte över något i /apps, /content och /home. Efter en uppgradering bör den gamla projektkoden, konfigurationerna och innehållet fortsätta att fungera som tidigare.

Att skapa bakåtkompatibelt material säkerställer också att uppgraderingsupplevelsen matchar enkelheten i den första installationen. Det räcker att bara stoppa AEM, ersätta JAR-filen för QuickStart och starta AEMagain. Med en snabbt växande installationsbas blir uppgraderingseffektiviteten en allt större fördel.

Befintliga API:er kan och bör markeras som inaktuella när de är nyare, men bättre funktioner ersätter dem, men alla API:er som publicerades i en tidigare version av 5.x måste fortsätta att fungera eftersom de kan användas i anpassad programkod. Inga sådana API:er ska tas bort.

Bakåtkompatibiliteten bör också beaktas när det gäller den allmänna konsekvensen i innehållsstrukturen och användarupplevelsen.

Viktiga begrepp

Författarinstans - Av säkerhetsskäl, styrningsskäl och andra skäl delas instanser av AEM in i författare- och publiceringsinstanser. Mer information om distributionsarkitekturen (inklusive författare/publiceringsinstanser) finns i dokumentationen om AEM instanser.

Cachelagring, fritering och bakning - Traditionellt sett är begreppen baking och kopiering en viktig skillnad mellan olika system för hantering av webbinnehåll. I CMS-jargon avser"baking" begreppet implementering av data i statiska filer vid publicering, medan"frying" avser begreppet att bearbeta data för slutlig presentation vid begäran (dvs. precis i tid).

Klustring och lastbalansering - För att öka tillgängligheten och förbättra prestandan i en produktionsmiljö är det vanligt att kombinera flera författare- och/eller publiceringsinstanser (i kluster), antingen genom att göra dem tillgängliga för olika användargrupper eller genom att lastbalansera dem bakom en Dispatcher-konfiguration.

Det går också att kombinera flera instanser av innehållsdatabasen för att skapa en hög tillgänglighet JCR-lösning som sedan kan integreras med AEM för att maximera skyddet mot maskinvaru- och programvarufel. Se Rekommenderade distributioner för ytterligare information.

Komponent - I AEM är en komponent en objekttyp, som i allmänhet kan skapas genom att du drar och släpper dem från t.ex. Sidsparken. De färdiga komponenterna som levereras med AEM innehåller komponenterna Text, Title, Tag Cloud, Carousel, Image och List, som alla finns tillgängliga från Sidespark vid körning.

Content Finder - I redigeringsläget är Innehållssökning en särskild panel (ram) till vänster på sidan som, beroende på vilken flik du väljer överst, visar listor med bilder, dokument, Flash-resurser, sidor, stycken eller databasresurser som du kan dra och släppa från Innehållssökning till den sida du arbetar med (till höger).

Digitala resurser - I AEM är digitala resurser (vanligtvis) bilder och multimediefiler. Mer information finns i Arbeta med digitala resurser i DAM.

Dispatcher - Dispatcher är både ett cache-lagrings- och lastbalanseringsverktyg och erbjuder vissa säkerhetsåtgärder.

ExtJS-widgetar - De flesta användargränssnittselement i AEM använder ExtJS, som är ett tredjepartswidgetbibliotek som skrivits i JavaScript. ExtJS har anpassningsbara gränssnittswidgetar med höga prestanda och en väldesignad och utbyggbar komponentmodell.

JCR, Java Content Repository - Java Content Repository-specifikationen (JSR-283) innehåller både en abstrakt datamodell och ett Application Programming Interface för att skapa en enormt skalbar NoSQL-datalager som kombinerar funktioner i ett filsystem och en objektdatabas. Även om ni inte behöver förstå JSR-283 i detalj, bör ni ta er tid att bekanta er med de grundläggande funktionerna i JCR och den underliggande datamodellen, eftersom JCR är det som gör det möjligt att använda AEM"allt är innehåll"-filosofi.

JCR är i själva verket ett system med noder och egenskaper, där noder kan ärva från andra noder och allt innehåll lagras som egenskap values. Observera, att JCR, förutom vanliga arv, även innehåller konceptet"mixin"-noder, som möjliggör modellering av flera arv.

JCR har ett antal fördefinierade nodtyper och egenskapstyper, men i allmänhet är typningssystemet relativt flexibelt och (faktiskt) en av styrkorna hos JCR är att det gör det möjligt att lagra och hantera både strukturerat och ostrukturerat innehåll lika enkelt. JCR kan alltså rymma mycket strukturerade data, men kan även rymma godtyckliga dynamiska datastrukturer utan schemabegränsningar.

JavaDoc för JCR:s Java API är här.

Innan du försöker läsa JavaDoc eller JCR-specifikationen i sig bör du kanske titta på den här förklaringen på hög nivå av JCR i enlighet med Adobe Experience Services.

Hanterare för flera platser (MSM) - MSM-funktionen i AEM hjälper kunderna att hantera flerspråkigt och internationellt innehåll, vilket gör det möjligt för dem att balansera centraliserad varumärkeshantering med lokaliserat innehåll.

OSGi - OSGi är den tjänstebaserade runtime-tekniken som utgör grunden för modulariserad Java-utveckling i AEM. Det är ett ramverk som inte bara erbjuder en mycket dynamisk (och säker) miljö för klassinläsning och körning av kodresurser (så kallade paket), utan också fullständig kontroll över synligheten och livscykeln för de olika tjänster som paketeras med. Ett tjänsteregister tillhandahåller en samarbetsmodell för paket som tar hänsyn till livscykeldynamik (och versionskrav). OSGi löser många av de problem som programservrar var tänkta att lösa, men gör det på ett lätt och mycket dynamiskt sätt, vilket till exempel gör det möjligt att använda tjänster under drift (så att den nya koden blir omedelbart tillgänglig utan att servern startas om).

Parsys, Paragraph System - Styckesystemet (parsys) är en sammansatt komponent som gör att författare kan lägga till komponenter av olika typer på en sida och som innehåller andra styckekomponenter. Varje stycketyp representeras som en komponent. Styckesystemet är också en komponent som innehåller de andra styckekomponenterna.

Microkernel - Alla arbetsytor i databasen kan konfigureras separat för att lagra data via en viss mikrokernel (en klass som hanterar läsning och skrivning av data). På samma sätt kan databasens hela versionsarkiv även konfigureras separat så att en viss mikrokärna används. Det finns ett antal olika mikrokärnor som kan lagra data i en mängd olika filformat eller relationsdatabaser. (Det finns till exempel beständiga hanterare för MongoDB, DB2 eller Oracle) Standardmikrokärnan för AEM är tarMK (se vidare nedan).

Publicera instans - Av säkerhetsskäl, av styrningsskäl och av andra skäl delas instanser av AEM vanligtvis upp i författare- och publiceringsinstanser. Mer information om distributionsarkitekturen (inklusive författare/publiceringsinstanser) finns i dokumentationen om AEM instanser.

Quickstart - Till skillnad från många andra program installerar du AEM genom att använda en och samma självextraherande JAR-fil. När du dubbelklickar på JAR-filen för första gången installeras allt du behöver automatiskt. Snabbstart-JAR innehåller alla filer som behövs för CRX-databasen (inklusive administrativa funktioner), virtuella databastjänster, index- och söktjänster, arbetsflödestjänster, säkerhet och en webbserver, plus CQ Servlet Engine (CQSE) och alla AEM. Det finns inga andra filer att installera: QuickStart är självständigt.

Första gången du startar Quickstart skapas en hel JCR-kompatibel databas i bakgrunden, vilket kan ta flera minuter. Efter den här initiala starten går det mycket snabbare att starta eftersom databasinfrastrukturen redan har fastställts.

Många startalternativ (t.ex. det aktiva portnumret och om den aktuella AEM ska vara en Publish-instans eller en Author-instans). och mycket mer) kan du styra genom att byta namn på QuickStart-filen. Om du vill se en lista med alternativ i det här avseendet kör du JAR med "-help" på kommandoraden:

java -jar <quickstartfilename>.jar -help

Replikeringsagenter - Replikeringsagenter är centrala för AEM eftersom de används för att publicera (aktivera) innehåll från en författare till en publiceringsmiljö. tömma innehåll från Dispatcher-cachen, returnerar användargenererat innehåll (till exempel formulärindata) från publiceringsmiljön till författarmiljön.

Ställning - Med hjälp av ställningar kan du skapa ett formulär (en struktur) med fält som motsvarar den struktur du vill ha för sidorna och sedan använda det här formuläret för att enkelt skapa sidor som baseras på den strukturen.

Segmentering - Besökare har olika intressen och mål när de besöker en webbplats. Att förstå besökarnas mål och uppfylla deras förväntningar är en viktig förutsättning för onlinemarknadsföring. Segmentering hjälper till att uppnå detta genom att analysera och karakterisera en besökares detaljer.

Sidekick - Sidsparken är ett palettliknande flytande fönster som visas på den redigerbara sidan, där nya komponenter kan dras och åtgärder som gäller för sidan kan utföras.

Site Catalyst - SiteCatalyst förser marknadsförarna med ett och samma ställe för att mäta, analysera och optimera integrerade data från alla onlineinitiativ över flera marknadsföringskanaler. Du kan använda Adobe SiteCatalyst för att analysera data från AEM webbplatser.

Tjärlagring (tarMK) - tarMK är standardbeständighetssystemet i AEM. Även om AEM kan konfigureras att använda ett annat beständigt system (till exempel MongoDB) har TarmMK vissa fördelar eftersom det är prestandaoptimerat för vanliga JCR-fall (vilket är mycket snabbt), använder ett standarddataformat och kan snabbt och enkelt säkerhetskopieras.

Mall - I AEM anger en mall en viss typ av sida. Den definierar strukturen för en sida (och anger vanligtvis en miniatyrbild och olika egenskaper). Du kan till exempel ha separata mallar för produktsidor, platskartor och kontaktinformation.

Arbetsflöde - Med AEM Workflow System kan man skapa automatiserade processer som innefattar sidor eller resurser.

På denna sida