Dokumentation AEM 6.4 Användarhandbok om utveckling

AEM - Grunderna aem-components-the-basics

Last update: Thu May 04 2023 00:00:00 GMT+0000 (Coordinated Universal Time)

Ämnen:
Developing

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.

När du börjar utveckla nya komponenter måste du förstå grunderna i deras struktur och konfiguration.

Den här processen innebär att man läser teorin och tittar på ett brett urval av komponentimplementeringar i en AEM. Det senare tillvägagångssättet är något komplicerat av det faktum att även om AEM har övergått till en ny standard, modern, pekaktiverad användarupplevelse, har det fortfarande stöd för det klassiska användargränssnittet.

Översikt overview

I det här avsnittet beskrivs viktiga koncept och problem som en introduktion till den information som behövs när du utvecklar egna komponenter.

Planering planning

Innan du börjar konfigurera eller koda komponenten bör du fråga:

Vad behöver du den nya komponenten till?
- En tydlig specifikation hjälper till i alla faser av utveckling, testning och överlämning.
  
  Detaljerna kan förändras över tid, men specifikationen kan uppdateras (men ändringarna bör också dokumenteras).
Behöver du skapa komponenten från grunden, eller kan du ärva grunderna från en befintlig komponent?
- Man behöver inte förnya hjulet.
- Det finns flera sätt i AEM som gör att du kan ärva och utöka detaljer från en annan komponentdefinition, inklusive åsidosättning, övertäckning och Samla resurser.
Kommer din komponent att behöva logik för att markera/ändra innehållet?
- Logiken ska hållas åtskild från användargränssnittets lager. HTML är utformat för att säkerställa att detta sker.
Behöver komponenten CSS-formatering?
- CSS-formateringen ska hållas åtskild från komponentdefinitionerna. Definiera konventioner för att namnge elementen i HTML så att du kan ändra dem via externa CSS-filer.
Vilka säkerhetsaspekter bör jag ta hänsyn till?
- Se Checklista för säkerhet - Bästa metoder för utveckling för mer information.

Pekaktiverat eller klassiskt gränssnitt touch-enabled-vs-classic-ui

Innan du börjar diskutera hur du utvecklar komponenter måste du veta vilket gränssnitt författarna kommer att använda:

Pekaktiverat användargränssnitt
Standardanvändargränssnittet som introducerades i AEM 5.6.0 som en förhandsgranskning och utökades i 6.x. Det bygger på Adobe Marketing Cloud enhetliga användarupplevelse och använder de underliggande teknikerna i Coral UI och Granite-gränssnitt.
Klassiskt användargränssnitt
Användargränssnitt som bygger på ExtJS-teknik som introducerades med CQ 5.1.

Se Gränssnittet Recommendations för kunder för mer information.

Komponenter kan implementeras för att stödja det beröringsaktiverade användargränssnittet, det klassiska användargränssnittet eller båda. När du tittar på en standardinstans ser du även färdiga komponenter som ursprungligen designats för det klassiska användargränssnittet, det pekaktiverade användargränssnittet eller båda.

Därför ska vi ta upp grunderna för båda och hur de ska kännas igen på den här sidan.

NOTE

Adobe rekommenderar att du utnyttjar det pekaktiverade användargränssnittet för att dra nytta av den senaste tekniken. AEM kan göra migreringen enklare.

Innehållslogik och återgivningsmarkeringar content-logic-and-rendering-markup

Vi rekommenderar att koden som ansvarar för kod och återgivning hålls åtskild från koden som styr logiken som används för att markera komponentens innehåll.

Denna filosofi stöds av HTL, ett mallspråk som är avsiktligt begränsat för att säkerställa att ett verkligt programmeringsspråk används för att definiera den underliggande affärslogiken. Den här (valfria) logiken anropas från HTML med ett specifikt kommando. Den här mekanismen markerar koden som anropas för en viss vy och, om det behövs, tillåter specifik logik för olika vyer av samma komponent.

HTL vs JSP htl-vs-jsp

HTML är ett mallspråk för HTML som introducerades med AEM 6.0.

Diskussion om huruvida ska användas HTL eller JSP (Java Server Pages) när du utvecklar egna komponenter bör vara okomplicerat eftersom HTML nu är det rekommenderade skriptspråket för AEM.

Både HTML och JSP kan användas för att utveckla komponenter för både det klassiska och det beröringskänsliga användargränssnittet. Även om det finns en tendens att anta att HTML bara är för det beröringsaktiverade användargränssnittet och JSP för det klassiska användargränssnittet, är detta en missuppfattning och beror mer på timing. Användargränssnittet med pekfunktion och HTML integrerades i AEM under ungefär samma period. Eftersom HTML nu är det rekommenderade språket används det för nya komponenter, som ofta används för användargränssnittet med pekfunktioner.

NOTE

Undantagen är formulärfält för GRE UI Foundation (som används i dialogrutor). Dessa kräver fortfarande JSP.

Utveckla egna komponenter developing-your-own-components

Om du vill skapa egna komponenter för rätt användargränssnitt kan du läsa (efter att du har läst den här sidan):

Ett snabbt sätt att komma igång är att kopiera en befintlig komponent och sedan göra de ändringar du vill. Mer information om hur du skapar egna komponenter och lägger till dem i styckesystemet finns i:

Utveckla komponenter (fokuserat på användargränssnittet med pekskärm)

Flytta komponenter till publiceringsinstansen moving-components-to-the-publish-instance

Komponenterna som återger innehåll måste distribueras på samma AEM som innehållet. Därför måste alla komponenter som används för att skapa och återge sidor på författarinstansen distribueras på publiceringsinstansen. När de distribueras är komponenterna tillgängliga för återgivning av aktiverade sidor.

Använd följande verktyg för att flytta dina komponenter till publiceringsinstansen:

Använd pakethanteraren om du vill lägga till dina komponenter i ett paket och flytta dem till en annan AEM.
Använda verktyget Aktivera trädreplikering för att replikera komponenterna.

NOTE

Dessa mekanismer kan också användas för att överföra komponenten mellan andra instanser, t.ex. från din utveckling till din testinstans.

Komponenter som ska vara medvetna om från Start components-to-be-aware-of-from-the-start

Sida:
- AEM har page komponent ( cq:Page).
- Detta är en specifik typ av resurs som är viktig för innehållshantering.
  - En sida motsvarar en webbsida med innehåll för webbplatsen.
Styckesystem:
- Styckesystemet är en viktig del av en webbplats när det hanterar en lista med stycken. Den används för att hålla kvar och strukturera de enskilda komponenterna som innehåller det faktiska innehållet.
- Du kan skapa, flytta, kopiera och ta bort stycken i styckesystemet.
- Du kan också välja vilka komponenter som ska vara tillgängliga för användning i ett visst styckesystem.
- Det finns olika styckesystem tillgängliga i en standardinstans (till exempel parsys, [responsivegrid](/docs/experience-manager-64/sites-authoring/responsive-layout.md)).

Struktur structure

Strukturen i en AEM är kraftfull och flexibel, de viktigaste aspekterna är:

Resurstyp
Komponentdefinition
Egenskaper och underordnade noder för en komponent
Dialogrutor
Designdialogrutor
Komponenttillgänglighet
Komponenter och det innehåll de skapar

Resurstyp resource-type

Ett nyckelelement i strukturen är resurstypen.

Innehållsstrukturen deklarerar avsikter.
Resurstyp som implementerar dem.

Detta är en abstraktion som säkerställer att även när utseendet och känslan förändras över tid så stannar avsikten.

Komponentdefinition component-definition

Grundläggande om komponenter component-basics

Definitionen av en komponent kan delas upp enligt följande:

AEM baseras på Sling.
AEM finns (vanligtvis) under:
- HTML: /libs/wcm/foundation/components
- JSP: /libs/foundation/components
Projekt-/platsspecifika komponenter finns (vanligtvis) under:
- /apps/<myApp>/components
AEM standardkomponenter definieras som cq:Component och har de viktigaste elementen:
- jcr-egenskaper:
  
  En lista med jcr-egenskaper; de här är variabler och vissa kan vara valfria genom en komponentnods grundläggande struktur, dess egenskaper och undernoder definieras av cq:Component definition
- Resurser:
  
  Dessa definierar statiska element som används av komponenten.
- Skript:
Används för att implementera beteendet för den resulterande instansen av komponenten.
Rotnod:
- <mycomponent> (cq:Component) - Komponentens hierarkiska nod.
Viktiga egenskaper:
- jcr:title - Komponenttitel; används till exempel som en etikett när komponenten visas i komponentwebbläsaren eller i sidledaren.
- jcr:description - Beskrivning av komponenten. kan användas som muspekningstips i komponentens webbläsare eller i sidledaren.
- Klassiskt användargränssnitt:
  - icon.png - Ikon för den här komponenten.
  - thumbnail.png - Bild som visas om den här komponenten finns med i styckesystemet.
- Pekgränssnitt
  - Se avsnittet Komponentikon i Touch UI för mer information.
Vitala underordnade noder:
- cq:editConfig (cq:EditConfig) - Definierar komponentens redigeringsegenskaper och aktiverar komponenten så att den visas i komponentwebbläsaren eller i Spark.
  
  Obs! om komponenten har en dialogruta, visas den automatiskt i komponentwebbläsaren eller i sidosparken, även om cq:editConfig inte finns.
- cq:childEditConfig (cq:EditConfig) - Styr gränssnittsaspekter för författare för underordnade komponenter som inte definierar sina egna cq:editConfig.
- Pekaktiverat användargränssnitt:
  - cq:dialog ( nt:unstructured) - Dialog för den här komponenten. Definierar gränssnittet som tillåter användaren att konfigurera komponenten och/eller redigera innehåll.
  - cq:design_dialog ( nt:unstructured) - Designredigering för den här komponenten
- Klassiskt användargränssnitt:
  - dialog ( cq:Dialog) - Dialog för den här komponenten. Definierar gränssnittet som tillåter användaren att konfigurera komponenten och/eller redigera innehåll.
  - design_dialog ( cq:Dialog) - Designredigering för den här komponenten.

Komponentikon i Touch UI component-icon-in-touch-ui

Ikonen eller förkortningen för komponenten definieras via JCR-egenskaperna för komponenten när komponenten skapas av utvecklaren. Dessa egenskaper utvärderas i följande ordning och den första giltiga egenskapen som hittas används.

cq:icon - String-egenskap som pekar på en standardikon i Coral UI-bibliotek som visas i komponentwebbläsaren
- Använd värdet för HTML-attributet för ikonen Koral.
abbreviation - String-egenskap för att anpassa förkortningen av komponentnamnet i komponentwebbläsaren
- Förkortningen ska vara begränsad till två tecken.
- Om du anger en tom sträng byggs förkortningen av de två första tecknen i jcr:title -egenskap.
  - Exempel:"Im" för"Bild"
  - Den lokaliserade titeln används för att skapa förkortningen.
- Förkortningen översätts bara om komponenten har en abbreviation_commentI18n -egenskapen, som sedan används som översättningstips.
cq:icon.png eller cq:icon.svg - Ikon för den här komponenten, som visas i komponentwebbläsaren
- 20 x 20 pixlar är storleken på ikonerna för standardkomponenter.
  - Storleken på större ikoner kommer att minskas (klientsidan).
- Den rekommenderade färgen är rgb(112, 112, 112) > #707070
- Bakgrunden för standardkomponentikoner är genomskinlig.
- Endast .png och .svg filer stöds.
- Om du importerar från filsystemet via plugin-programmet Eclipse måste filnamnen escape-konverteras som _cq_icon.png eller _cq_icon.svg till exempel.
- .png tar över sitt prejudikat .svg om båda finns

Om ingen av ovanstående egenskaper ( cq:icon, abbreviation, cq:icon.png eller cq:icon.svg) finns på komponenten:

Systemet söker efter samma egenskaper i de överordnade komponenterna efter sling:resourceSuperType -egenskap.
Om inget eller en tom förkortning hittas på den överordnade komponentnivån, kommer systemet att skapa förkortningen från de första bokstäverna i jcr:title den aktuella komponentens egenskap.

Om du vill avbryta arvet av ikoner från superkomponenter anger du ett tomt värde abbreviation -egenskapen för komponenten återställs till standardbeteendet.

The Komponentkonsol visar hur ikonen för en viss komponent definieras.

Exempel på SVG-ikon svg-icon-example

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "https://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="Layer_1" xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" x="0px" y="0px"
     width="20px" height="20px" viewBox="0 0 20 20" enable-background="new 0 0 20 20" xml:space="preserve">
    <ellipse cx="5" cy="5" rx="3" ry="3" fill="#707070"/>
    <ellipse cx="15" cy="5" rx="4" ry="4" fill="#707070"/>
    <ellipse cx="5" cy="15" rx="5" ry="5" fill="#707070"/>
    <ellipse cx="15" cy="15" rx="4" ry="4" fill="#707070"/>
</svg>

Egenskaper och underordnade noder för en komponent properties-and-child-nodes-of-a-component

Många av de noder/egenskaper som behövs för att definiera en komponent är gemensamma för båda gränssnitten, men skillnaderna är fortfarande oberoende så att komponenten kan fungera i båda miljöerna.

En komponent är en nod av typen cq:Component och har följande egenskaper och underordnade noder:

Namn

Typ

Beskrivning

cq:Component

Aktuell komponent. En komponent är av nodtyp cq:Component.

componentGroup

String

Grupp under vilken komponenten kan väljas i komponentwebbläsaren (beröringsaktiverat användargränssnitt) eller Sidekick (klassiskt användargränssnitt).
Värdet för .hidden används för komponenter som inte är tillgängliga för val från gränssnittet, t.ex. det faktiska styckesystemet.

cq:isContainer

Boolean

Anger om komponenten är en behållarkomponent och därför kan innehålla andra komponenter, till exempel ett styckesystem.

cq:dialog

nt:unstructured

Definition av redigeringsdialogrutan för det beröringsaktiverade användargränssnittet.

dialog

cq:Dialog

Definition av redigeringsdialogrutan för det klassiska användargränssnittet.

cq:design_dialog

nt:unstructured

Definition av designdialogrutan för det beröringskänsliga användargränssnittet.

design_dialog

cq:Dialog

Definition av designdialogrutan för det klassiska användargränssnittet.

dialogPath

String

Sökväg till en dialogruta som täcker fallet när komponenten inte har någon dialognod.

cq:cellName

String

Om den anges används den här egenskapen som cell-ID. Mer information finns i kunskapsbasartikeln Hur skapas ID:n för Design Cell?.

cq:childEditConfig

cq:EditConfig

När komponenten är en behållare, t.ex. ett styckesystem, styr detta redigeringskonfigurationen för de underordnade noderna.

cq:editConfig

cq:EditConfig

Redigera komponentens konfiguration.

cq:htmlTag

nt:unstructured

Returnerar ytterligare taggattribut som läggs till i den omgivande html-taggen. Möjliggör tillägg av attribut till de automatiskt genererade diven.

cq:noDecoration

Boolean

Om true återges inte komponenten med automatiskt genererade div- och css-klasser.

cq:template

nt:unstructured

Om den hittas används den här noden som en innehållsmall när komponenten läggs till från komponentwebbläsaren eller Sidekick.

cq:templatePath

String

Sökväg till en nod som ska användas som innehållsmall när komponenten läggs till från komponentwebbläsaren eller Sidekick. Detta måste vara en absolut sökväg, inte relativ till komponentnoden.
Om du inte vill återanvända innehåll som redan finns på en annan plats krävs inte detta och cq:template är tillräckligt (se nedan).

jcr:created

Date

Datum då komponenten skapades.

jcr:description

String

Beskrivning av komponenten.

jcr:title

String

Komponentens namn.

sling:resourceSuperType

String

När den är inställd ärver komponenten från den här komponenten.

virtual

sling:Folder

Gör att virtuella komponenter kan skapas. Titta på kontaktkomponenten på:
/libs/foundation/components/profile/form/contact

<breadcrumb.jsp>

nt:file

Skriptfil.

icon.png

nt:file

Ikonen för komponenten visas bredvid titeln i Sidespark.

thumbnail.png

nt:file

Valfri miniatyrbild som visas när komponenten dras på plats från Sidekick.

Om vi tittar på Text kan vi se följande element (båda versionerna):

HTL ( /libs/wcm/foundation/components/text)
JSP ( /libs/foundation/components/text)

Egenskaper av särskilt intresse är:

jcr:title - komponentens titel, den kan användas för att identifiera komponenten, till exempel visas den i komponentlistan i komponentwebbläsaren eller i sidledaren
jcr:description - beskrivning av komponenten, kan användas som muspekningstips i komponentlistan i sidosparken
sling:resourceSuperType: detta anger arvets sökväg när en komponent utökas (genom att åsidosätta en definition)

Underordnade noder av särskilt intresse är:

cq:editConfig ( cq:EditConfig) - detta styr visuella aspekter, den kan till exempel definiera utseendet på en stapel eller widget, eller lägga till anpassade kontroller
cq:childEditConfig ( cq:EditConfig) - detta styr de visuella aspekterna för underordnade komponenter som inte har egna definitioner
Pekaktiverat användargränssnitt:
- cq:dialog ( nt:unstructured) - definierar dialogrutan för redigering av innehåll i den här komponenten
- cq:design_dialog ( nt:unstructured) - anger designredigeringsalternativen för den här komponenten
Klassiskt användargränssnitt:
- dialog ( cq:Dialog) - definierar dialogrutan för redigering av innehåll i den här komponenten (specifik för det klassiska användargränssnittet)
- design_dialog ( cq:Dialog) - anger designredigeringsalternativen för den här komponenten
- icon.png - grafikfil som ska användas som ikon för komponenten i Sidekick
- thumbnail.png - grafikfil som ska användas som miniatyrbild för komponenten när den dras från Sidesparken

Dialogrutor dialogs

Dialogrutor är ett nyckelelement i komponenten eftersom de tillhandahåller ett gränssnitt där författare kan konfigurera och ange indata för den komponenten.

Beroende på komponentens komplexitet kan din dialogruta behöva en eller flera flikar för att hålla dialogrutan kort och sortera indatafälten.

Dialogrutedefinitioner är specifika för användargränssnittet:

NOTE

Av kompatibilitetsskäl kan det beröringsaktiverade användargränssnittet använda definitionen för en klassisk användargränssnittsdialogruta när ingen dialogruta har definierats för det beröringsaktiverade användargränssnittet.
The AEM finns även för att hjälpa dig att utöka/konvertera komponenter som bara har dialogrutor definierade för det klassiska användargränssnittet.

Pekaktiverat användargränssnitt
- cq:dialog ( nt:unstructured) noder:
  - definiera dialogrutan för redigering av innehåll i den här komponenten
  - specifikt för det pekaktiverade användargränssnittet
  - definieras med gränssnittskomponenter i Granite
  - har en egenskap sling:resourceType, som standard för Sling-innehållsstruktur
  - kan ha en egenskap helpPath för att definiera den sammanhangsberoende hjälpresursen (absolut eller relativ sökväg) som öppnas när hjälpikonen (? ) är markerat.
    - För körklara komponenter refererar detta ofta till en sida i dokumentationen.
    - Om nej helpPath anges visas standardwebbadressen (dokumentationsöversiktssidan).
I dialogrutan definieras enskilda fält:
Klassiskt användargränssnitt
- dialog ( cq:Dialog) noder
  - definiera dialogrutan för redigering av innehåll i den här komponenten
  - specifikt för det klassiska användargränssnittet
  - definieras med ExtJS-widgetar
  - har en egenskap xtype, som refererar till ExtJS
  - kan ha en egenskap helpPath för att definiera den sammanhangsberoende hjälpresursen (absolut eller relativ sökväg) som nås när Hjälp är markerad.
    - För körklara komponenter refererar detta ofta till en sida i dokumentationen.
    - Om nej helpPath anges visas standardwebbadressen (dokumentationsöversiktssidan).
I dialogrutan definieras enskilda fält:

I en klassisk dialogruta:
- du kan skapa dialogrutan som cq:Dialogsom ger en enda flik, som i textkomponenten, eller om du behöver flera flikar, som med textimagekomponenten, kan dialogrutan definieras som cq:TabPanel.
- a cq:WidgetCollection ( items) används som bas för båda inmatningsfälten ( cq:Widget) eller fler tabbar ( cq:Widget). Den här hierarkin kan utökas.

Designdialogrutor design-dialogs

Designdialogrutor påminner mycket om dialogrutorna som används för att redigera och konfigurera innehåll, men de tillhandahåller ett gränssnitt där författare kan konfigurera och tillhandahålla designinformation för den komponenten.

Designdialogrutor är tillgängliga i designläge, även om de inte behövs för alla komponenter, t.ex. Titel och Bild båda har designdialogrutor, men Text inte.

Designdialogrutan för styckesystemet (t.ex. parsys) är ett specialfall eftersom den gör det möjligt för användaren att välja specifika andra komponenter (från komponentwebbläsaren eller sidosparken) på sidan.

Lägga till komponenten i styckesystemet adding-your-component-to-the-paragraph-system

När en komponent har definierats måste den göras tillgänglig för användning. Om du vill göra en komponent tillgänglig för användning i ett styckesystem kan du antingen:

Öppna Designläge för en sida och aktivera den nödvändiga komponenten.
Lägg till de nödvändiga komponenterna i components egenskapen för malldefinitionen under:

/etc/designs/<*yourProject*>/jcr:content/<*yourTemplate*>/par

Se till exempel:

/etc/designs/geometrixx/jcr:content/contentpage/par

Komponenter och det innehåll de skapar components-and-the-content-they-create

Om vi skapar och konfigurerar en instans av Titel på sidan: <content-path>/Prototype.html

Pekaktiverat användargränssnitt
Klassiskt användargränssnitt

Sedan kan vi se strukturen för det innehåll som skapas i databasen:

screen_shot_2012-02-13at61405pm

Om du tittar på den faktiska texten för en Titel:

definitionen (för båda användargränssnitten) har egenskapen name= ./jcr:title
- /libs/foundation/components/title/cq:dialog/content/items/column/items/title
- /libs/foundation/components/title/dialog/items/title
i innehållet genererar detta egenskapen jcr:title som innehåller författarens innehåll.

De definierade egenskaperna är beroende av de enskilda definitionerna. Även om de kan vara mer komplexa än tidigare följer de fortfarande samma grundläggande principer.

Komponenthierarki och arv component-hierarchy-and-inheritance

Komponenterna i AEM har tre olika hierarkier:

Hierarki för resurstyp

Detta används för att utöka komponenter med hjälp av egenskapen sling:resourceSuperType. Detta gör att komponenten kan ärva. En textkomponent ärver till exempel olika attribut från standardkomponenten.
- skript (lösta av Sling)
- dialogrutor
- beskrivningar (inklusive miniatyrbilder, ikoner etc.)
Behållarhierarki

Detta används för att fylla i konfigurationsinställningar till den underordnade komponenten och används oftast i ett parsyscenario.

Till exempel kan konfigurationsinställningar för redigeringsfältsknappar, kontrolluppsättningens layout (redigeringsfält, överrullning) och dialogrutans layout (textbunden, flytande) definieras för den överordnade komponenten och spridas till de underordnade komponenterna.

Konfigurationsinställningar (för redigeringsfunktioner) i cq:editConfig och cq:childEditConfig är spridda.
Inkludera hierarki

Detta anges vid körning av sekvensen includes.

Denna hierarki används av Designer, som i sin tur fungerar som bas för olika designaspekter av återgivningen. inklusive layoutinformation, CSS-information, tillgängliga komponenter på en parsys med flera.

Redigera beteende edit-behavior

I det här avsnittet beskrivs hur du konfigurerar redigeringsbeteendet för en komponent. Detta inkluderar attribut som åtgärder som är tillgängliga för komponenten, egenskaper för infogningsredigeraren och avlyssnare som relaterar till händelser för komponenten.

Konfigurationen är gemensam för det beröringsaktiverade och klassiska användargränssnittet, men med vissa specifika skillnader.

En komponents redigeringsbeteende konfigureras genom att 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. Följande egenskaper och underordnade noder är tillgängliga:

cq:editConfig nodegenskaper:
- cq:actions ( String array): definierar de åtgärder som kan utföras på komponenten.
- cq:layout ( String): : definierar hur komponenten redigeras i det klassiska användargränssnittet.
- cq:dialogMode ( String): definierar hur komponentdialogrutan öppnas i det klassiska användargränssnittet
  - I det beröringsaktiverade användargränssnittet flyter dialogrutorna alltid i skrivbordsläge och öppnas automatiskt som helskärm i mobilen.
- cq:emptyText ( String): definierar text som visas utan visuellt innehåll.
- cq:inherit ( Boolean): definierar om saknade värden ärvs från komponenten som den ärver från.
- dialogLayout (String): definierar hur dialogrutan ska öppnas.
cq:editConfig underordnade noder:
- cq:dropTargets (nodtyp nt:unstructured): definierar en lista med släppmål som kan acceptera en släppning från en resurs i innehållshanteraren
  - Det finns bara flera släppmål i det klassiska användargränssnittet.
  - I det beröringsaktiverade användargränssnittet tillåts en enda släppåtgärd.
- cq:actionConfigs (nodtyp nt:unstructured): definierar en lista med nya åtgärder som läggs till i cq:actions-listan.
- cq:formParameters (nodtyp nt:unstructured): definierar ytterligare parametrar som läggs till i dialogformuläret.
- cq:inplaceEditing (nodtyp cq:InplaceEditingConfig): definierar en redigeringskonfiguration på plats för komponenten.
- cq:listeners (nodtyp cq:EditListenersConfig): definierar vad som händer före eller efter att en åtgärd inträffar på komponenten.

NOTE

På den här sidan representeras en nod (egenskaper och underordnade noder) som XML, vilket visas i följande exempel.

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[edit]"
    cq:dialogMode="floating"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig">
    <cq:listeners
        jcr:primaryType="cq:EditListenersConfig"
        afteredit="REFRESH_PAGE"/>
</jcr:root>

Det finns många befintliga konfigurationer i databasen. Du kan enkelt söka efter specifika egenskaper eller underordnade noder:

Leta efter en egenskap i cq:editConfig nod, t.ex. cq:actionskan du använda frågeverktyget i CRXDE Lite och söka med följande XPath-frågesträng:

//element(cq:editConfig, cq:EditConfig)[@cq:actions]
Leta efter en underordnad nod till cq:editConfig, t.ex. kan du söka efter cq:dropTargets, som är av typen cq:DropTargetConfig; Du kan använda frågeverktyget i  CRXDE Lite och söka med följande XPath-frågesträng:

//element(cq:dropTargets, cq:DropTargetConfig)

Komponentplatshållare component-placeholders

Komponenter måste alltid återge viss HTML som är synlig för författaren, även när komponenten inte har något innehåll. I annat fall försvinner det visuellt från redigerarens gränssnitt, vilket gör det tekniskt möjligt men osynligt på sidan och i redigeraren. I så fall kan författarna inte markera och interagera med den tomma komponenten.

Därför bör komponenter återge en platshållare så länge de inte återger några synliga utdata när sidan återges i sidredigeraren (när WCM-läget är edit eller preview).
Den typiska HTML-koden för en platshållare är följande:

<div class="cq-placeholder" data-emptytext="Component Name"></div>

Det typiska HTL-skriptet som återger platshållaren HTML är följande:

<div class="cq-placeholder" data-emptytext="${component.properties.jcr:title}"
     data-sly-test="${(wcmmode.edit || wcmmode.preview) && isEmpty}"></div>

I föregående exempel isEmpty är en variabel som bara är true när komponenten inte har något innehåll och som är osynlig för författaren.

För att undvika upprepningar rekommenderar Adobe att komponentimplementerare använder en HTML-mall för dessa platshållare. som den som finns i Core Components.

Mallen i den föregående länken används sedan med följande rad i HTML:

<sly data-sly-use.template="core/wcm/components/commons/v1/templates.html"
     data-sly-call="${template.placeholder @ isEmpty=!model.text}"></sly>

I föregående exempel model.text är variabeln som är true bara när innehållet har innehåll och är synlig.

Ett exempel på hur den här mallen används finns i Core Components, som i komponenten Title.

Konfigurera med cq:EditConfig-egenskaper configuring-with-cq-editconfig-properties

cq:åtgärder cq-actions

The cq:actions egenskap ( String array) definierar en eller flera åtgärder som kan utföras på komponenten. Följande värden är tillgängliga för konfiguration:

Egenskapsvärde

Beskrivning

text:<some text>

Visar det statiska textvärdet <some text="">
Endast synligt i klassiskt användargränssnitt. Det beröringskänsliga användargränssnittet visar inte åtgärder på en sammanhangsberoende meny, så detta är inte tillämpligt.

Lägger till ett mellanrum.
Endast synligt i klassiskt användargränssnitt. Det beröringskänsliga användargränssnittet visar inte åtgärder på en sammanhangsberoende meny, så detta är inte tillämpligt.

edit

Lägger till en knapp för att redigera komponenten.

editannotate

Lägger till en knapp för att redigera komponenten samt för att tillåta anteckningar.

delete

Lägger till en knapp för att ta bort komponenten

insert

Lägger till en knapp för att infoga en ny komponent före den aktuella

copymove

Lägger till en knapp för att kopiera och klippa ut komponenten.

I följande konfiguration läggs en redigeringsknapp, ett mellanrum, en borttagningsknapp och en infogningsknapp till i komponentens redigeringsfält:

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[edit,-,delete,insert]"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig"/>

Följande konfiguration lägger till texten"Ärvda konfigurationer från basramverket" i komponentens redigeringsfält:

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[text:Inherited Configurations from Base Framework]"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig"/>

cq:layout (endast Classic UI) cq-layout-classic-ui-only

The cq:layout egenskap ( String) definierar hur komponenten kan redigeras i det klassiska användargränssnittet. Följande värden är tillgängliga:

Egenskapsvärde

Beskrivning

rollover

Standardvärde. Komponentutgåvan är tillgänglig"när du för muspekaren över" genom att klicka och/eller snabbmenyn.
Observera att motsvarande objekt på klientsidan är: CQ.wcm.EditRollover.

editbar

Komponentutgåvan är tillgänglig via ett verktygsfält.
Observera att motsvarande objekt på klientsidan är: CQ.wcm.EditBar.

auto

Koden lämnas kvar på klientsidan.

NOTE

Begreppen överrullning och redigeringsfält kan inte användas i det beröringsaktiverade gränssnittet.

Följande konfiguration lägger till en redigeringsknapp i komponentens redigeringsfält:

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[edit]"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig">
</jcr:root>

cq:dialogMode (endast Classic UI) cq-dialogmode-classic-ui-only

Komponenten kan länkas till en redigeringsdialogruta. The cq:dialogMode egenskap ( String) definierar hur komponentdialogen ska öppnas i det klassiska användargränssnittet. Följande värden är tillgängliga:

Egenskapsvärde

Beskrivning

floating

Dialogrutan är flytande.

inline

(standardvärde). Dialogrutan är förankrad över komponenten.

auto

Om komponentbredden är mindre än klientsidan CQ.themes.wcm.EditBase.INLINE_MINIMUM_WIDTH värdet, dialogrutan är flytande, annars är den textbunden.

NOTE

I det beröringsaktiverade användargränssnittet flyter dialogrutorna alltid i skrivbordsläge och öppnas automatiskt som helskärm i mobilen.

I följande konfiguration definieras ett redigeringsfält med en redigeringsknapp och en flytande dialogruta:

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[edit]"
    cq:dialogMode="floating"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig">
</jcr:root>

cq:emptyText cq-emptytext

The cq:emptyText egenskap ( String) definierar text som visas utan visuellt innehåll. Standardvärdet är: Drag components or assets here.

cq:inherit cq-inherit

The cq:inherit egenskap ( boolean) definierar om saknade värden ärvs från den komponent som de ärver från. Standardvärdet är false.

dialogLayout dialoglayout

The dialogLayout -egenskapen definierar hur en dialogruta ska öppnas som standard.

Värdet för fullscreen öppnar dialogrutan i helskärmsläge.
Ett tomt värde eller en frånvaro av egenskapen öppnar normalt dialogrutan.
Observera att användaren alltid kan växla till helskärmsläge i dialogrutan.
Gäller inte det klassiska användargränssnittet.

Konfigurera med cq:EditConfig-underordnade noder configuring-with-cq-editconfig-child-nodes

cq:dropTargets cq-droptargets

The cq:dropTargets nod (nodtyp) nt:unstructured) definierar en lista med släppmål som kan acceptera en släppning från en resurs som dras från innehållssökaren. Det fungerar som en samling noder av typen cq:DropTargetConfig.

NOTE

Det finns bara flera släppmål i det klassiska användargränssnittet.

I det beröringsaktiverade användargränssnittet används bara det första målet.

Varje underordnad nod av typen cq:DropTargetConfig definierar ett släppmål i komponenten. Nodnamnet är viktigt eftersom det måste användas i JSP enligt följande för att generera CSS-klassnamnet som tilldelats DOM-elementet som är det gällande släppmålet:

<drop target css class> = <drag and drop prefix> +
 <node name of the drop target in the edit configuration>

The <*drag and drop prefix*> definieras av Java-egenskapen:

com.day.cq.wcm.api.components.DropTarget.CSS_CLASS_PREFIX.

Klassnamnet definieras så här i JSP:n för komponenten Download
( /libs/foundation/components/download/download.jsp), där file är nodnamnet för släppmålet i redigeringskonfigurationen för komponenten Download:

String ddClassName = DropTarget.CSS_CLASS_PREFIX + "file";

Noden av typen cq:DropTargetConfig måste ha följande egenskaper:

Egenskapsnamn

Egenskapsvärde

accept

Regex används på resursens Mime-typ för att validera om släppning är tillåten.

groups

Matris med släppmålgrupper. Varje grupp måste matcha den grupptyp som definieras i tillägget för innehållssökning och som är kopplad till resurserna.

propertyName

Namnet på den egenskap som ska uppdateras efter en giltig släppning.

Följande konfiguration hämtas från komponenten Download. Den aktiverar alla resurser (mime-typen kan vara vilken sträng som helst) från media grupp som ska tas bort från innehållssökaren i komponenten. Komponentegenskapen efter släppningen fileReference uppdateras:

    <cq:dropTargets jcr:primaryType="nt:unstructured">
        <file
            jcr:primaryType="cq:DropTargetConfig"
            accept="[.*]"
            groups="[media]"
            propertyName="./fileReference"/>
    </cq:dropTargets>

cq:actionConfigs (endast Classic UI) cq-actionconfigs-classic-ui-only

The cq:actionConfigs nod (nodtyp) nt:unstructured) definierar en lista med nya åtgärder som läggs till i listan som definieras av cq:actions -egenskap. Varje underordnad nod till cq:actionConfigs definierar en ny åtgärd genom att definiera en widget.

I följande exempelkonfiguration definieras en ny knapp (med en avgränsare för det klassiska användargränssnittet):

en avgränsare, definierad av xtype tbseparator;
- Detta används endast av det klassiska användargränssnittet.
- Den här definitionen ignoreras av det beröringsaktiverade användargränssnittet eftersom xtypes ignoreras (och separatorer är inte nödvändiga eftersom åtgärdsverktygsfältet konstrueras på ett annat sätt i det beröringsaktiverade användargränssnittet).
en knapp med namnet Hantera kommentarer som kör hanterarfunktionen CQ_collab_forum_openCollabAdmin().

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:nt="https://www.jcp.org/jcr/nt/1.0"
    cq:actions="[EDIT,COPYMOVE,DELETE,INSERT]"
    jcr:primaryType="cq:EditConfig">
    <cq:actionConfigs jcr:primaryType="nt:unstructured">
        <separator0
            jcr:primaryType="nt:unstructured"
            xtype="tbseparator"/>
        <manage
            jcr:primaryType="nt:unstructured"
            handler="function(){CQ_collab_forum_openCollabAdmin();}"
            text="Manage comments"/>
    </cq:actionConfigs>
</jcr:root>

NOTE

Se Lägg till ny åtgärd i ett komponentverktygsfält som ett exempel för det pekaktiverade användargränssnittet.

cq:formParameters cq-formparameters

The cq:formParameters nod (nodtyp) nt:unstructured) definierar ytterligare parametrar som läggs till i dialogformuläret. Varje egenskap mappas till en formulärparameter.

Följande konfiguration lägger till en parameter med namnet name, anges med värdet photos/primary till dialogrutan:

    <cq:formParameters
        jcr:primaryType="nt:unstructured"
        name="photos/primary"/>

cq:inplaceEditing cq-inplaceediting

The cq:inplaceEditing nod (nodtyp) cq:InplaceEditingConfig) definierar en redigeringskonfiguration på plats för komponenten. Den kan ha följande egenskaper:

Egenskapsnamn

Egenskapsvärde

active

(boolean) True to enable the inplace editing of the component.

configPath

(String) Sökväg till redigerarkonfigurationen. Konfigurationen kan anges av en konfigurationsnod.

editorType

(String) Typ av redigerare. De tillgängliga typerna är:

plaintext: som ska användas för innehåll som inte är HTML.
titel: är en förbättrad textredigerare som konverterar grafiska titlar till klartext innan redigeringen börjar. Används av Geometrixx titelkomponent.
text: som ska användas för HTML (använder textredigeraren).

Följande konfiguration aktiverar redigering på plats av komponenten och definierar plaintext som redigeringstyp:

    <cq:inplaceEditing
        jcr:primaryType="cq:InplaceEditingConfig"
        active="{Boolean}true"
        editorType="plaintext"/>

cq:avlyssnare cq-listeners

The cq:listeners nod (nodtyp) cq:EditListenersConfig) definierar vad som händer före eller efter en åtgärd på komponenten. I följande tabell definieras dess möjliga egenskaper.

Egenskapsnamn

Egenskapsvärde

Standardvärde

(Endast Classic UI)

beforedelete

Hanteraren aktiveras innan komponenten tas bort.

beforeedit

Hanteraren aktiveras innan komponenten redigeras.

beforecopy

Hanteraren aktiveras innan komponenten kopieras.

beforemove

Hanteraren aktiveras innan komponenten flyttas.

beforeinsert

Hanteraren aktiveras innan komponenten infogas.
Endast för det beröringskänsliga användargränssnittet.

beforechildinsert

Hanteraren aktiveras innan komponenten infogas i en annan komponent (endast behållare).

afterdelete

Hanteraren aktiveras när komponenten har tagits bort.

REFRESH_SELF

afteredit

Hanteraren aktiveras när komponenten har redigerats.

REFRESH_SELF

aftercopy

Hanteraren aktiveras när komponenten har kopierats.

REFRESH_SELF

afterinsert

Hanteraren aktiveras när komponenten har infogats.

REFRESH_INSERTED

aftermove

Hanteraren aktiveras när komponenten har flyttats.

REFRESH_SELFMOVED

afterchildinsert

Hanteraren aktiveras när komponenten har infogats i en annan komponent (endast behållare).

NOTE

The REFRESH_INSERTED och REFRESH_SELFMOVED -hanterare är bara tillgängliga i det klassiska användargränssnittet.

NOTE

Standardvärden för avlyssnarna anges bara i det klassiska användargränssnittet.

NOTE

När det gäller kapslade komponenter finns det vissa begränsningar för åtgärder som definierats som egenskaper för cq:listeners nod:

För kapslade komponenter är värdena för följande egenskaper måste be REFRESH_PAGE:
- aftermove
- aftercopy

Händelsehanteraren kan implementeras med en anpassad implementering. Till exempel project.customerAction är en statisk metod):

afteredit = "project.customerAction"

Följande exempel motsvarar REFRESH_INSERTED konfiguration:

afterinsert="function(path, definition) { this.refreshCreated(path, definition); }"

NOTE

Om du vill se vilka parametrar som kan användas i hanterarna för det klassiska användargränssnittet läser du i before<action> och after<action> händelseavsnittet i CQ.wcm.EditBar och CQ.wcm.EditRollover widgetdokumentation.

Med följande konfiguration uppdateras sidan när komponenten har tagits bort, redigerats, infogats eller flyttats:

    <cq:listeners
        jcr:primaryType="cq:EditListenersConfig"
        afterdelete="REFRESH_PAGE"
        afteredit="REFRESH_PAGE"
        afterinsert="REFRESH_PAGE"
        afterMove="REFRESH_PAGE"/>

recommendation-more-help

2315f3f5-cb4a-4530-9999-30c8319c520e