Klassisk til berøringsgrensesnittoverføring for AEM: Flere tips fra Opplev

(Liubou Masiuk) (17. okt. 2019)

I vårt forrige (innlegg om Classic til TouchUI-migrering) beskrev vi vår generelle «Hybrid Mode» -tilnærming til å migrere et helt Classic UI-komponentbibliotek til Touch UI ved hjelp av AEMs kompatibilitetsmodus. I innlegget henviste vi til noen «quirks» som vi opplevde. I dette nye innlegget går vi inn i mye mer detaljer om disse særegenheter og hvordan vi skal håndtere noen av disse særegenheter.

Selv om Hybrid Mode er ekstremt nyttig, har den noen begrensninger som kan forhindre utviklingsteamet i å vedta TouchUI uten ekstra innsats på store prosjekter. Her er noen av problemene vi møtte, og løsningene vårt utviklingsteam fant på.

Forfatteren kan ikke dra & slippe bilder mens han redigerer en komponent

ClassicUI Widgets-biblioteket gir en SmartImage-komponent for opplasting og behandling av bilder. Bildemateriell kan som standard lastes opp på to forskjellige måter:

  • Fra filsystemet
  • Fra DAM (Digital Asset Manager) ved å dra bildet fra sideinnholdsfinner panel på venstre side
DAM Assets panel (TouchUI interface)
DAM Assets panel (TouchUI-grensesnitt)

La oss dykke dypt inn i de tekniske detaljene i TouchUI-implementeringen. Kompatibilitetsmodus gjengir en ClassicUI-dialog i en iframe. Av en eller annen grunn har den kompatible modusen ingen logikk for å spore dra & slippe hendelser utenom boksen. Dette begrenser forfattere fra å dra bilder ut av Assets-panelet (slik de er vant til å gjøre det i ClassicUI-opplevelsen). Dette betyr at de ikke har en måte å plassere bildet i komponenten. Når et bildefelt er påkrevd, har forfatteren ikke muligheten til å fullføre komponentkonfigurasjonen på grunn av et tomt obligatorisk felt.

Løsning

For å løse dette problemet bestemte vi oss for å utvide Standard SmartImage-komponenten for å gjengi et banefelt i tillegg til eksisterende funksjonalitet. Som et resultat får forfatteren muligheten til å velge et bilde ved hjelp av stifelt, og bildet vises inne i SmartImage-området for å forhåndsvise og / eller endre bildet om nødvendig. For ikke-eksisterende baner (eller ikke-bildebaner) er feltet uthevet som ugyldig.

Nødvendig bildeområde inne i komponenten
Nødvendig bildeområde inne i komponenten
  1. Registrer originalen htmlsamartimage xtype på nytt med en iboende tilpasset en som utvider originalen CQ HtmlSmartImage-widget. Ved initialiseringen av den nye widgeten legger vi til en ekstra PathField-widget i komponentbeholderne. I tillegg gir vi små oppdateringer til standard widgetoppsett som er en vanlig UI-oppdatering for ExtJS-baserte brukergrensesnitt.
  2. Bindende kontroller (PathFields) i alle HTMLSmartImages. Først og fremst forbereder vi hjelpere ved å lage metoder for å hente og sette verdier fra PathPicker og de samme metodene for den originale komponenten. Det første paret er setValue og getValue of PathField, som er den enkle delen. Den vanskelige delen er å håndtere den opprinnelige komponentverdien. HTMLSmartImage lagrer ikke verdien i en tilgjengelig tilstand.

For å få den nåværende bildestien gjøres det enkelt ved å bruke metoden this.fileReferenceField.getValue (). Men for å sette verdien til den opprinnelige widgeten, må vi etterligne en bilderesursfall på komponenten. Vi kan klare det på følgende måte:

Nå når vi har alle verditilbehør, må vi vet når originalen og når Pathfield-verdien endres. For å spore Pathfield-endringer kan vi bruke en uskarphet -hendelse. For den originale widgeten er imagestate hendelsen den mest passende. Vi må spore to typer endringer i bildestatus: originalremoved og originalavailable, slik at lytteren kan være følgende:

Nå er den klar for binding. For å beholde valideringsmekanismen i den nye implementeringen, overstyrer vi den opprinnelige valideringslogikken for den innebygde pathfield-forekomsten.

Alle stillasfeltdialoger er deaktivert

AEM Stillasmodus lar en forfatter enkelt lage sider basert på en bestemt stillasformstruktur. Stillas er ekstremt nyttige for å lage veldefinert strukturert innhold (f.eks. Artikler, blogginnlegg).

I hybridmodus er alle felt for stillasformer deaktivert, noe som betyr at de ikke kan redigeres.

Eksempel på stillasform
Eksempel på stillasform

Løsning

Inkludering av cq.security-biblioteket i sidens JSP løste problemet og stillasskjemaene begynte å fungere skikkelig.

Hybrid-dialogboksen lukkes uten å lagre data når du klikker utenfor dialogområdet

Alle komponentene redigeres i dialogboksen for komponentkonfigurasjon, som dukker opp i redigeringsmodus.

Redigere en komponent i AEM (TouchUI-grensesnitt)
Redigere en komponent i AEM (TouchUI-grensesnitt)

Det er en liten forskjell i brukeropplevelse i Hybrid- og TouchUI-dialoger:

  • Hvis en bruker klikker bort fra TouchUI-dialogen, skjer ingenting.
  • Hvis en bruker klikker seg bort fra hybrid dialogboksen, lukkes den uten å lagre angitte data.

Dette betyr at alle data som ikke er lagret er g å gå tapt i tilfelle et tilfeldig klikk utenfor komponenten! Unødvendig å si dette er ganske irriterende for forfattere.

Løsning

Heldigvis er løsningen ganske enkel. Opprinnelig er dialogbakgrunnen i «modal» modus. For å endre bakgrunnsmodus for dialog, må dialogens JSP-fil legges og dialogbakgrunnsmodus settes til “statisk” verdi.

Noen dialogfelt passer ikke til dialogvinduområdet

Som vi allerede har beskrevet tidligere, vises UI-dialoger i en iframe inne i TouchUI-dialogvinduet. Noen ganger passer ikke dette dialogvinduet til alt dynamisk innhold, og noen ganger forårsaker det et rart oppsett der ekstra rullefelt vises inne i dialogen.

Ekstra rulle element for komponenten i hybridmodus
Ekstra rulleelement for komponenten i hybridmodus

Løsning

For å overvinne denne ulempen legger vi over JSP-filen som inneholder alle konfigurasjonsinnstillinger for korrekt gjengivelse av dialoger i kompatibilitetsmodus. Denne JSP-filen er plassert i følgende under følgende bane:

apps/cq/gui/components/authoring/compat/components/dialog/dialog.jsp

Vi endrer vinduets bredde og høyde for å vurdere originalen dialogens dimensjoner, samt nettleserens vindusstørrelse.

Vi håndterer denne situasjonen via skript som faktisk gir bind mellom Touch UI (Coral) -innpakningen og innebygd klassisk dialog i iframe. Hendelsen “dialogwrapper-ready” + ns er nødvendig for det med forhåndsberegnet bredde og høyde som parametere for håndteringsfunksjonen. Det er også mulig å gjøre din egen beregning og deretter sette bredden og høyden til Coral Dialog-innholdet:

Noen komponenter kan ikke redigeres i TouchUI (enkelt)

Forfatteropplevelsen er et av de viktigste punktene du bør vurdere når du implementerer komponenter i AEM. Tenk deg en karusellkomponent som inneholder et antall lysbilder. I redigeringsmodus er det bedre å gjengi alle karusellbildene som en kolonne, slik at forfatteren enkelt kan omorganisere lysrekkefølgen og få tilgang til alle samtidig uten å bytte mellom lysbildene. Det er en viktig forskjell mellom ClassicUI og TouchUI:

  • I ClassicUI er forfatterelementene (f.eks. Redigeringslinjer) en del av markeringen som gjengis med komponenten i redigeringsmodus.
  • I TouchUI blir forfatterelementene gjengitt i et overlegg. Endelig komponentoppmerking gjengis i en iframe. Kombinasjonen av disse forholdene fører en forfatter til situasjonen når det ikke er mulig å samhandle med komponenten i redigeringsmodus i det hele tatt (f.eks. Klikke på knappene, bla gjennom lysbildene til en karusell).

Så vi møter tilfeller der et par komponenter i biblioteket vårt krever noe samhandling før brukeren kan starte redigeringsprosessen, men dette kan ikke lett oppnås i TouchUI.

Løsninger

Imidlertid er det et par fikser som kan betraktes som mulige løsninger:

  1. Det er en rask og enkel løsning som ikke krever noen anstrengelse: alle redigerbare komponenter finner du i Content Tree og det er et skiftenøkkelikon ved siden av hver av dem som åpner redigeringsdialogen.
Sideinnholdstre i TouchUI grensesnitt
Sideinnholdstre i TouchUI-grensesnitt

2. For komplekse komponenter med mange underkomponenter kan markeringen av komponenten i redigeringsmodus endres for å gjøre alle «skjulte» komponentområder åpne for forfatterens «øyne». Dette vil bety at alt er synlig og tilgjengelig i redigeringsmodus.

3. Som en best praksis gir Adobe en løsning for å støtte en slik forfatteropplevelsessak i AEM-kjernekomponenter . Karusellkomponent og Fanekomponent bruker alternativet Velg panel i verktøylinjen for komponenten for å omorganisere lysbildene og viser og endre elementet som nå er forhåndsvist.

Out-of-the-box-løsning for å nå innhold skjult fra forfatterskap
Out-of-the-box-løsning for å nå innhold skjult fra forfatterskap

Knappen «Lås opp side» fungerer ikke

Det er et standard AEM-alternativ å låse og låse opp siden for endringer. Mens vi validerte TouchUI-migreringsmetoden, fant vi en situasjon der forfatteren ikke kunne tilbakestille en låst side til sin opprinnelige tilstand. Heldigvis fungerer denne funksjonaliteten skikkelig via AEM Site Console.

Lås alternativ i TouchUI-grensesnitt

Et lignende problem er beskrevet her og her .

Løsning

Feilmeldingen i nettleserkonsollen sier at den «Kan ikke lese eiendom» delt «av udefinerte ”. Grunnårsaken ligger i et manglende klientbibliotek cq.shared.

Feilmelding når du arbeider med funksjonen
Feilmelding når du arbeider med funksjonen Lås / Lås opp

Inkludert av cq.shared bibliotek i sidens JSP-løsninger problemet og knappen «Lås opp side» begynner å fungere som forventet.

Forfattere: Volha Lunkova , Liubou Masiuk, Aliaksei Stsefanovich

Opprinnelig publisert på https://exadel.com 17. oktober 2019.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *