Klasyczna migracja interfejsu dotykowego dla AEM: więcej wskazówek od Doświadczenie

(Liubou Masiuk) (17 października 2019 r.)

W naszym poprzednim (poście dotyczącym migracji Classic do TouchUI) opisaliśmy nasze ogólne podejście „trybu hybrydowego” do migracji całkowicie klasycznej biblioteki komponentów UI do Touch UI przy użyciu Tryb zgodności AEM. W poście nawiązaliśmy do pewnych „dziwactw”, które napotkaliśmy. W tym nowym poście bardziej szczegółowo omawiamy te dziwactwa i sposoby radzenia sobie z niektórymi z nich.

Chociaż tryb hybrydowy jest niezwykle przydatny, ma pewne ograniczenia, które mogą uniemożliwić zespołowi programistów przyjęcie TouchUI bez dodatkowego wysiłku przy dużych projektach. Oto niektóre z napotkanych przez nas problemów i rozwiązań, które wymyślił nasz zespół programistów.

Autor nie może przeciągać & upuszczać obrazów podczas edytowania komponentu

ClassicUI Biblioteka widżetów udostępnia składnik SmartImage do przesyłania i przetwarzania obrazów. Zasoby graficzne można domyślnie przesyłać na dwa różne sposoby:

  • Z systemu plików
  • Z DAM (Menedżera zasobów cyfrowych), przeciągając obraz z wyszukiwarki zawartości strony panel po lewej stronie
Panel zasobów DAM (interfejs TouchUI)
Panel zasobów DAM (Interfejs TouchUI)

Zagłębmy się w szczegóły techniczne implementacji TouchUI. Tryb zgodności renderuje okno dialogowe ClassicUI wewnątrz elementu iframe. Z jakiegoś powodu tryb zgodny nie ma żadnej logiki do śledzenia przeciągania & upuszczania zdarzeń po wyjęciu z pudełka. Ogranicza to autorom możliwość przeciągania obrazów poza panel Zasoby (ponieważ są do tego przyzwyczajeni w środowisku ClassicUI). Oznacza to, że nie mają możliwości umieszczenia obrazu w komponencie. Ponadto, gdy wymagane jest pole obrazu, autor nie ma możliwości zakończenia konfiguracji komponentu z powodu pustego pola wymaganego.

Rozwiązanie

Aby rozwiązać ten problem, zdecydowaliśmy się rozszerz standardowy składnik SmartImage, aby renderować pole ścieżki jako dodatek do istniejącej funkcjonalności. W rezultacie autor ma możliwość wyboru obrazu za pomocą pola ścieżki, a obraz pojawia się w obszarze SmartImage w celu podglądu i / lub zmiany obrazu w razie potrzeby. W przypadku ścieżek nieistniejących (lub ścieżek nie będących obrazami) pole jest podświetlane jako nieprawidłowe.

Wymagany obszar obrazu wewnątrz komponentu
Wymagany obszar obrazu wewnątrz komponentu
  1. Ponownie zarejestruj oryginalny xtype htmlsamartimage na nieodłączny niestandardowy, który rozszerza oryginał Widżet CQ HtmlSmartImage. Podczas inicjalizacji nowego widżetu dodajemy dodatkowy widżet PathField do kontenerów komponentów. Ponadto zapewniamy niewielkie aktualizacje domyślnego układu widżetów, który jest typową aktualizacją interfejsu użytkownika dla interfejsów użytkownika opartych na ExtJS.
  2. Kontrolki powiązania (PathFields) we wszystkich HTMLSmartImages. Przede wszystkim przygotowujemy pomocników, tworząc metody pobierania i ustawiania wartości z PathPickera oraz te same metody dla oryginalnego komponentu. Pierwsza para to setValue i getValue z PathField, co jest prostszą częścią. Najtrudniejsza część dotyczy oryginalnej wartości komponentu. HTMLSmartImage nie przechowuje swojej wartości w stanie dostępnym.

Aby uzyskać bieżącą ścieżkę obrazu, można łatwo uzyskać za pomocą metody this.fileReferenceField.getValue (). Ale aby ustawić wartość na oryginalny widget, musimy emulować upuszczenie zasobu obrazu w komponencie. Możemy to zrobić w następujący sposób:

Teraz, gdy mamy wszystkie akcesory wartości, których potrzebujemy wiedzieć, kiedy oryginał i kiedy zmienia się wartość Pathfield. Aby śledzić zmiany w Pathfield, możemy użyć zdarzenia „rozmycia”. W przypadku oryginalnego widżetu najbardziej odpowiednie jest zdarzenie „imagestate”. Musimy śledzić dwa typy zmian stanu obrazu: „originalremoved” i „originalavailable”, więc odbiornikiem może być:

Teraz jest gotowy do wiązania. Aby zachować mechanizm walidacji w nowej implementacji, nadpisujemy oryginalną logikę walidacji dla osadzonej instancji pathfield.

Wszystkie okna dialogowe pól szkieletu są wyłączone.

AEM Tryb tworzenia szkieletów umożliwia autorowi łatwe tworzenie stron w oparciu o określoną strukturę formularza szkieletowego. Rusztowania są niezwykle przydatne do tworzenia dobrze zdefiniowanej zawartości strukturalnej (np. Artykułów, postów na blogu).

W trybie hybrydowym wszystkie pola formularzy szkieletu są wyłączone, co oznacza, że ​​nie można ich edytować.

Przykład formularza rusztowania
Przykład formularza rusztowania

Rozwiązanie

Dołączenie biblioteki cq.security do strony JSP rozwiązało problem, a formularze szkieletu zaczęły działać poprawnie.

Hybrydowe okno dialogowe zamyka się bez zapisywania danych po kliknięciu poza obszarem okna dialogowego

Wszystkie komponenty są edytowane w oknie dialogowym konfiguracji komponentów, które pojawia się w trybie edycji.

Edycja komponentu w AEM (interfejs TouchUI)
Edycja komponentu w AEM (interfejs TouchUI)

Jest niewielka różnica w doświadczeniu użytkownika w oknach dialogowych Hybrid i TouchUI:

  • Jeśli użytkownik opuści okno dialogowe TouchUI, nic się nie dzieje.
  • Jeśli użytkownik opuści hybrydę okno dialogowe zamyka się bez zapisywania wprowadzonych danych.

Oznacza to, że wszystkie niezapisane dane są o zagubieniu w przypadku przypadkowego kliknięcia poza komponentem! Nie trzeba dodawać, że jest to dość denerwujące dla autorów.

Rozwiązanie

Na szczęście rozwiązanie jest dość proste. Początkowo tło okna dialogowego jest w trybie „modalnym”. Aby zmienić tryb tła okna dialogowego, należy nałożyć plik JSP okna dialogowego, a tryb tła okna dialogowego ustawić na wartość „statyczną”.

Niektóre pola okna dialogowego nie mieszczą się w obszarze okna dialogowego

Jak już opisaliśmy wcześniej, okna dialogowe interfejsu użytkownika są renderowane w ramce iframe w oknie dialogowym TouchUI. To okno dialogowe czasami nie pasuje do całej zawartości dynamicznej, czasami powodując dziwny układ, w którym w oknie pojawiają się dodatkowe paski przewijania.

Dodatkowe przewijanie element dla komponentu w trybie hybrydowym
Dodatkowy element przewijania dla komponentu w trybie hybrydowym

Rozwiązanie

Aby przezwyciężyć tę niedogodność, nakładamy plik JSP, który zawiera wszystkie ustawienia konfiguracyjne, aby poprawnie renderować okna dialogowe w trybie zgodności. Ten plik JSP jest umieszczony w następującej ścieżce:

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

Zmieniamy szerokość i wysokość okna, aby uwzględnić oryginał wymiary okna dialogowego, a także rozmiar okna przeglądarki.

Obsługujemy tę sytuację za pomocą skryptu, który faktycznie zapewnia powiązanie między opakowaniem dotykowego interfejsu użytkownika (koral) a osadzonym klasycznym oknem dialogowym w ramce iframe. Zdarzenie „dialogwrapper-ready” + ns jest potrzebne do tego z wstępnie obliczoną szerokością i wysokością jako parametrami funkcji obsługi. Możliwe jest również wykonanie własnego przeliczenia, a następnie ustawienie szerokości i wysokości zgodnie z zawartością Coral Dialog:

Niektórych komponentów nie można edytować w TouchUI (łatwo)

Doświadczenie tworzenia jest jednym z najważniejszych punktów do rozważenia podczas implementacji komponentów w AEM. Wyobraź sobie komponent karuzeli zawierający kilka slajdów. W trybie edycji lepiej jest wyrenderować wszystkie slajdy karuzeli jako kolumny, aby autor mógł łatwo zmienić kolejność slajdów i uzyskać do nich dostęp jednocześnie bez przełączania się między slajdami. Istnieje jedna ważna różnica między ClassicUI a TouchUI:

  • W ClassicUI elementy autorskie (np. Paski edycji) są częścią znacznika renderowanego ze składnikiem w trybie edycji.
  • W TouchUI elementy autorskie są renderowane w postaci nakładki. Ostateczny znacznik składnika jest renderowany w ramce iframe. Połączenie tych warunków prowadzi autora do sytuacji, w której nie można w ogóle wchodzić w interakcję z komponentem w trybie edycji (np. Klikać przyciski, przewijać slajdy karuzeli).

Dlatego spotykamy się z przypadkami, w których kilka komponentów w naszej bibliotece wymaga pewnej interakcji, zanim użytkownik będzie mógł rozpocząć proces edycji, ale nie można tego łatwo osiągnąć w TouchUI.

Rozwiązania

Jest jednak kilka poprawek, które można uznać za możliwe rozwiązania:

  1. Istnieje szybkie i proste obejście, które nie wymaga żadnego wysiłku programisty: wszystkie edytowalne komponenty można znaleźć w drzewie treści i obok każdego z nich znajduje się ikona klucza, która otwiera okno dialogowe edycji.
Drzewo zawartości strony w TouchUI interfejs
Drzewo zawartości strony w interfejsie TouchUI

2. W przypadku złożonych komponentów z wieloma składnikami podrzędnymi można zmienić oznaczenie komponentu w trybie edycji, aby wszystkie „ukryte” obszary komponentów były otwarte dla „oczu” autora. Oznaczałoby to, że wszystko jest widoczne i dostępne w trybie edycji.

3. Zgodnie z najlepszą praktyką firma Adobe zapewnia rozwiązanie do obsługi takiego przypadku tworzenia treści w podstawowych składnikach AEM . Carousel Component i Tabs Component używają opcji Select Panel na pasku narzędzi komponentu, aby zmienić kolejność slajdów oraz wyświetla i zmienia aktualnie wyświetlany podgląd elementu.

Gotowe rozwiązanie umożliwiające dotarcie do zawartości ukrytej przed tworzeniem
Gotowe rozwiązanie do uzyskiwania dostępu do treści ukrytej przed tworzeniem

Przycisk „odblokuj stronę” nie działa

Standardowa opcja AEM umożliwia blokowanie i odblokowywanie strony w celu wprowadzenia zmian. Podczas sprawdzania metody migracji TouchUI znaleźliśmy sytuację, w której autor nie mógł przywrócić „zablokowanej” strony do stanu początkowego. Na szczęście ta funkcja działa poprawnie za pośrednictwem konsoli witryny AEM.

Opcja „Zablokuj” w interfejsie TouchUI
Opcja blokady w interfejsie TouchUI

Podobny problem opisano tutaj i tutaj .

Rozwiązanie

Komunikat o błędzie w konsoli przeglądarki mówi, że „Nie można odczytać właściwości„ shared ”undefined ”. Główna przyczyna leży w brakującej bibliotece klienta „cq.shared”.

Komunikat o błędzie podczas obsługi funkcji „Blokowanie / Odblokowywanie”
Komunikat o błędzie podczas obsługi funkcji „Blokowanie / Odblokowywanie”

Dołączanie biblioteki „cq.shared” do rozwiązań JSP strony problem i przycisk „Odblokuj stronę” zaczyna działać zgodnie z oczekiwaniami.

Autorzy: Volha Lunkova , Liubou Masiuk, Aliaksei Stsefanovich

Pierwotnie opublikowane w https://exadel.com 17 października 2019 r.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *