Integração do mecanismo HTML no aplicativo nativo do Windows - escolha e arquitetura

Como traduzimos o trabalho com HTML no 1C: Enterprise do Internet Explorer para o WebKit

A capacidade de exibir HTML nos formulários 1C apareceu na plataforma 1C: Enterprise em 2003, versão 8.0. Para trabalhar com HTML, a plataforma usava o mecanismo do navegador Internet Explorer (1C: Enterprise naquela época trabalhava apenas no Windows). O mecanismo do navegador foi usado pela plataforma para fins utilitários. Por exemplo, para escrever do zero um elemento completo para editar texto no Word - com a possibilidade de várias soluções de cores e fontes, inserir imagens, etc. - uma tarefa muito difícil. E se você usar HTML para esses fins e usar o mecanismo do navegador da Internet como ferramenta de exibição, a tarefa será bastante simplificada. Além disso, com a ajuda do mecanismo, vários outros mecanismos (por exemplo, exibindo informações de ajuda ) e elementos (por exemplo, Agendador ) foram implementados.

Bem, a capacidade dos desenvolvedores de aplicativos exibirem usando o design customizado em HTML pelos padrões do mundo dos sistemas de contabilidade às vezes possibilitou trazer uma variedade de destaques agradáveis ​​à interface dos aplicativos de negócios.

Com o passar do tempo, a plataforma começou a dar suporte ao Linux primeiro e depois ao macOS. O Internet Explorer não era adequado para trabalhar com HTML nesses sistemas operacionais por razões óbvias; no Linux, usamos o WebKitGTK + e no macOs, uma biblioteca baseada em Cocoa. Portanto, a unidade da base de código para diferentes sistemas operacionais (que tentamos manter para o código do cliente no nível de 95%) foi violada nessa área. Bem, o mecanismo do IE a essa altura se tornou a fonte de vários problemas.


Os problemas:

• O mecanismo do IE fechou o código-fonte - significa:
  
  • Não é possível o ajuste flexível do motor às necessidades da plataforma
  • Depuração e compreensão de processos internos
  • Não é possível corrigir bugs e erros atualizando a versão do mecanismo
• O mecanismo não é adequado para a implementação de tarefas modernas de programação da web
• Problemas de desempenho em máquinas fracas

Portanto, a tradução de trabalhar com HTML na versão 1C: Enterprise for Windows do mecanismo do IE para outra coisa era óbvia. O que escolher?

Para começar, formulamos os requisitos para o mecanismo:

• Suporte para modernas tecnologias de programação da web
• Código aberto para personalização flexível do mecanismo e entendimento de sua lógica
• Alto desempenho em computadores mais lentos
• É desejável que o mecanismo exija um pequeno número de bibliotecas de terceiros para funcionar

Seleção do motor

O que escolher? Começamos, é claro, com o WebKit , com o qual já trabalhamos em versões da plataforma para Linux e macOS.

O WebKit foi desenvolvido na Apple no início dos anos 2000 com base nos mecanismos de código aberto KHTML e KJS . Com base no WebKit, o navegador Safari foi criado posteriormente - Chrome (ainda mais tarde, o Chrome passou do WebKit para o Blink , que novamente se baseia no código WebCore do WebKit).

O código fonte do WebKit é de código aberto e licenciado sob a LGPL . O WebKit foi escrito para o macOS, existem várias portas para o Windows:

WebKit AppleWin

Essa é a porta que os desenvolvedores do WebKit sugerem criar no Windows por padrão. Foi fabricado por funcionários da Apple em meados do final dos anos 2000. Ele usa a biblioteca de gráficos CoreGraphics , que é uma versão simplificada da biblioteca para macOS, portada para o Windows. Para executar o JavaScript, a porta usa a biblioteca JavaScriptCore com a mesma API usada na implementação da plataforma para Linux. Isso o torna um excelente candidato para uso.

WebKit WinCairo

Essa porta usa a biblioteca do Cairo para gráficos. Há algum tempo, a Apple desenvolve ativamente essa porta como um análogo à principal porta AppleWin. A vantagem dessa porta é que ela depende menos das bibliotecas específicas do macOS que o CoreGraphics exige. Além disso, a porta usa a mesma biblioteca de gráficos ( Cairo ) que o mecanismo WebKitGTK +, usado na implementação da plataforma Linux, o que é bom para padronizar o comportamento do nosso código.

QtWebKit

Outra implementação do mecanismo WebKit para Windows, agora independente dos desenvolvedores do próprio mecanismo. O Qt é uma biblioteca popular de plataforma cruzada com sua própria biblioteca de gráficos QtGui. Essa porta também usa a biblioteca JavaScriptCore para manipular o JavaScript, no entanto, possui desvantagens:

• Forte dependência dos principais componentes do Qt, que, se usados ​​em software de terceiros, precisarão ser entregues com ele
• Um conjunto diferente de interfaces para trabalhar com componentes para renderizar HTML em comparação com o WebKitGTK e sua própria lógica para trabalhar com eles.

WebKitGtk + para Windows

Já usamos o WebKitGtk + na versão Linux da plataforma. Mas a opção de usá-lo no Windows foi descartada devido à complexidade da montagem, à documentação insuficiente desse processo e à falta de suporte constante para essa área de desenvolvimento por parte dos desenvolvedores do WebKitGTK +.

Crómio (intermitente)

O primeiro e único mecanismo não semelhante ao WebKit, considerado um candidato para resolver o problema. Foi rejeitado devido a grandes diferenças na lógica dos componentes para renderizar HTML em comparação com o WebKitGTK + e outra biblioteca para trabalhar com JavaScript ( V8 ).

O que escolher?

Após a pesquisa, AppleWin e WinCairo chegaram à final.
Para fazer a escolha final, estudamos como o WebKit funciona.

Estrutura do mecanismo WebKit

Normalmente, portas diferentes do WebKit diferem de duas maneiras. A primeira é diretamente a implementação de um sistema operacional específico usando componentes específicos do sistema operacional. O segundo é uma biblioteca de gráficos. A figura abaixo descreve as diferenças nesse sentido entre as portas do WebKit. Para o Windows, os desenvolvedores do WebKit criaram portas na biblioteca CoreGraphics e Cairo adaptada.



Um modelo simplificado do mecanismo: três mecanismos tradicionais para formatar uma página da web - HTML, JavaScript e CSS - são alimentados no mecanismo, que forma e exibe a página a partir deles:



O próprio mecanismo consiste em vários componentes:

• WTF (Web Template Framework, não o que você poderia ter pensado ): aqui você encontra suas próprias implementações de estruturas de dados para o funcionamento do mecanismo, além de trabalhar com fluxos
• JavaScriptCore: um componente, como o nome indica, para trabalhar com a linguagem JavaScript
• WebCore: todo o trabalho com DOM, estilos, análise de HTML e XML está escrito aqui. Toda a "mágica" principal do mecanismo é feita aqui.
• Plataforma: executa ações técnicas para interagir com a rede, colocar dados em um banco de dados, decodificar imagens, trabalhar com mídia
• WebKit e WebKit2 API - vinculando todos os componentes e fornecendo acesso a eles

O relacionamento entre os componentes do WebKit e os recursos específicos do SO é mostrado na figura abaixo. Como você pode ver, existem alguns pontos específicos que precisam ser implementados para cada sistema operacional separadamente. Embora o JavaScriptCore permita que você se use em cada porta sem implementações separadas.

Como uma página da web é formada

A partir da rede, uma resposta chega a uma solicitação ao servidor com dados para download. O carregador passa os dados para o analisador, que, interagindo com o componente para JavaScript, forma o DOM e a folha de estilos. Em seguida, os dados gerados são transferidos para a árvore de renderização e exibidos em um contexto gráfico.

A própria página também consiste em componentes individuais. O componente WebCore implementa a classe Page, que permite acesso a toda a página. A página possui um quadro principal - MainFrame, um quadro sempre possui um documento. O quadro principal pode ter qualquer número de outros quadros, também com documentos dentro. Para cada quadro, alguns eventos são formados separadamente, bem como contextos gráficos e JavaScript específicos.



O analisador HTML simplificado funciona assim. Do conjunto de bytes recebidos do servidor, o decodificador gera um conjunto de caracteres para análise. Os símbolos são convertidos em tokens ou tokens, que geralmente são trechos de código elementares com metainformações sobre o tipo de texto, se faz parte da sintaxe ou do conteúdo do idioma. Em seguida, os nós são formados a partir de tokens para construir uma árvore DOM. Um construtor de árvores de um conjunto de nós forma um modelo de objeto completo para um documento de página da web.

Escolha final

• Applewin
  • Prós:
    • Implementado em uma biblioteca de gráficos executada no macOS - a principal plataforma de destino para desenvolvedores do WebKit
  • Contras:
    • Falta de implementação do mecanismo de impressão
    • Um grande número de dependências
• Wincairo
  • Prós:
    • A mesma biblioteca de gráficos (Cairo), usada na porta Linux da plataforma 1C
  • Contras:
    • Essencial para as nossas tarefas não encontradas

Derrotado WinCairo. Para o desenvolvimento, foi utilizada a versão mais recente do WebKit disponível na época - 605.1.11.

Implementação

Embora o mecanismo seja bastante bem coberto por testes de unidade (cerca de 30.000 para todos os componentes do mecanismo, escritos pelos autores do mecanismo), existem erros e deficiências nas implementações de sistemas operacionais "não essenciais" (ou seja, para tudo que não é macOS). Essas falhas de implementação foram gradualmente descobertas à medida que o mecanismo foi desenvolvido e testado como parte da plataforma 1C: Enterprise.

Baixar HTML via Arrastar e Soltar

Ao arrastar o texto para a janela, verificou-se que, se o texto sendo arrastado contiver caracteres não ASCII, os hieróglifos serão inseridos no documento final. O erro apareceu apenas na implementação do mecanismo do Windows, porque funcionava com um mecanismo específico do SO para arrastar e soltar elementos. Acontece que o texto não foi decodificado de UNICODE para UTF-16 antes de ser passado para o manipulador de eventos de inserção.

Alterar Shift + Enter Comportamento do teclado

Na maioria dos editores de texto (incluindo o Microsoft Word), essa combinação insere uma quebra de linha. O comportamento padrão do WebKit é inserir um novo parágrafo (como se estivesse simplesmente pressionando Enter). Mudamos o mecanismo, tornando o comportamento mais familiar para os usuários.

Organização do mecanismo Desfazer e Refazer.

O WebKit fornece uma API para implementar seu próprio mecanismo para cancelar e repetir ações do usuário. Seu esquema é o seguinte: quando o usuário executa uma certa ação discreta do ponto de vista do mecanismo (por exemplo, alternando para um novo parágrafo, formatando em itálico, colando), o WebKit informa o desenvolvedor sobre isso usando a API para que ele possa registrar esta ação.

No processo de teste do mecanismo implementado, uma coisa desagradável foi descoberta: o mecanismo não relata alterações na estrutura das tabelas. Foram adicionados comandos para adicionar e remover células e alterar o atributo colSpan, que se tornaram parte de ações compostas, como, por exemplo, adicionar / remover uma coluna ou uma linha de uma tabela. Esses comandos compostos são registrados na mesma pilha de desfazer e refazer e, junto com os comandos do mecanismo, garantem a operação correta do mecanismo.

Colar do Excel

Aqueles que trabalharam com a área de transferência do Windows e o Excel podem saber que, em primeiro lugar, ao copiar do Excel para HTML, o formato da área de transferência no fragmento copiado contém apenas as marcas de células e linhas, mas não a marca da tabela e, em segundo lugar, estilos de um documento do Excel não são transferidos para as células. Por esse motivo, inserir, por exemplo, uma tabela de cores em um elemento editável no Chrome se parece com o seguinte:

Original:



No Chrome:



Esses dois fatores não foram levados em consideração pelos desenvolvedores do WebKit. A abertura do código do mecanismo nos permitiu refinar o mecanismo de inserção, e agora o fragmento da tabela inserida no campo HTML do documento está próximo ao original:

Geração de fonte em itálico

Se o Windows não tiver uma versão em itálico de uma fonte não padrão, a maioria dos editores de texto poderá gerar essa fonte usando sua versão regular. No entanto, o WebKit não foi capaz de fazer isso e enganou os desenvolvedores algumas vezes: como é que no código HTML do documento colocamos o texto na tag <i>, mas, apesar disso, o texto permaneceu reto. O motivo é que o mecanismo WebKit seleciona a fonte correta na porta WinCairo que usamos - se não houver versão em itálico, o mecanismo usará a versão regular. Esse comportamento foi substituído pelo uso da fonte em itálico gerada pela biblioteca de gráficos do Cairo.

Erros na decodificação de imagens e animações

Foram encontrados erros no comportamento do mecanismo ao trabalhar com elementos gráficos. Ao carregar algumas imagens no formato PNG, foi observada distorção da imagem e, algumas vezes, sua ausência. Não foi possível descobrir o motivo desse comportamento, pois ocorre um erro ao decodificar imagens nas entranhas da biblioteca libpng.

Empiricamente, verificou-se que, ao vincular a biblioteca libpng de maneira dinâmica, em vez de estática, o problema é corrigido. A propósito, na versão atual do mecanismo, a vinculação é feita dessa maneira. Foi decidido fazer o mesmo.

Outro problema foi o mecanismo ao carregar animações no formato GIF. O erro era reproduzido periodicamente ao carregar a página com essas animações e causava o travamento do programa. O erro foi causado pela falta de sincronização ao trabalhar com o buffer no qual o próximo quadro da animação é colocado. O problema foi resolvido usando as ferramentas internas de sincronização do WebKit.

Suporte de ortografia

Na montagem com o Internet Explorer, no Windows versão 8 e posterior, a verificação ortográfica pode ser ativada para o campo editável em HTML. Para fazer isso, basta atribuir "verificação ortográfica" igual a "true". O WebKit tinha soluções diferentes para portas diferentes: no Linux, é a biblioteca Enchant , no macOS, possui seu próprio mecanismo, familiar a todos os usuários de produtos da Apple. Mas para o Windows não há implementação, mas uma API é fornecida para sua própria solução. Usamos a API de verificação ortográfica do Windows , disponível a partir do Windows 8, e implementamos um mecanismo semelhante à compilação no Internet Explorer. A propósito, agora em um documento formatado em clientes nativos 1C: Enterprise, essa funcionalidade também funciona. Antes da versão 8.3.14, era desabilitada devido ao baixo desempenho do Internet Explorer.

Suporte para Windows XP

Alguns de nossos clientes ainda trabalham no Windows XP e não atualizarão o sistema operacional no futuro próximo. Triste para nós como desenvolvedores, mas é verdade. Então - precisamos apoiá-los. E aqui tivemos uma surpresa desagradável: os desenvolvedores do WebKit há cerca de um ano não suportam o mecanismo no WinXP. Uma tentativa de compilar uma versão do mecanismo com um conjunto de ferramentas de compilação para o WinXP não teve êxito - os desenvolvedores do WebKit usam bibliotecas que estão disponíveis apenas no Windows Vista e versões posteriores.

O que fazer As opções foram as seguintes:

1. Deixe a implementação do WinXP com o mecanismo do Internet Explorer e use o WebKit em versões mais antigas do Windows
2. Leve para o desenvolvimento uma versão anterior do mecanismo WebKit, que funciona no WinXP, e use esta versão em todos os sistemas operacionais.
3. Use a versão apropriada do WebKit no WinXP e use o mecanismo mais recente nas versões mais antigas do Windows
4. Portar a versão atual do mecanismo para o WinXP e usá-lo em qualquer lugar

A questão não era simples. A primeira opção permitiu que você usasse a versão mais recente do mecanismo WebKit, mas o forçaria a retornar a implementação antiga com o Internet Explorer. Em tal solução, seria difícil garantir a operação sem erros do programa, e o próprio código seria muito complicado. A segunda opção forneceu o mesmo comportamento em todos os sistemas operacionais Windows, no entanto, não nos deixaria a oportunidade de desenvolvimento - atualizando o mecanismo para corrigir erros e obter novos recursos dos desenvolvedores do mecanismo em versões posteriores. A terceira opção permitiu que você usasse a versão atual do mecanismo em versões mais antigas do Windows, mas complicou bastante a lógica de instalação e garantiu o mesmo comportamento de versão em todos os sistemas operacionais. A quarta opção parecia preferível a todas as outras, mas era impossível prever a complexidade e, em geral, a possibilidade de tal solução.

No entanto, decidimos arriscar e implementar a quarta opção, a mais correta do ponto de vista arquitetural (usando um código-fonte de mecanismo único em todas as versões do Windows). A versão portada do WebKit funciona de maneira diferente no WinXP e nas versões mais recentes do Windows:

• Eu tive que abandonar as ferramentas do novo DirectX (d3d11) em favor do antigo DirectX9 (d3d9) e adaptar seus arquivos de cabeçalho à versão mais nova do SDK.
• As funções do novo SDK, quando executadas em novas versões do Windows, são chamadas no endereço (obtido por meio de GetProcAddress ).
• Para transferir dados entre fluxos no mecanismo, o WinXP usa o armazenamento local Thread, em novas versões - armazenamento local Fiber.

Sumário

Portanto, agora em nossa plataforma 1C: Enterprise a partir da versão 8.3.14 (versão final de 2018), o HTML será suportado no nível mais alto - HTML5, OpenGL, etc. Tanto a quantidade quanto a qualidade das passas que podem ser tomadas nas decisões em nossa plataforma são limitadas apenas pela imaginação do desenvolvedor. E, no entanto, é claro, o sistema operacional do cliente - no WinXP, muitos pães saborosos em HTML5 não funcionam, por razões óbvias.

Agora, os aplicativos Windows na plataforma 1C: Enterprise poderão mostrar isso:



Mas, usando os "benefícios" do HTML em soluções de aplicativos, não esqueça o bom senso. O uso de HTML é apropriado e recomendado para tarefas especializadas (exibindo ajuda, técnicas, descrições de produtos, ...), mas não para implementar tarefas de lógica de negócios (entrada / saída de informações estruturadas). Para fazer isso, você precisa usar os mecanismos de interface 1C: Enterprise padrão que fornecem suporte automático para direitos de acesso, gerenciamento de funcionalidade, adaptação ao fator de forma do dispositivo, suporte para configurações do usuário e o trabalho de muitos outros mecanismos, sem os quais a operação completa de um aplicativo de negócios se torna quase impossível.