AEM API:er

AEM API:er innehåller abstraktioner och funktioner som är specifika för produktioner.

AEM-API:erna PageManager och Page innehåller till exempel abstraktioner för cq:Page noder i AEM som representerar webbsidor.

Dessa noder är tillgängliga via Sling API:er som resurser och JCR-API:er som noder, men AEM API:er innehåller abstraktioner för vanliga användningsområden. Med AEM API:er säkerställs ett konsekvent beteende mellan AEM och AEM samt anpassningar och tillägg.

com.adobe.* vs com.day.* API:er

AEM-API:er har en paketspecifik inställning som identifieras av följande Java™-paket, i prioritetsordning:

  1. com.adobe.cq
  2. com.adobe.granite
  3. com.day.cq

Paketet com.adobe.cq har stöd för produktanvändningsfall, medan com.adobe.granite har stöd för flerproduktsplattformsanvändning, som arbetsflöde eller uppgifter (som används för olika produkter: AEM Assets, Sites, osv.).

Paketet com.day.cq innehåller ursprungliga API:er. Dessa API:er åtgärdar viktiga abstraktioner och funktioner som fanns före och/eller runt Adobe förvärv av Day CQ. Dessa API:er stöds och bör undvikas, såvida inte com.adobe.cq- eller com.adobe.granite-paketen inte har ett (nyare) alternativ.

Nya abstraktioner som Content Fragments och Experience Fragments är inbyggda i com.adobe.cq-utrymmet i stället för com.day.cq som beskrivs nedan.

Fråga API:er

AEM stöder flera frågespråk. De tre huvudspråken är JCR-SQL2, XPath och AEM Query Builder.

Det viktigaste problemet är att ha ett konsekvent frågespråk i hela kodbasen, vilket minskar komplexiteten och gör att du lättare kan förstå kostnaderna.

Alla frågespråk har i princip samma prestandaprofiler, eftersom Apache Oak kopplar dem till JCR-SQL2 för slutlig frågekörning, och konverteringstiden till JCR-SQL2 är försumbar jämfört med själva frågetiden.

Det önskade API:t är AEM Query Builder, som är den högsta nivån för abstraktion och som tillhandahåller ett robust API för att skapa, köra och hämta resultat för frågor, och som ger följande:

CAUTION
AEM QueryBuilder API läcker ett ResourceResolver-objekt. Följ det här kodexemplet om du vill minska läckan.

Sling API:er

Apache Sling är det RESTful-webbramverk som stöder AEM. Sling tillhandahåller routning av HTTP-begäran, modeller av JCR-noder som resurser, ger säkerhetskontext och mycket annat.

Sling API:er har dessutom fördelen att skapas för tillägg, vilket innebär att det ofta är enklare och säkrare att förstärka beteendet för program som skapats med Sling API:er än de mindre utökningsbara JCR-API:erna.

Vanliga användningsområden för Sling API:er

JCR-API:er

JCR-API:erna (Java™ Content Repository) 2.0 är en del av en specifikation för JCR-implementeringar (för AEM Apache Jackrabbit Oak). All JCR-implementering måste följa och implementera dessa API:er, och är därför den lägsta nivån för API för interaktion med AEM-innehåll.

Själva JCR är ett hierarkiskt/trädbaserat NoSQL-datalager som AEM använder som innehållsdatabas. JCR har en mängd API:er som stöds, från innehålls-CRUD till frågor om innehåll. Trots detta robusta API är det sällsynt att de föredras framför AEM- och Sling-abstraktioner på högre nivå.

Använd alltid JCR-API:erna framför API:erna i Apache Jackrabbit Oak. JCR-API:erna är till för interaktion med en JCR-databas, medan Oak-API:erna är till för implementering av en JCR-databas.