JCR-integrering

Föredra Sling Resource API till JCR API

Sling API fungerar på en högre och mer abstrakt nivå än JCR API. Detta gör att koden kan återanvändas mer och vara oberoende av den underliggande lagringen. Detta gör det enklare att inkludera externa virtuella data via ResourceProvider-mekanismen om det behövs.

Undvik frågor där det är möjligt

Det är alltid snabbare att navigera i databasen för att hämta data än att köra en fråga. Det finns tillfällen då frågor är nödvändiga, t.ex. en slutanvändarfråga eller behöver hitta strukturerat innehåll från hela databasen, men i alla andra fall är det bäst att navigera till de noder som behövs. Frågor bör alltid undvikas i återgivningslogik som navigeringskomponenter,"lista över senaste objekt", antal objekt och så vidare. I dessa fall är det bättre att gå igenom hierarkin eller cachelagra resultatet i förväg så att det kan användas direkt när det återges.

Begränsa omfattningen av JCR-observation

När du lyssnar efter händelser i databasen är det viktigt att begränsa omfattningen så mycket som möjligt. Det är till exempel mycket bättre att lyssna efter en händelse på /etc/mycompany inte lyssna på /etc. Lyssna aldrig efter händelser i databasroten. Kontrollera dessutom att återkallningsmetoderna körs så snabbt som möjligt när det inte finns något att göra.

Eliminera användningen av JCR-administratörsåtkomst

Från och med AEM 6 används inte inloggningsadministration eftersom en administrativ session har hämtats från ResourceResolverFactory. Tjänstkonton ska i stället skapas för back office-åtgärder som skulle kräva den här typen av åtkomst och ResourceResolverFactory kan användas för att hämta en ResourceResolver för det här kontot.