Riktlinjer för komponenter component-guidelines

The Kärnkomponenter följer moderna implementeringsmönster som är helt annorlunda än de grundläggande komponenterna.

På den här sidan förklaras de här mönstren och när du ska använda dem för att skapa egna författarskapande komponenter. Första avsnittet Allmänna komponentmönster gäller för alla typer av komponenter, medan andra avsnittet Återanvändbara komponentmönster används för komponenter som är avsedda att återanvändas på webbplatser eller i projekt, som till exempel kärnkomponenterna.

Allmänna komponentmönster general-component-patterns

Riktlinjerna i det här avsnittet rekommenderas för alla typer av komponenter, oavsett om komponenten är specifik för ett enskilt projekt eller om komponenten är avsedd att återanvändas i stor omfattning på webbplatser eller i projekt.

Konfigurerbara komponenter configurable-components

Komponenter kan ha dialogrutor med en mängd olika alternativ. Detta bör utnyttjas för att göra komponenterna flexibla och konfigurerbara och undvika att implementera flera komponenter som i huvudsak är varianter av varandra.

Om en trådram eller design innehåller variationer av liknande element bör dessa variationer vanligtvis inte implementeras som olika komponenter, utan som den enda komponenten med alternativ att välja mellan variationerna.

Om du vill gå ett steg längre och om komponenter återanvänds på olika webbplatser eller i olika projekt, se Förkonfigurerbara funktioner -avsnitt.

Separation av oro separation-of-concerns

Att hålla logiken (eller modellen) för en komponent åtskild från markeringsmallen (eller vyn) är vanligtvis en bra vana. Det finns flera sätt att uppnå det, men det rekommenderas att använda Sling Models för logiken och HTML mallspråk (HTML) för markeringen, precis som Core Components också.

Sling Models är en uppsättning Java-anteckningar som gör det enkelt att komma åt nödvändiga variabler från POJO:er och därför erbjuder ett enkelt, kraftfullt och effektivt sätt att implementera Java-logik för komponenter.

HTML har utformats för att vara ett säkert och enkelt mallspråk som är anpassat för AEM. Det kan kalla många typer av logik, vilket gör den mycket flexibel.

Återanvändbara komponentmönster reusable-component-patterns

Riktlinjerna i det här avsnittet kan även användas för alla typer av komponenter, men de passar bäst för komponenter som är avsedda att återanvändas på webbplatser eller i projekt, som till exempel kärnkomponenterna. Dessa riktlinjer kan därför ignoreras för komponenter som bara används på en enda plats eller ett enda projekt.

Förkonfigurerbara funktioner pre-configurable-capabilities

Förutom redigeringsdialogrutan som används av sidförfattare kan komponenterna även ha en designdialogruta där mallförfattare kan förkonfigurera dem. The Mallredigerare I kan du konfigurera alla dessa förkonfigurationer, som kallas för "Principer".

För att göra komponenterna så återanvändbara som möjligt bör de ha meningsfulla alternativ för förkonfiguration. Detta gör att du kan aktivera eller inaktivera funktioner i komponenterna för att passa de specifika behoven på olika platser.

Proxykomponentmönster proxy-component-pattern

Varje innehållsresurs har en sling:resourceType som refererar till komponenten för att återge den, är det oftast bra att ha dessa egenskaper som pekar på platsspecifika komponenter, i stället för att peka på komponenter som delas av flera platser. Detta ger större flexibilitet och undviker innehållsomfaktorisering om en webbplats behöver ett annat beteende för en komponent, eftersom den här anpassningen då kan göras på den platsspecifika komponenten och inte påverkar de andra platserna.

För att de projektspecifika komponenterna inte ska duplicera någon kod bör de referera till den delade överordnade komponenten med sling:resourceSuperType -egenskap. Dessa projektspecifika komponenter som oftast bara refererar till överordnade komponenter kallas"proxykomponenter". Proxykomponenter kan vara helt tomma om de helt ärver funktionaliteten, eller så kan de definiera om vissa aspekter av komponenten.

Komponentversionshantering component-versioning

Komponenterna bör vara helt kompatibla över tid, men ibland krävs ändringar som inte kan hållas kompatibla. En lösning på de motsatta behoven är att införa komponentversionshantering genom att lägga till en siffra i resurstypsökvägen och i de fullständiga Java-klassnamnen för implementeringarna. Versionsnumret representerar en huvudversion som definieras av riktlinjer för semantisk versionshantering, som endast ökas för ändringar som inte är bakåtkompatibla.

Inkompatibla ändringar i följande aspekter av komponenterna resulterar i en ny version av dem:

Mer information finns i Versionsprinciper -dokument i GitHub.

Komponentversionshantering skapar en typ av kontrakt som är viktig för uppgraderingar eftersom den klargör när något behöver ändras. Se även avsnittet Uppgraderingskompatibilitet för anpassningar, som förklarar vad olika typer av anpassningar kräver för en uppgradering.

För att undvika krånglig innehållsmigrering är det viktigt att aldrig peka direkt på versionskomponenter från innehållsresurser. Som tumregel är sling:resourceType av innehållet får aldrig ha något versionsnummer, eller om du uppgraderar komponenter måste innehållet också ändras. Det bästa sättet att undvika detta är att följa Proxykomponentmönster som beskrivs ovan.

Modellgränssnitt model-interfaces

Det här mönstret handlar om HTML:er data-sly-use -instruktion som pekar på ett Java-gränssnitt, medan implementeringen av Sling-modellen också registrerar sig själv för komponentens resurstyp.

I kombination med Proxykomponentmönster som beskrivs ovan, den här typen av dubbelbindningserbjudanden som följer efter fina tilläggspunkter:

Sammanställ allt putting-it-all-together

Nedan visas en översikt över hela bindningsstrukturen för resurstyper, som i exemplet med kärnkomponenten Title. Det visar hur en platsspecifik proxykomponent kan lösa komponentversionshantering, så att innehållsresursen inte innehåller något versionsnummer. Sedan visas hur komponenten title.html HTL filen använder till modellgränssnittet, medan implementeringen binder till den specifika versionen av komponenten via Sling Model anteckningar.

Nedan finns en annan översikt som inte visar information om implementeringens POJO, men som visar hur den associerade mallar och policyer refereras.

The cq:allowedTemplates anger vilka mallar som kan användas för en plats, och cq:template anger för varje sida vad den associerade mallen är. Varje mall består av följande tre delar:

AEM Project Archetype aem-project-archetype

AEM Project Archetype skapar ett minimalt Adobe Experience Manager-projekt som startpunkt för dina egna projekt, inklusive ett exempel på anpassade HTML-komponenter med SlingModels för att logiken och implementeringen av Core Components med det rekommenderade proxymönstret ska fungera.

Läs nästa: