AEM: n perinteinen kosketuskäyttöliittymän siirto: Lisää vinkkejä Kokemus

(Liubou Masiuk) (17. lokakuuta 2019)

Edellisessä (postitse Classic – TouchUI-siirtoon) kuvailimme yleistä ”hybriditilaa” -lähestymistapaa täysin klassisen käyttöliittymäkomponenttikirjaston siirtämiseen Touch UI: hen AEM-yhteensopivuustila. Viestissä viittasimme joihinkin ”omituisuuksiin”, joita olemme kohdanneet. Tässä uudessa viestissä käsitellään paljon yksityiskohtaisemmin näitä oivalluksia ja kuinka käsitellä joitain näistä oivalluksista.

Vaikka hybriditila on erittäin hyödyllinen, sillä on joitain rajoituksia, jotka voivat estää kehitystiimiä omaksumasta TouchUI ilman lisätoimia suurissa projekteissa. Tässä on joitain kohtaamistamme ongelmista ja ratkaisuja, joita kehitystiimimme keksi.

Kirjoittaja ei voi vetää & pudottaa kuvia komponenttia muokatessasi

ClassicUI Widget-kirjasto tarjoaa SmartImage-komponentin kuvien lataamiseen ja käsittelyyn. Kuvaominaisuudet voidaan oletusarvoisesti ladata kahdella eri tavalla:

  • tiedostojärjestelmästä
  • DAM: sta (Digital Asset Manager) vetämällä kuvaa sivun sisällönhakijasta vasemmalla puolella oleva paneeli
DAM-resurssit-paneeli (TouchUI-käyttöliittymä)
DAM-omaisuus-paneeli (TouchUI-käyttöliittymä)

Sukelletaan syvälle TouchUI-toteutuksen teknisiin yksityiskohtiin. Yhteensopivuustila tekee ClassicUI-valintaikkunan iframe-kehyksen sisällä. Jostain syystä yhteensopivassa tilassa ei ole logiikkaa vetämisen & pudotustapahtumien seurantaan. Tämä rajoittaa tekijöitä vetämästä kuvia pois Omaisuus-paneelista (kuten he ovat tottuneet tekemään sen ClassicUI-kokemuksen sisällä). Tämä tarkoittaa, että heillä ei ole tapaa sijoittaa kuvaa komponenttiin. Lisäksi kun kuvakenttä vaaditaan, kirjoittajalla ei ole mahdollisuutta täydentää komponenttien kokoonpanoa tyhjän pakollisen kentän takia.

Ratkaisu

Tämän ongelman ratkaisemiseksi päätimme laajenna Standardi SmartImage -komponenttia siten, että se näyttää polun nykyisten toimintojen lisäksi. Tämän seurauksena kirjoittaja saa mahdollisuuden valita kuva polkukentän avulla ja kuva näkyy SmartImage-alueen sisällä esikatsella ja / tai muuttaa kuvaa tarvittaessa. Ei-olemassa oleville poluille (tai muille kuin poluille) kenttä on korostettu virheelliseksi.

Pakollinen kuva-alue komponentin sisällä
Pakollinen kuva-alue komponentin sisällä
  1. Rekisteröi alkuperäinen htmlsamartimage xtype omalla mukautetulla, joka laajentaa alkuperäistä CQ HtmlSmartImage -widget. Uuden widgetin alustamisen yhteydessä lisätään ylimääräinen PathField-widget komponenttikontteihin. Lisäksi tarjoamme vähän päivityksiä oletussovelluksen asettelulle, joka on yleinen käyttöliittymän päivitys ExtJS-pohjaisiin käyttöliittymiin.
  2. Sitomisen ohjaimet (PathFields) kaikissa HTMLSmartImagesissa. Ensinnäkin valmistelemme avustajia luomalla menetelmiä arvojen saamiseksi ja asettamiseksi PathPickeristä ja samoja menetelmiä alkuperäiselle komponentille. Ensimmäinen pari on PathFieldin setValue ja getValue, mikä on helppo osa. Hankala osa käsittelee alkuperäisen komponentin arvoa. HTMLSmartImage ei tallenna arvoa saavutettavissa olevaan tilaan.

Nykyisen kuvapolun saaminen on helppoa käyttämällä this.fileReferenceField.getValue () -menetelmää. Mutta alkuperäisen widgetin arvon asettamiseksi meidän on jäljiteltävä komponenttikuvaa kuvan resurssista. Voimme hallita sitä seuraavalla tavalla:

Nyt kun meillä on kaikki tarvitsemme lisäarvoa tietää, milloin alkuperäinen ja milloin Pathfield-arvo muuttuu. Pathfield-muutosten seuraamiseksi voimme käyttää epätarkkuutta. Alkuperäiselle widgetille sopivin on ”imagestate” -tapahtuma. Meidän on seurattava kahden tyyppisiä kuvatilan muutoksia: ”originalremoved” ja ”originalavailable”, joten kuuntelija voi olla seuraava:

Nyt se on valmis sitomaan. Vahvistusmekanismin säilyttämiseksi uudessa toteutuksessa ohitamme upotetun polkukenttä-ilmentymän alkuperäisen vahvistuslogiikan.

Kaikki rakennustelineiden valintaikkunat ovat pois käytöstä

AEM Rakennustila antaa tekijälle mahdollisuuden luoda sivuja helposti tietyn telineen lomakerakenteen perusteella. Rakennustelineistä on erittäin hyötyä hyvin määritellyn jäsennellyn sisällön (esim. Artikkeleiden, blogiviestien) luomisessa.

Hybriditilassa kaikki rakennustelineiden lomakekentät on poistettu käytöstä, mikä tarkoittaa, että niitä ei voi muokata.

Rakennustelineiden esimerkki
Rakennustelineiden esimerkki

Ratkaisu

cq.security-kirjaston sisällyttäminen sivun JSP: hen ratkaisi ongelman ja rakennustelineet alkoivat toimia oikein.

Hybridi-valintaikkuna sulkeutuu tallentamatta tietoja napsautettaessa valintaikkunan ulkopuolella

Kaikki komponentit muokataan komponentin määritysvalintaikkunassa, joka avautuu muokkaustilassa.

Komponentin muokkaaminen AEM: ssä (TouchUI-käyttöliittymä)
Komponentin muokkaaminen AEM: ssä (TouchUI-käyttöliittymä)

On pieni ero käyttäjäkokemuksessa Hybridi- ja TouchUI-valintaikkunoissa:

  • Jos käyttäjä napsauttaa pois TouchUI-valintaikkunasta, mitään ei tapahdu.
  • Jos käyttäjä napsauttaa pois hybridistä valintaikkuna, se sulkeutuu tallentamatta syötettyjä tietoja.

Tämä tarkoittaa, että kaikki tallentamattomat tiedot ovat g Hukkaantuminen vahingossa tapahtuvan napsautuksen yhteydessä komponentin ulkopuolelle! Tarpeetonta sanoa, että tämä on kirjailijoille melko ärsyttävää.

Ratkaisu

Onneksi ratkaisu on melko yksinkertainen. Aluksi valintaikkunan taustakuva on ”modaalisessa” tilassa. Dialogien taustatilan vaihtamiseksi valintaikkunan JSP-tiedosto on peitettävä ja valintaikkunan taustan tilaksi on määritettävä staattinen arvo.

Jotkin valintaikkunakentät eivät sovi valintaikkuna-alueeseen

Kuten jo aiemmin kuvailimme, käyttöliittymän valintaikkunat hahmotellaan iframe-kehyksessä TouchUI-valintaikkunan sisällä. Tämä valintaikkuna ei joskus sovi kaikkeen dynaamiseen sisältöön, mikä toisinaan aiheuttaa outoa asettelua, jossa ylimääräiset vierityspalkit näkyvät valintaikkunan sisällä.

Lisäselaus komponentin elementti hybriditilassa
Lisä vierityselementti komponentille hybriditilassa

Ratkaisu

Tämän haitan voittamiseksi peitämme JSP-tiedoston, joka sisältää kaikki kokoonpanoasetukset, jotta valintaikkunat voidaan tehdä oikein yhteensopivuustilassa. Tämä JSP-tiedosto sijoitetaan seuraavaan polkuun:

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

Muutamme ikkunan leveyttä ja korkeutta alkuperäisen huomioon ottamiseksi valintaikkunan mitat sekä selaimen ikkunan koko.

Käsittelemme tämän tilanteen komentosarjan avulla, joka todella tarjoaa sidoksen Touch UI (Coral) -kääreen ja upotetun Classic-valintaikkunan välillä iframe-kehyksessä. Tapahtuma “dialogwrapper-ready” + ns tarvitaan siihen, että käsittelijän toimintoparametreina on ennalta laskettu leveys ja korkeus. On myös mahdollista tehdä oma laskentasi ja asettaa sitten leveys ja korkeus Coral Dialog -sisältöön:

Joitakin komponentteja ei voi muokata TouchUI: ssa (helposti).

Kirjoituskokemus on yksi tärkeimmistä seikoista, jotka on otettava huomioon komponenttien toteuttamisessa AEM: ssä. Kuvittele karusellikomponentti, joka sisältää useita dioja. Muokkaustilassa on parempi tehdä kaikki karusellidiat sarakkeina, jotta tekijä voi järjestää diasarjan helposti uudelleen ja käyttää niitä kaikkia samanaikaisesti siirtymättä dioiden välillä. ClassicUI: n ja TouchUI: n välillä on yksi tärkeä ero:

  • ClassicUI: ssa kirjoittajaelementit (esim. Muokkauspalkit) ovat osa merkintää, joka renderöidään komponentin kanssa muokkaustilassa.
  • TouchUI: ssa tekijän elementit hahmonnetaan peittokuvana. Komponentin lopullinen merkintä tehdään iframe-kehyksessä. Näiden ehtojen yhdistelmä johtaa tekijän tilanteeseen, jossa muokkaustilassa komponentin kanssa ei ole mahdollista olla lainkaan vuorovaikutuksessa (esim. Napsauta painikkeita, selaa karusellin dioja).

Joten kohtaamme tapauksia, joissa kirjaston muutama komponentti vaatii jonkin verran vuorovaikutusta ennen kuin käyttäjä voi aloittaa muokkausprosessin, mutta tätä ei voida helposti saavuttaa TouchUI: n avulla.

Ratkaisut

On kuitenkin olemassa muutamia korjauksia, joita voidaan pitää mahdollisina ratkaisuina:

  1. On olemassa nopea ja yksinkertainen kiertotapa, joka ei vaadi kehitystyötä: kaikki muokattavat komponentit löytyvät Sisältöpuusta ja jokaisen vieressä on jakoavainkuvake, joka avaa muokkausikkunan.
TouchUI-sivun sisältöpuu käyttöliittymä
Sivun sisältöpuu TouchUI-käyttöliittymässä

2. Monimutkaisissa komponenteissa, joissa on paljon alikomponentteja, komponentin merkintää muokkaustilassa voidaan muuttaa siten, että kaikki piilotetut komponenttialueet ovat avoimia tekijän silmille. Tämä tarkoittaisi, että kaikki on näkyvissä ja käytettävissä muokkaustilassa.

3. Parhaana käytäntönä Adobe tarjoaa ratkaisun tukemaan tällaista kirjoituskokemustapausta AEM-ydinkomponenteissa . Karusellikomponentti ja Välilehtien komponentti järjestää diat uudelleen komponenttityökalurivillä Valitse paneeli ja näkymiä ja muuta tällä hetkellä esikatseltavaa elementtiä.

Pakkauksen ulkopuolinen ratkaisu sisällön saavuttamiseksi, joka on piilotettu kirjoittajalta
Pakkauksen ulkopuolinen ratkaisu tekijänoikeuksilta piilotetun sisällön saavuttamiseksi

Avaa sivu -painike ei toimi

AEM-vakiovaihtoehto on lukita ja avata sivu muutosten tekemiseksi. Vahvistaessamme TouchUI-siirtolähestymistavan havaitsimme tilanteen, jossa kirjoittaja ei voinut palauttaa lukittua sivua alkuperäiseen tilaansa. Onneksi tämä toiminto toimii oikein AEM-sivustokonsolin kautta.

Lukitse-vaihtoehto TouchUI-käyttöliittymässä
Lukitse-vaihtoehto TouchUI-käyttöliittymässä

Vastaava ongelma on kuvattu täällä ja täällä .

Ratkaisu

Selainkonsolin virhesanomassa sanotaan, että se ”Ei voi lukea määrittelemättömän” jaettua ”ominaisuutta ”. Perimmäinen syy on puuttuvassa asiakaskirjastossa cq.shared.

Virhesanoma lukitessasi / avatessasi toimintoja
Virhesanoma lukitessasi / avatessasi

Kirjaston cq.shared sisällyttäminen sivun JSP-ratkaisuihin ongelma ja ”Avaa sivu” -painike alkaa toimia odotetulla tavalla.

Tekijät: Volha Lunkova , Liubou Masiuk, Aliaksei Stsefanovich

Alun perin julkaistu osoitteessa https://exadel.com 17. lokakuuta 2019.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *