AEM Core Concepts aem-core-concepts

Krav för utveckling av AEM prerequisites-for-developing-on-aem

Du behöver följande kunskaper för att kunna utveckla AEM:

Vi rekommenderar att du läser och följer Riktlinjer och bästa praxis.

Java™ Content Repository java-content-repository

Java™ Content Repository (JCR), JSR 283, anger ett leverantörsoberoende och implementeringsoberoende sätt att få åtkomst till innehåll dubbelriktat på en detaljnivå i en innehållsdatabas.

Adobe Research (Schweiz) AG har en ledande specialiseringsbefattning.

The JCR API 2.0 package, javax.jcr.* används för direkt åtkomst och redigering av databasinnehåll.

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

Experience Server innehåller de Experience Services som AEM bygger på och som kan användas för att skapa anpassade program, och den bäddar in innehållsdatabasen baserat på Jackrabbit.

Apache Jackrabbit är en fullt kompatibel implementering av JCR API 2.0 med öppen källkod.

Bearbetning av försäljningsbegäran sling-request-processing

Introduktion till Sling introduction-to-sling

AEM byggs med Sling, ett ramverk för webbapplikationer som bygger på REST-principer och som enkelt utvecklar innehållsorienterade applikationer. Sling använder en JCR-databas, t.ex. Apache Jackrabbit eller, om det finns AEM, CRX Content Repository som datalager. Sling har bidragit till Apache Software Foundation - mer information finns på Apache.

Med Sling är den typ av innehåll som ska återges inte den första bearbetningen. Det viktigaste är i stället om URL:en tolkas till ett innehållsobjekt för vilket ett skript sedan kan användas för återgivningen. Detta ger ett utmärkt stöd för dem som skapar webbmaterial att bygga sidor som enkelt kan anpassas efter deras behov.

Fördelarna med den här flexibiliteten är uppenbara i program med många olika innehållselement eller när du behöver sidor som enkelt kan anpassas. Detta gäller särskilt när man implementerar ett webbinnehållshanteringssystem som WCM i AEM.

Se Sling på 15 minuter för de första stegen för att utveckla med Sling.

I följande diagram förklaras Sling-skriptupplösningen. Den visar hur du hämtar från HTTP-begäran till innehållsnoden, från innehållsnod till resurstyp, från resurstyp till skript och vilka skriptvariabler som är tillgängliga.

I följande diagram förklaras alla dolda, men kraftfulla, frågeparametrar som du kan använda när du arbetar med SlingPostServlet. Den innehåller standardhanteraren för alla begäranden om POST som ger dig oändliga alternativ för att skapa, ändra, ta bort, kopiera och flytta noder i databasen.

Sling är innehållscentrerat sling-is-content-centric

Sling är innehållscentrerad. Detta innebär att bearbetningen är inriktad på innehållet eftersom varje HTTP-begäran mappas till innehåll i form av en JCR-resurs (en databasnod):

RESTful Sling restful-sling

På grund av den innehållsorienterade filosofin implementerar Sling en REST-orienterad server och har därför ett nytt koncept i ramverk för webbapplikationer. Fördelarna är:

URL-disposition url-decomposition

Vid Sling styrs bearbetningen av URL:en för användarförfrågningen. Här definieras vilket innehåll som ska visas av rätt skript. Det gör du genom att extrahera information från webbadressen.

Om du analyserar följande URL:

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

Du kan dela upp den i dess sammansatta delar:

protocol HTTP

värd Webbplatsens namn.

innehållsbana Sökväg som anger det innehåll som ska återges. Används tillsammans med tillägget. I det här exemplet översätts de till tools/spy.html.

väljare Används för alternativa metoder för återgivning av innehållet. I det här exemplet används en utskriftsvänlig version i A4-format.

extension Innehållsformat; anger också det skript som ska användas för återgivning.

suffix Kan användas för att ange ytterligare information.

parametrar Alla parametrar som krävs för dynamiskt innehåll.

Från URL till innehåll och skript from-url-to-content-and-scripts

Använd dessa principer:

Bilden nedan visar vilken mekanism som används, vilket beskrivs mer ingående i följande avsnitt.

Med Sling anger du vilket skript som ska återge en viss enhet (genom att ange sling:resourceType i JCR-noden). Den här mekanismen ger mer frihet än en där skriptet får åtkomst till datatabellerna (som en SQL-sats i ett PHP-skript skulle göra) eftersom en resurs kan ha flera renderingar.

Mappa begäranden till resurser mapping-requests-to-resources

Begäran är uppdelad och nödvändig information extraheras. Databasen genomsöks efter den begärda resursen (innehållsnod):

Med Sling kan även andra saker än JCR-noder vara resurser, men det här är en avancerad funktion.

Hitta skriptet locating-the-script

När rätt resurs (innehållsnod) finns, slingresurstyp extraheras. Detta är en sökväg som letar upp skriptet som ska användas för återgivning av innehållet.

Sökvägen som anges av sling:resourceType kan antingen vara:

Alla Sling-skript lagras i undermappar till båda /apps eller /libs, som söks igenom i den här ordningen (se Anpassa komponenter och andra element).

Några andra punkter att notera är:

Listan över skriptmotorer som stöds av den angivna AEM finns på Felix Management Console ( http://<host>:<port>/system/console/slingscripting).

Dessutom har Apache Sling stöd för integrering med andra populära skriptmotorer (till exempel Groovy, JRuby, Freemarker) och är ett sätt att integrera nya skriptmotorer.

Använda ovanstående exempel om sling:resourceType är hr/jobs sedan för:

Om flera skript gäller för en viss begäran väljs det skript som matchar bäst. Ju mer specifik en matchning är, desto bättre blir den; med andra ord matchar väljaren bättre, oavsett vilket tillägg eller metodnamn som används i begäran.

Ta till exempel en begäran om åtkomst till resursen
/content/corporate/jobs/developer.print.a4.html
av typen
sling:resourceType="hr/jobs"

Anta att du har följande lista med skript på rätt plats:

Sedan är ordningen (8) - (7) - (6) - (5) - (4) - (3) - (2) - (1).

Förutom resurstyperna (definieras primärt av sling:resourceType ) finns också resursens supertyp. Detta anges av sling:resourceSuperType -egenskap. De här supertyperna beaktas också när du försöker hitta ett skript. Fördelen med resurssupertyper är att de kan utgöra en hierarki av resurser där standardresurstypen är sling/servlet/default (används av standardservletarna) är roten.

Resursens överordnade typ kan definieras på två sätt:

Till exempel:

Typhierarkin för:

Det beror på att /y har sling:resourceSuperType egenskap. /x inte och dess supertyp tas därför från sin resurstyp.

Sling Scripts kan inte anropas direkt sling-scripts-cannot-be-called-directly

I Sling kan skript inte anropas direkt eftersom det skulle bryta det strikta begreppet med en REST-server. Du skulle blanda resurser och representationer.

Om du anropar representationen (skriptet) direkt döljer du resursen i skriptet, så att ramverket (Sling) inte längre vet om det. Därför förlorar du vissa funktioner:

Sling API sling-api

Detta använder Sling API-paketet org.apache.sling.* och taggbibliotek.

referera till befintliga element med sling:include referencing-existing-elements-using-sling-include

En sista sak är behovet av att referera till befintliga element i skripten.

Mer komplicerade skript (sammanställning av skript) måste ha åtkomst till flera resurser (navigering, sidospalt, sidfot, element i en lista, till exempel) och göra det genom att inkludera resurs.

Använd följande snedstreck: include("/<path>/<resource>"). Detta inkluderar effektivt definitionen av den refererade resursen, som i följande programsats som refererar till en befintlig definition för återgivning av bilder:

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

OSGI osgi

OSGi definierar en arkitektur för utveckling och driftsättning av modulära program och bibliotek (kallas även Dynamic Module System för Java™). Med OSGi-behållare kan du dela in programmet i enskilda moduler (som är jar-filer med ytterligare metainformation och kallas buntar i OSGi-terminologi) och hantera korsberoenden mellan dem med:

Dessa tjänster och kontrakt utgör en arkitektur som gör att enskilda element dynamiskt kan identifiera varandra för samarbete.

Ett OSGi-ramverk ger dig dynamisk inläsning/borttagning, konfiguration och kontroll av dessa paket - utan att du behöver starta om.

Med den här arkitekturen kan du utöka Sling med programspecifika moduler. Sling, och därmed CQ5, använder Apache Felix implementering av OSGI (Open Services Gateway-initiativ) och baseras på OSGi Service Platform version 4 version 4.2 Specifications. De är båda samlingar av OSGi-paket som körs i ett OSGi-ramverk.

Detta gör att du kan utföra följande åtgärder på något av paketen i din installation:

Se webbkonsolen, OSGI-konfigurationoch Konfigurationsinställningar för OSGi för mer information.

Utvecklingsobjekt i AEM development-objects-in-the-aem-environment

Följande är av intresse för utvecklingen:

Objekt Ett objekt är antingen en nod eller en egenskap.

Mer information om hur du hanterar Item-objekt finns i Java™ docs av Interface javax.jcr.Item

Nod (och deras egenskaper) Noder och deras egenskaper definieras i JCR API 2.0-specifikationen (JSR 283). De lagrar innehåll, objektdefinitioner, återgivningsskript och andra data.

Noderna definierar innehållsstrukturen och deras egenskaper lagrar det faktiska innehållet och metadata.

Innehållsnoder styr återgivningen. Sling hämtar innehållsnoden från den inkommande begäran. Egenskapen sling:resourceType för den här noden pekar på den Sling-återgivningskomponent som ska användas.

En nod, som är ett JCR-namn, kallas också en resurs i Sling-miljön.

Om du till exempel vill hämta egenskaperna för den aktuella noden kan du använda följande kod i skriptet:

PropertyIterator properties = currentNode.getProperties();

currentNode är det aktuella nodobjektet.

Mer information om hur du hanterar nodobjekt finns i Java™ docs.

Widget I AEM hanteras alla användarindata av widgetar. De används ofta för att styra redigeringen av ett visst innehåll.

Dialogrutor skapas genom att widgetar kombineras.

AEM har utvecklats med ExtJS-biblioteket med widgetar.

Dialog En dialogruta är en speciell typ av widget.

För att redigera innehåll använder AEM dialogrutor som definieras av programutvecklaren. Dessa kombinerar en serie widgetar för att ge användaren alla fält och åtgärder som behövs för att redigera det relaterade innehållet.

Dialogrutor används också för att redigera metadata och för olika administrationsverktyg.

Komponent En programvarukomponent är ett systemelement som erbjuder en fördefinierad tjänst eller händelse och kan kommunicera med andra komponenter.

I AEM används ofta en komponent för att återge innehållet i en resurs. När resursen är en sida, kallas komponentåtergivningen för en komponent på översta nivån eller en sidkomponent. En komponent behöver dock inte återge innehåll eller vara länkad till en viss resurs. En navigeringskomponent visar till exempel information om flera resurser.

Definitionen av en komponent omfattar följande:

Mall En mall är basen för en viss typ av sida. När användaren skapar en sida på fliken Webbplatser måste han eller hon välja en mall. Den nya sidan skapas sedan genom att den här mallen kopieras.

En mall är en hierarki med noder som har samma struktur som den sida som ska skapas, men utan något verkligt innehåll.

Den definierar den sidkomponent som används för att återge sidan och standardinnehållet (primärt innehåll på den översta nivån). Innehållet definierar hur det återges när AEM är innehållscentrerat.

Sidkomponent (komponent på översta nivån) Komponenten som ska användas för att återge sidan.

Sida En sida är en förekomst av en mall.

En sida har en hierarkinod av typen cq:Page och en innehållsnod av typen cq:PageContent. Egenskapen sling:resourceType för innehållsnoden pekar på den sidkomponent som används för återgivning av sidan.

Om du till exempel vill hämta namnet på den aktuella sidan kan du använda följande kod i skriptet:

String pageName = currentPage.getName();

AktuellSida är det aktuella sidobjektet. Mer information om hur du hanterar sidobjekt finns i Java™ docs.

Sidhanteraren Sidhanteraren är ett gränssnitt som innehåller metoder för åtgärder på sidnivå.

Om du till exempel vill hämta innehållssidan för en resurs kan du använda följande kod i skriptet:

Sida myPage = pageManager.getContainingPage(myResource);

pageManager är sidhanterarobjektet och myResource är ett resursobjekt. Mer information om de metoder som sidhanteraren tillhandahåller finns i Java™ docs.

Struktur i databasen structure-within-the-repository

I följande lista visas en översikt över strukturen som du ser i databasen.

Miljö environments

Med AEM består en produktionsmiljö ofta av två olika typer av instanser: en Författare och en publiceringsinstans.

Dispatcher the-dispatcher

Dispatcher är ett Adobe-verktyg för både cachelagring och/eller belastningsutjämning. Ytterligare information finns under Dispatcher.

FileVault (system för källrevision) filevault-source-revision-system

FileVault förser JCR-databasen med filsystemsmappning och versionskontroll. Det kan användas för att hantera AEM utvecklingsprojekt med fullt stöd för lagring och versionshantering av projektkod, innehåll, konfigurationer och så vidare i standardversionskontrollsystem (till exempel Subversion).

Se FileVault-verktyget detaljerad information.

Arbetsflöden workflows

Ditt innehåll omfattas ofta av organisatoriska processer, inklusive steg som godkännande och godkännande från olika deltagare. Dessa processer kan representeras som arbetsflöden, definieras och utvecklas inom AEMoch sedan tillämpas på lämpliga innehållssidor eller digitala resurser efter behov.

Arbetsflödesmotorn används för att hantera implementeringen av dina arbetsflöden och deras efterföljande program till ditt innehåll.

Hantering av flera webbplatser multi-site-management

Med Multi Site Manager (MSM) kan du enkelt hantera flera webbplatser som delar gemensamt innehåll. Med MSM kan du definiera relationer mellan platserna så att innehållsändringar på en plats automatiskt replikeras på andra platser.

Webbplatser finns till exempel ofta på flera språk för internationella målgrupper. När antalet webbplatser på samma språk är lågt (tre till fem) går det att synkronisera innehåll manuellt mellan webbplatser. Men när antalet webbplatser växer eller när flera språk används blir det effektivare att automatisera processen.

Mer information finns i Multi Site Manager.