Migração de IU clássico para toque para AEM: mais dicas de Experiência

(Liubou Masiuk) (17 de outubro de 2019)

Em nosso artigo anterior (postagem sobre a migração de Classic para TouchUI), descrevemos nossa abordagem geral de “Modo Híbrido” para migrar uma biblioteca de componentes de UI inteiramente Classic para Touch UI usando Modo de compatibilidade do AEM. No post, aludimos a algumas “peculiaridades” que encontramos. Neste novo post, vamos entrar em muito mais detalhes sobre essas peculiaridades e como lidar com algumas delas.

Embora o modo híbrido seja extremamente útil, ele tem algumas limitações que podem impedir a equipe de desenvolvimento de adotar TouchUI sem esforço adicional em grandes projetos. Aqui estão alguns dos problemas que encontramos e as soluções que nossa equipe de desenvolvimento apresentou.

O autor não pode arrastar & imagens soltas ao editar um componente

A ClassicUI Biblioteca de widgets fornece um componente SmartImage para enviar e processar imagens. Os ativos de imagem por padrão podem ser carregados de duas maneiras diferentes:

  • Do sistema de arquivos
  • Do DAM (Digital Asset Manager) arrastando a imagem do localizador de conteúdo da página painel do lado esquerdo
painel de ativos DAM (interface TouchUI)
painel de ativos DAM (Interface TouchUI)

Vamos nos aprofundar nos detalhes técnicos da implementação TouchUI. O modo de compatibilidade renderiza uma caixa de diálogo ClassicUI dentro de um iframe. Por algum motivo, o modo compatível não tem nenhuma lógica para rastrear eventos de arrastar & soltar fora da caixa. Isso impede que os autores arrastem imagens para fora do painel Ativos (como estão acostumados a fazer isso na experiência ClassicUI). Isso significa que eles não têm como colocar a imagem no componente. Além disso, quando um campo de imagem é obrigatório, o autor não tem a opção de completar a configuração do componente por causa de um campo obrigatório vazio.

Solução

Para resolver este problema, decidimos estenda o componente Standard SmartImage para renderizar um pathfield além da funcionalidade existente. Como resultado, o autor obtém a capacidade de selecionar uma imagem usando pathfield e a imagem aparece dentro da área SmartImage para visualizar e / ou alterar a imagem, se necessário. Para caminhos não existentes (ou caminhos sem imagem), o campo é destacado como inválido.

Área da imagem necessária dentro do componente
Área de imagem necessária dentro do componente
  1. Registre novamente o htmlsamartimage xtype original com um personalizado inerente que estende o original Widget CQ HtmlSmartImage. Na inicialização do novo widget, adicionamos um widget PathField adicional aos contêineres de componentes. Além disso, fornecemos pequenas atualizações para o layout de widget padrão que é uma atualização de IU comum para IUs baseadas em ExtJS.
  2. Controles de vinculação (PathFields) em todos os HTMLSmartImages. Em primeiro lugar, preparamos auxiliares criando métodos para obter e definir valores do PathPicker e os mesmos métodos para o componente original. O primeiro par é setValue e getValue do PathField, que é a parte fácil. A parte complicada é lidar com o valor do componente original. HTMLSmartImage não armazena seu valor em um estado acessível.

Para obter o caminho da imagem atual, é fácil usar o método this.fileReferenceField.getValue (). Mas para definir o valor para o widget original, precisamos emular uma queda de recurso de imagem no componente. Podemos gerenciar isso da seguinte maneira:

Agora, quando temos todos os acessadores de valor, precisamos saber quando o original e quando o valor do Pathfield estão mudando. Para rastrear as mudanças do Pathfield, podemos usar um evento ‘blur’. Para o widget original, o evento ‘imagestate’ é o mais adequado. Precisamos rastrear dois tipos de alterações de estado de imagem: originalremoved e originalavailable, para que o ouvinte possa ser o seguinte:

Agora, está pronto para vinculação. Para manter o mecanismo de validação na nova implementação, substituímos a lógica de validação original para a instância de pathfield incorporada.

Todos os diálogos de campos de scaffolding são desativados

AEM O modo de andaime permite que um autor crie facilmente páginas com base em uma estrutura de formulário de andaime específica. Os scaffolds são extremamente úteis para criar conteúdo estruturado bem definido (por exemplo, artigos, postagens de blog).

No modo híbrido, todos os campos do formulário de scaffolding são desativados, o que significa que não podem ser editados.

Exemplo de forma de andaime
Exemplo de forma de andaime

Solução

Incluir a biblioteca cq.security no JSP da página resolveu o problema e os formulários de scaffolding começaram a funcionar corretamente.

A caixa de diálogo híbrida fecha sem salvar dados ao clicar fora da área de diálogo

Todos os componentes são editados dentro da janela de diálogo de configuração do componente, que aparece no modo de edição.

Editando um componente no AEM (interface TouchUI)
Editando um componente no AEM (interface TouchUI)

Existe uma pequena diferença na experiência do usuário em caixas de diálogo Hybrid e TouchUI:

  • Se um usuário clicar fora da caixa de diálogo TouchUI, nada acontece.
  • Se um usuário clicar fora da caixa de diálogo híbrida caixa de diálogo, ele fecha sem salvar os dados inseridos.

Isso significa que todos os dados não salvos são g oing se perder no caso de um clique acidental fora do componente! Não é preciso dizer que isso é muito chato para os autores.

Solução

Felizmente, a solução é bem simples. Inicialmente, o pano de fundo do diálogo está no modo “modal”. Para alterar o modo de fundo da caixa de diálogo, o arquivo JSP da caixa de diálogo precisa ser sobreposto e o modo de fundo da caixa de diálogo definido para o valor “estático”.

Alguns campos da caixa de diálogo não cabem na área da janela de diálogo

Como já descrevemos antes, as caixas de diálogo da IU são renderizadas em um iframe dentro da janela de diálogo TouchUI. Esta janela de diálogo às vezes não se ajusta a todo o conteúdo dinâmico, às vezes causando um layout estranho onde barras de rolagem extras aparecem dentro da caixa de diálogo.

Rolagem adicional elemento para o componente no modo híbrido
Elemento de rolagem adicional para o componente no modo híbrido

Solução

Para superar esse inconveniente, sobrepomos o arquivo JSP que contém todas as configurações para renderizar corretamente os diálogos no modo de compatibilidade. Este arquivo JSP é colocado dentro do seguinte sob o seguinte caminho:

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

Mudamos a largura e altura da janela para considerar o original dimensões da caixa de diálogo, bem como o tamanho da janela do navegador.

Lidamos com essa situação por meio de um script que realmente fornece vínculo entre o wrapper Touch UI (Coral) e a caixa de diálogo Classic incorporada no iframe. O evento “dialogwrapper-ready” + ns é necessário para isso com largura e altura pré-calculadas como parâmetros de função do manipulador. Também é possível fazer seu próprio recálculo e definir a largura e altura para o conteúdo do Coral Dialog:

Alguns componentes não podem ser editados no TouchUI (facilmente)

A experiência de autoria é um dos pontos mais importantes a serem considerados ao implementar componentes no AEM. Imagine um componente de carrossel que contém vários slides. No modo de edição, é melhor renderizar todos os slides do carrossel como uma coluna para que o autor possa reorganizar facilmente a ordem dos slides e acessar todos eles simultaneamente, sem alternar entre os slides. Há uma diferença importante entre ClassicUI e TouchUI:

  • No ClassicUI, os elementos de autoria (por exemplo, barras de edição) são uma parte da marcação que é renderizada com o componente no modo de edição.
  • No TouchUI, os elementos de autoria são renderizados em uma sobreposição. A marcação final do componente é renderizada em um iframe. A combinação dessas condições leva o autor à situação em que não é possível interagir com o componente no modo de edição (por exemplo, clicar em botões, navegar pelos slides de um carrossel).

Portanto, enfrentamos casos em que alguns componentes em nossa biblioteca requerem alguma interação antes que o usuário possa iniciar o processo de edição, mas isso não pode ser facilmente alcançado no TouchUI.

Soluções

No entanto, existem algumas correções que podem ser consideradas possíveis soluções:

  1. Há uma solução rápida e simples que não requer esforço de desenvolvimento: todos os componentes editáveis ​​podem ser encontrados na Árvore de conteúdo e há um ícone de chave inglesa próximo a cada um deles que abre a caixa de diálogo de edição.
Árvore de conteúdo da página no TouchUI interface
Árvore de conteúdo da página na interface TouchUI

2. Para componentes complexos com muitos subcomponentes, a marcação do componente no modo Editar pode ser alterada para tornar todas as áreas de componentes “ocultas” abertas aos “olhos” do Autor. Isso significa que tudo está visível e acessível através do modo de edição.

3. Como prática recomendada, a Adobe oferece uma solução para oferecer suporte a esse caso de experiência de autoria dentro dos AEM Core Components . Componente Carrossel e Componente Guias usam a opção Selecionar Painel na barra de ferramentas do componente para reordenar os slides e visualiza e altera o elemento visualizado no momento.

Solução pronta para usar para alcançar conteúdo oculto da criação
Solução pronta para o uso para alcançar conteúdo oculto da autoria

O botão “desbloquear página” não funciona

Existe uma opção AEM padrão para bloquear e desbloquear a página para alterações. Ao validar a abordagem de migração TouchUI, encontramos uma situação em que o autor não conseguiu reverter uma página “bloqueada” ao seu estado inicial. Felizmente, essa funcionalidade funciona corretamente por meio do AEM Site Console.

Opção Bloquear na interface TouchUI
Opção Lock na interface TouchUI

Um problema semelhante é descrito aqui e aqui .

Solução

A mensagem de erro no console do navegador diz que “Não é possível ler propriedade compartilhada de indefinido ”. A causa raiz está em uma biblioteca cliente ausente cq.shared.

Mensagem de erro ao lidar com a funcionalidade Bloqueio / desbloqueio
Mensagem de erro ao lidar com a funcionalidade Bloquear / Desbloquear

Incluir a biblioteca cq.shared nas soluções JSP da página o problema e o botão “Desbloquear página” começa a funcionar conforme o esperado.

Autores: Volha Lunkova , Liubou Masiuk, Aliaksei Stsefanovich

Originalmente publicado em https://exadel.com em 17 de outubro de 2019.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *