AEM används för att lagra, formatera och återge innehåll som är tillgängligt på dina webbsidor.
När skapa sidorgör komponenterna att författarna kan redigera och konfigurera innehållet.
När en Handel -plats kan komponenterna till exempel samla in och återge information från katalogen.
Se Utveckla e-handeln för mer information.
När en Communities sajten som komponenterna kan tillhandahålla information till och samla in information från era besökare.
Se Utveckla webbgrupper för mer information.
I publiceringsinstansen återger komponenterna ditt innehåll och presenterar det som du vill för webbplatsens besökare.
Den här sidan är en fortsättning på dokumentet AEM - Grunderna.
Komponenter nedan /libs/cq/gui/components/authoring/dialog
ska bara användas i redigeraren (komponentdialogrutor i redigeringsverktyget). Om de används någon annanstans (t.ex. i en guidedialogruta) kanske de inte fungerar som förväntat.
Den här sidan innehåller referensdokumentation (eller länkar till referensdokumentation) som krävs för att utveckla nya komponenter för AEM. Se Utveckla AEM - kodexempel för några praktiska exempel.
En komponents grundläggande struktur beskrivs på sidan AEM - Grunderna. Dokumentet omfattar både pekaktiverade och klassiska användargränssnitt. Även om du inte behöver använda de klassiska inställningarna i den nya komponenten kan det vara bra att känna till dem när du ärver från befintliga komponenter.
Beroende på vilken komponent du vill implementera kan det vara möjligt att utöka eller anpassa en befintlig instans i stället för att definiera och utveckla hela struktur från scratch.
När du utökar eller anpassar en befintlig komponent eller dialogruta kan du kopiera eller replikera antingen hela strukturen eller den struktur som krävs för dialogrutan innan du gör ändringarna.
Du kan utöka en befintlig komponent med Hierarki för resurstyp och tillhörande arvsmekanismer.
Komponenter kan också definieras om med en övertäckning som baseras på sökvägslogiken. I sådana fall gäller dock att Samla resurser aktiveras inte och /apps
måste definiera hela övertäckningen.
The komponent för innehållsfragment kan också anpassas och utökas, men hela strukturen och relationerna med Assets måste beaktas.
Du kan även åsidosätta en komponentdialogruta med Samla resurser och definiera egenskapen sling:resourceSuperType
.
Det innebär att du bara behöver definiera om skillnaderna, i stället för att definiera om hela dialogrutan (med sling:resourceSuperType
). Den här metoden rekommenderas nu för att utöka en komponentdialogruta
Se Samla resurser för mer information.
Komponenten återges med HTML. Komponenten måste definiera den HTML som behövs för att ta det önskade innehållet och sedan återge det som det behövs, både i författarmiljön och i publiceringsmiljön.
The HTML (HTML Templating Language), som introducerades med AEM 6.0, ersätter JSP (JavaServer Pages) som det rekommenderade serversidesmallsystemet för HTML. För webbutvecklare som behöver bygga robusta företagswebbplatser kan HTML bidra till ökad säkerhet och effektivare utveckling.
Även om både HTML och JSP kan användas för att utveckla komponenter illustrerar vi utvecklingen med HTML på den här sidan, eftersom det är det rekommenderade skriptspråket för AEM.
Denna valfria logik markerar och/eller beräknar innehållet som ska återges. Den anropas från HTML-uttryck med rätt Use-API-mönster.
Mekanismen för att skilja logik från utseende gör det lättare att klargöra vad som krävs för en viss vy. Det möjliggör också olika logik för olika vyer av samma resurs.
Använd-API:t för HTL Java gör att en HTML-fil kan få åtkomst till hjälpmetoder i en anpassad Java-klass. Detta gör att du kan använda Java-kod för att implementera logiken för att välja och konfigurera komponentinnehållet.
Använd-API:t för HTML JavaScript gör att en HTML-fil kan komma åt hjälpkod som skrivits i JavaScript. På så sätt kan du använda JavaScript-kod för att implementera logiken för att välja och konfigurera komponentinnehållet.
Moderna webbplatser är starkt beroende av bearbetning på klientsidan som styrs av komplex JavaScript- och CSS-kod. Det kan vara komplicerat att organisera och optimera serveringen av koden.
AEM tillhandahåller Biblioteksmappar på klientsidan, som gör att du kan lagra din klientkod i databasen, ordna den i kategorier och definiera när och hur varje kodkategori ska skickas till klienten. Klientsidans bibliotekssystem tar sedan hand om att skapa rätt länkar på den slutliga webbsidan för att läsa in rätt kod.
Läs Använda HTML-bibliotek på klientsidan för mer information.
Du kan konfigurera redigeringsbeteendet för en komponent, inklusive attribut som åtgärder som är tillgängliga för komponenten, egenskaper för redigeraren och avlyssnare som är relaterade till händelser för komponenten. Konfigurationen är gemensam för det beröringsaktiverade och klassiska användargränssnittet, men med vissa specifika skillnader.
The redigeringsbeteendet för en komponent är konfigurerat genom att lägga till en cq:editConfig
nod av typen cq:EditConfig
nedanför komponentnoden (av typen cq:Component
) och genom att lägga till specifika egenskaper och underordnade noder.
The WCM-läge cookie är inställd vid växling till Förhandsgranska även när sidan inte uppdateras.
Komponenter med en återgivning som är känslig för WCM-läget måste definieras så att de uppdateras specifikt och sedan baseras på värdet för cookien.
I det beröringskänsliga användargränssnittet är endast värdena EDIT
och PREVIEW
används för WCM-läge cookie.
I dialogrutor kan författaren interagera med komponenten. Med en dialogruta kan författare och/eller administratörer redigera innehåll, konfigurera komponenten eller definiera designparametrar (med en Designdialogruta)
Coral UI och Granite-gränssnitt definiera det moderna utseendet och känslan hos AEM.
Gränssnittet i Granite innehåller ett stort urval av de grundläggande komponenterna (widgetar) behövs för att skapa en dialogruta i redigeringsmiljön. Vid behov kan du utöka markeringen och skapa en egen widget.
Mer information finns i:
Coral UI
Granite-gränssnitt
På grund av karaktären hos GRE-komponenterna (och skillnaderna mellan ExtJS-widgetarna) finns det vissa skillnader mellan hur komponenterna interagerar med det beröringskänsliga användargränssnittet och klassiskt användargränssnitt.
Dialogrutor för det beröringskänsliga användargränssnittet:
är namngivna cq:dialog
.
definieras som nt:unstructured
noden med sling:resourceType
egenskapsuppsättning.
finns under deras cq:Component
och bredvid deras komponentdefinition.
återges på serversidan (som Sling-komponenter) baserat på deras innehållsstruktur och sling:resourceType
-egenskap.
använda GRI-ramverket för Granite.
innehåller en nodstruktur som beskriver fälten i dialogrutan.
nt:unstructured
med sling:resourceType
-egenskap.En exempelnodstruktur kan vara:
newComponent (cq:Component)
cq:dialog (nt:unstructured)
content
layout
items
column
items
file
description
Att anpassa en dialogruta liknar att utveckla en komponent eftersom dialogrutan i sig är en komponent (d.v.s. markering som återges av ett komponentskript tillsammans med beteende/stil som tillhandahålls av ett klientbibliotek).
Se till exempel:
/libs/foundation/components/text/cq:dialog
/libs/foundation/components/download/cq:dialog
Om en komponent inte har någon dialogruta definierad för det beröringsaktiverade användargränssnittet, används den klassiska användargränssnittsdialogrutan som reserv i ett kompatibilitetslager. Om du vill anpassa en sådan dialogruta måste du anpassa den klassiska användargränssnittsdialogrutan. Se AEM för det klassiska användargränssnittet.
Se:
Widgetar för det beröringsaktiverade användargränssnittet implementeras som GRE-komponenter.
Om du vill skapa en ny widget som ska användas i en komponentdialogruta för det beröringsaktiverade användargränssnittet måste du skapa en ny gränssnittskomponent för Granite.
Mer information om GRENITE finns i Granite UI-dokumentation.
Om du ser dialogrutan som en enkel behållare för ett formulärelement kan du även se det primära innehållet i dialogrutan som formulärfält. Om du skapar ett nytt formulärfält måste du skapa en resurstyp; motsvarar att skapa en ny komponent. För att du ska få hjälp med den uppgiften erbjuder Granite UI en generisk fältkomponent att ärva från (med sling:resourceSuperType
):
/libs/granite/ui/components/coral/foundation/form/field
Mer specifikt ger GRE UI ett antal fältkomponenter som är lämpliga att använda i dialogrutor (eller mer allmänt i formulär).
Detta skiljer sig från det klassiska användargränssnittet, där widgetar representeras av cq:Widgets
noder, var och en med en viss xtype
för att fastställa relationen med deras motsvarande ExtJS-widget. Från en implementeringssynvinkel renderades dessa widgetar på klientsidan av ExtJS-ramverket.
När du har skapat resurstypen kan du skapa en instans av fältet genom att lägga till en ny nod i dialogrutan med egenskapen sling:resourceType
refererar till den resurstyp som du just har introducerat.
Om du vill definiera format och beteende för komponenten kan du skapa en dedikerad klientbibliotek som definierar din egen CSS/LESS och JS.
Om du vill att klientbiblioteket ska läsas in enbart för komponentdialogrutan (d.v.s. den inte ska läsas in för en annan komponent) måste du ange egenskapen extraClientlibs
** **i dialogrutan till kategorinamnet för det klientbibliotek du just har skapat. Detta rekommenderas om klientbiblioteket är stort och/eller om fältet är specifikt för den dialogrutan och inte behövs i andra dialogrutor.
Om du vill att klientbiblioteket ska läsas in för alla dialogrutor anger du kategoriegenskapen för klientbiblioteket till cq.authoring.dialog
. Det här är kategorinamnet för klientbiblioteket som inkluderas som standard när alla dialogrutor återges. Du vill göra det om klientbiblioteket är litet och/eller fältet är generiskt och kan återanvändas i andra dialogrutor.
Se följande exempel:
cqgems/customizingfield/components/colorpicker/clientlibs
Beroende på dina behov kan du antingen:
sling:resourceSuperType
)Du kan också använda återgivningsvillkor ( rendercondition
) för att styra vem som har åtkomst till specifika flikar/fält i din dialog, till exempel:
+ mybutton
- sling:resourceType = granite/ui/components/coral/foundation/button
+ rendercondition
- sling:resourceType = myapp/components/renderconditions/group
- groups = ["administrators"]
Metoden för att hantera händelser i dialogrutefält är nu klar med avlyssnare i ett anpassat klientbibliotek. Detta är en förändring från den äldre metoden att avlyssnare i innehållsstrukturen.
För att lägga in logik i fältet bör du:
För att uppnå detta måste du känna till det underliggande widgetbiblioteket som du vill interagera med. Se Dokumentation för Coral UI identifiera vilken händelse du vill reagera på. Detta liknar den process du tidigare använde för att utföra ExtJS: hitta dokumentationssidan för en viss widget och kontrollera sedan informationen om dess händelse-API.
Se följande exempel:
cqgems/customizingfield/components/clientlibs/customizingfield
I det klassiska användargränssnittet med ExtJS var det vanligt att ha avlyssnare för en viss widget i innehållsstrukturen. Att uppnå samma sak i det beröringskänsliga användargränssnittet skiljer sig från JS-avlyssnarkoden (eller vilken kod som helst) som inte längre är definierad i innehållet.
Innehållsstrukturen beskriver den semantiska strukturen. det ska (måste) inte antyda den underliggande widgetens karaktär. Genom att inte ha JS-kod i innehållsstrukturen kan du ändra implementeringsinformationen utan att behöva ändra innehållsstrukturen. Du kan med andra ord ändra widgetbiblioteket utan att behöva ändra innehållsstrukturen.
Om du har ett anpassat JavaScript som bara behöver köras när dialogrutan är tillgänglig och klar bör du avlyssna dialog-ready
-händelse.
Den här händelsen utlöses när dialogrutan läses in (eller läses in igen) och är klar att användas, vilket innebär när det finns en ändring (skapa/uppdatera) i DOM för dialogrutan.
dialog-ready
kan användas för att koppla i anpassad JavaScript-kod som utför anpassningar av fälten i en dialogruta eller liknande åtgärder.
Om du vill markera ett givet fält som obligatoriskt anger du följande egenskap på innehållsnoden i fältet:
required
Boolean
Se följande exempel:
/libs/foundation/components/page/cq:dialog/content/items/tabs/items/basic/items/column/items/title/items/title
Fältvalidering i GRA-gränssnitt och GRA-komponenter (motsvarande widgetar) görs med foundation-validation
API. Se foundation-valdiation
Behåll dokumentation för mer information.
Se till exempel:
cqgems/customizingfield/components/clientlibs/customizingfield/js/validations.js
/libs/cq/gui/components/authoring/dialog/clientlibs/dialog/js/validations.js
Dialogrutan Design visas när en komponent har designdetaljer som kan redigeras i Designläge.
Definitionen liknar den för en dialogruta som används för att redigera innehåll, med skillnaden att det är definierat som en nod:
cq:design_dialog
nt:unstructured
Med en infogningsredigerare kan användaren redigera innehåll direkt i styckeflödet utan att behöva öppna en dialogruta. Standardkomponenterna Text och Title har till exempel båda en infogad redigerare.
En infogningsredigerare är inte nödvändig/meningsfull för varje komponenttyp.
Se Utöka sidredigering - Lägg till ny infogningsredigerare för mer information.
The Komponentverktygsfältet ger användaren tillgång till en rad åtgärder för komponenten, till exempel redigera, konfigurera, kopiera och ta bort.
Se Utöka sidredigering - Lägg till ny åtgärd i ett komponentverktygsfält för mer information.
Om den nya komponenten refererar till innehåll från andra sidor kan du överväga om du vill att den ska påverka Lånat innehåll och Utlånat innehåll avsnitt i Referenser Rail.
AEM markerar bara komponenten Reference. Om du vill lägga till din komponent måste du konfigurera OSGi-paketet Referenskonfiguration för WCM-redigeringsinnehåll.
Skapa en ny post i definitionen som anger komponenten tillsammans med den egenskap som ska kontrolleras. Till exempel:
/apps/<*your-Project*>/components/reference@parentPath
När du arbetar med AEM finns det flera sätt att hantera konfigurationsinställningarna för sådana tjänster. Se Konfigurerar OSGi om du vill ha mer information och rekommenderade rutiner.
När komponenten har utvecklats måste den aktiveras för användning i ett lämpligt styckesystem, så att den kan användas på de sidor som krävs.
Detta kan göras antingen genom att:
components
egenskap i en malls styckesystem.AEM erbjuder möjlighet att konfigurera ett styckesystem på sidan så att en instans av den nya komponenten skapas automatiskt när en användare drar en (lämplig) resurs till en instans av sidan (i stället för att alltid behöva dra en tom komponent till sidan).
Detta beteende och den nödvändiga relationen mellan resurser och komponenter kan konfigureras:
Under styckedefinitionen för siddesignen. Till exempel:
/etc/designs/<myApp>/page/par
Skapa en ny nod:
cq:authoring
nt:unstructured
Skapa en ny nod under detta för att innehålla alla mappningar av resurs-till-komponent:
assetToComponentMapping
nt:unstructured
Skapa en nod för varje resurs-till-komponent-mappning:
nt:unstructured
Var och en med följande egenskaper:
assetGroup
:
String
media
assetMimetype
:
String
image/*
droptarget
:
String
image
resourceType
:
String
foundation/components/image
type
:
String
Images
Exempel:
/etc/designs/geometrixx/jcr:content/page/par/cq:authoring
/etc/designs/geometrixx-outdoors/jcr:content/page/par/cq:authoring
/etc/designs/geometrixx-media/jcr:content/article/article-content-par/cq:authoring
KOD PÅ GITHUB
Koden för den här sidan finns på GitHub
Det automatiska skapandet av komponentinstanser kan nu enkelt konfigureras i användargränssnittet när du använder Kärnkomponenter och redigerbara mallar. Se Skapa sidmallar om du vill ha mer information om hur du definierar vilka komponenter som automatiskt kopplas till angivna medietyper.
The AEM Brackets Extension ger ett smidigt arbetsflöde för att redigera AEM komponenter och klientbibliotek. Den baseras på Hakparenteser kodredigerare.
Tillägget:
Hakparenteser är den rekommenderade mekanismen för att skapa komponenter. Den ersätter funktionaliteten CRXDE Lite - Skapa komponent, som har utformats för det klassiska användargränssnittet.
När du migrerar en komponent som har utformats för användning med det klassiska användargränssnittet till en komponent som kan användas med det beröringsaktiverade användargränssnittet (antingen enbart eller tillsammans) bör du tänka på följande:
HTL
Komponenter
cq:listener
kod som använder klassiska gränssnittsspecifika funktionercq:listener
kod som använder funktioner som är specifika för det klassiska användargränssnittetDialogrutor
Om du migrerar ett projekt som har utformats för det klassiska användargränssnittet ska du cq:listener
kod (och komponentrelaterade klienter) kan använda funktioner som är specifika för det klassiska användargränssnittet (till exempel CQ.wcm.*
). För migreringen måste du uppdatera sådan kod med motsvarande objekt/funktioner i det beröringsaktiverade användargränssnittet.
Om ditt projekt ska migreras helt till det beröringskänsliga användargränssnittet måste du ersätta den koden för att använda de objekt och funktioner som är relevanta för det beröringskänsliga användargränssnittet.
Om ditt projekt måste tillgodose både det klassiska användargränssnittet och det beröringsaktiverade användargränssnittet under migreringsperioden (det vanliga scenariot) måste du implementera en switch för att särskilja den separata koden som refererar till lämpliga objekt.
Den här switchmekanismen kan implementeras som:
if (Granite.author) {
// touch UI
} else {
// classic UI
}
Som utvecklare vill du ha enkel åtkomst till komponentdokumentation så att du snabbt kan förstå:
Därför är det enkelt att göra befintliga dokumentationsmarkeringar tillgängliga i själva komponenten.
Placera en README.md
i komponentstrukturen. Den här markeringen visas i dialogrutan komponentkonsol.
Den kod som stöds är densamma som den som innehållsfragment.