AEM - riktlinjer och bästa praxis

Senast uppdaterad: 4 maj 2023

Skapat för:

  • Developer
CAUTION
AEM 6.4 har nått slutet på den utökade supporten och denna dokumentation är inte längre uppdaterad. Mer information finns i teknisk supportperiod. Hitta de versioner som stöds här.

Riktlinjer för användning av mallar och komponenter

AEM komponenter och mallar utgör en mycket kraftfull verktygslåda. De kan användas av utvecklare för att ge användare, redaktörer och administratörer på webbplatser den funktionalitet de behöver för att anpassa sina webbplatser till föränderliga affärsbehov (innehållsflexibilitet) samtidigt som webbplatsernas enhetliga layout (varumärkesskydd) bibehålls.

En typisk utmaning för en person som ansvarar för en webbplats, eller en uppsättning webbplatser (till exempel på ett globalt företags kontor) är att presentera en ny typ av innehållspresentation på deras webbplatser.

Låt oss anta att det finns ett behov av att lägga till en nyhetslistsida på webbplatserna, som listar utdrag från andra artiklar som redan har publicerats. Sidan ska ha samma design och struktur som resten av webbplatsen.

Det rekommenderade sättet att hantera en sådan utmaning är att

  • Återanvänd en befintlig mall för att skapa en ny typ av sida. Mallen definierar en sidstruktur (navigeringselement, paneler och så vidare) som finjusteras ytterligare av dess design (CSS, grafik).
  • Använd styckesystemet (parsys/iparsys) på de nya sidorna.
  • Definiera direkt åtkomst till styckesystemens designläge, så att endast behöriga personer (vanligtvis administratören) kan ändra dem.
  • Definiera de komponenter som tillåts i det angivna styckesystemet så att redigerare sedan kan placera de nödvändiga komponenterna på sidan. I det här fallet kan det vara en listkomponent som kan gå igenom ett underträd med sidor och extrahera informationen enligt fördefinierade regler.
  • Redigerare lägger till och konfigurerar de tillåtna komponenterna, på de sidor som de ansvarar för, för att leverera den begärda funktionen (information) till företaget.

Detta visar hur detta tillvägagångssätt gör det möjligt för de medverkande användarna och administratörerna på webbplatsen att snabbt reagera på affärsbehov, utan att utvecklingsteamen behöver vara engagerade. Alternativa metoder, till exempel att skapa en ny mall, är vanligtvis en kostsam övning som kräver en ändringshanteringsprocess och att utvecklingsteamet är engagerat. Detta gör hela processen mycket längre och kostsam.

Utvecklarna av AEM bör därför använda

  • mallar och åtkomstkontroll för styckesystemdesign för enhetligt varumärke och varumärkesskydd
  • styckesystem inklusive dess konfigurationsalternativ för flexibilitet.

Följande allmänna regler för utvecklare är bra för de flesta vanliga projekt:

  • Behåll lågt antal mallar - lika lite som antalet helt olika sidstrukturer på webbplatserna.
  • Erbjud nödvändig flexibilitet och konfigurationsfunktioner till dina anpassade komponenter.
  • Maximera användningen av kraften och flexibiliteten i AEM styckesystem - komponenterna parsys och iparsys.

Anpassa komponenter och andra element

När du skapar egna komponenter eller anpassar en befintlig komponent är det oftast enklast (och säkraste) att återanvända befintliga definitioner. Samma principer gäller även andra element i AEM, till exempel felhanteraren.

Detta kan du göra genom att kopiera och ersätta den befintliga definitionen. Med andra ord, kopiera definitionen från /libs till /apps/<your-project>. Den här nya definitionen, i /apps, kan uppdateras efter dina behov.

NOTE
Se Använda övertäckningar för mer information.

Till exempel:

  • Anpassa en komponent

    Detta innebar att en komponentdefinition skulle ersättas:

    • Skapa en ny komponentmapp i /apps/<website-name>/components/<MyComponent> genom att kopiera en befintlig komponent:

      • Så här anpassar du komponentkopian Text:

        • från /libs/foundation/components/text
        • till /apps/myProject/components/text

  • Anpassa sidor som visas av felhanteraren

    Det här fallet handlar om att täcka över en serverdel:

    • Kopiera standardskripten i databasen:

      • från /libs/sling/servlet/errorhandler/
      • till /apps/sling/servlet/errorhandler/
CAUTION
Du får inte ändra något i /libs bana.
Detta beror på innehållet i /libs skrivs över nästa gång du uppgraderar din instans (och kan mycket väl skrivas över när du använder en snabbkorrigering eller ett funktionspaket).
För konfiguration och andra ändringar:
  1. kopiera objektet i /libs till /apps
  2. gör ändringar i /apps

När JCR-frågor ska användas och när de inte ska användas

JCR-frågor är ett kraftfullt verktyg när de används på rätt sätt. De är lämpliga för

  • riktiga slutanvändarfrågor, t.ex. fulltextsökningar i innehåll.

  • tillfällen då strukturerat innehåll måste hittas i hela databasen.

    I sådana fall ska du se till att frågor endast körs när det är absolut nödvändigt, t.ex. vid komponentaktivering eller cacheogiltigförklaring (till skillnad från t.ex. arbetsflödessteg, händelsehanterare som utlöser vid innehållsändringar, filter etc.).

JCR-frågor ska aldrig användas för renderingsbegäranden. JCR-frågor passar till exempel inte för

  • återgivningsnavigering
  • skapa en översikt över de 10 senaste nyhetsobjekten
  • visa antal innehållsobjekt

Använd navigeringsåtkomst till innehållsträdet i stället för att utföra en JCR-fråga när du återger innehåll.

NOTE
Om du använder Query Builderanvänder du JCR-frågor när Query Builder genererar JCR-frågor under huven.

Säkerhetsaspekter

NOTE
Det är även värt att hänvisa till checklista för säkerhet.

JCR-sessioner (databas)

Du bör använda användarsessionen, inte den administrativa sessionen. Detta innebär att du bör använda:

slingRequest.getResourceResolver().adaptTo(Session.class);

Protect mot XSS (Cross-Site Scripting)

Med XSS (Cross-site scripting) kan angripare lägga in kod på webbsidor som visas av andra användare. Säkerhetsluckan kan utnyttjas av skadliga webbanvändare för att kringgå åtkomstkontroller.

AEM tillämpar principen om att filtrera allt innehåll som användaren tillhandahåller vid utskrift. Förhindrande av XSS har högsta prioritet under både utveckling och testning.

Dessutom en brandvägg för webbprogram, som mod_security för Apache, kan ge tillförlitlig, central kontroll över distributionsmiljöns säkerhet och skydda mot tidigare oidentifierade serveröverskridande skriptattacker (cross-site scripting).

CAUTION
Exempelkod som medföljer AEM kan inte skydda sig mot sådana attacker och är vanligtvis beroende av att en webbprogrambrandvägg filtrerar begäranden.

XSS API-databladet innehåller information som du behöver känna till för att kunna använda XSS API:t och göra en AEM säkrare. Du kan ladda ned den här:

XSSAPI-kalkylbladet.

Hämta fil

Skydda kommunikation för konfidentiell information

Liksom för alla Internetprogram ska du se till att konfidentiella uppgifter skickas

  • trafiken säkras via SSL
  • HTTP-POST används om tillämpligt

Detta gäller information som är konfidentiell för systemet (t.ex. konfiguration eller administrativ åtkomst) samt information som är konfidentiell för användarna (t.ex. personuppgifter)

Distinkta utvecklingsuppgifter

Anpassa felsidor

Felsidor kan anpassas för AEM. Detta är tillrådligt så att instansen inte visar slingspår på interna serverfel.

Se Anpassa felsidor som visas av felhanteraren för fullständig information.

Öppna filer i Java-processen

Eftersom AEM kan få åtkomst till ett stort antal filer rekommenderar vi att man öppna filer för en Java-process vara explicit konfigurerad för AEM.

För att minimera problemet bör du se till att alla öppnade filer stängs korrekt så snart som (meningsfullt) möjligt.

Föregående sida
Nästa sida

Experience Manager