TOTVS HTML Framework

Árvore de páginas

Versões comparadas

Versão antiga 28

changes.mady.by.user Thiago Almeida de Souza Weber

Gravado em

comparado com

Nova versão Atual

changes.mady.by.user Usuário desconhecido (jhosef.carvalho)

Gravado em

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Geral

O TOTVS | HTML Framework foi concebido para tratar apenas a camada de interface das aplicações; confiando que os produtos por trás da interface irão conceder a infraestrutura e a implementação mínima dos serviços para utilização do framework. Desta forma cada produto deverá prover os seguintes itens quanto a:

  • Infraestrutura: Um container web independente de plataforma. Neste caso podemos considerar:

    Observação: Os servidores web citados são exemplos dos containers, sendo possível utilizar outros servidores web.

    Em relação a segurança de contexto da aplicação, cada aplicação deverá ser responsável pela sua implementação devido a diversidade de plataformas e diferença entre os padrões de cada produto.

  • Serviços:  Cada produto deverá prover os serviços para IDE e para a aplicação a ser construida; Para correto funcionamento da IDE cada produto deverá prover o seguinte serviço:

     

    • getAvailableServices: Este serviço deverá estar disposto como REST utilizando o protocolo GET e retornar um JSON contendo um lista de serviços disponiveis. O path para acesso ao serviço deverá ser: <url do serviço rest>/getAvailableServices

      • Parâmetros:

         

        • Entrada - name: nome do serviço para ser utilizado como filtro, default é uma String em branco.

        • Entrada - start: indica quando registros já estão disponíveis em tela, default é 0.

        • Entrada - limit: indica a quantidade de registros a serem retornados a partir do indicado de inicio (start), default é 100.

        • Saida - uma lista de serviços disponíveis, está lista deve ser composta por:

           

          • id: identificador do serviço;

          • name: nome do serviço, por convenção deve ser utilizado o nome do contexto em qual o serviço se encontra;

          • description: descrição do serviço;

          • descriptor: URL contendo o descritos WADL ou WSDL do serviço em questão;

          • type: tipo de serviço: REST ou SOAP 

             

      Bloco de código
      languagejava
      firstline1
      titleExemplofirstline1
      linenumberstrue
      collapsetrue
      // URL do Serviço: http://localhost:8380/html-service/rest/framework/getAvailableServices

// Assinatura do método getAvailableServices:
@GET
@Path("/getAvailableServices")
@Produces(MediaType.APPLICATION_JSON)
public List<AvailableServices> getAvailableServices(
	@QueryParam("name")  @DefaultValue("")      String  name,
    @QueryParam("start") @DefaultValue("0")     int     start,
    @QueryParam("limit") @DefaultValue("100")   int     limit) throws Exception;

// Assinatura do AvailableServices:
@XmlRootElement(name = "AvailableServices")
@XmlAccessorType(XmlAccessType.FIELD)
public class AvailableServices implements Serializable {

    @XmlElement(name = "id")
    private Long id;

    @XmlElement(name = "name")
    private String name;

    @XmlElement(name = "description")
    private String description;

    @XmlElement(name = "descriptor")
    private String descriptor;

    @XmlElement(name = "type")
    private String type = "REST"; // ou SOAP
}

// JSON gerado como retorno do método getAvailableServices:
[{
    "id":1,
    "name":"html-app",
    "description":"Serviços de gerenciamento da aplicação de referência html-app.",
    "descriptor":"/html-app/rest/application.wadl",
    "type":"REST"
}, {
    "id":2,
    "name":"html-sample",
    "description":"Serviços da aplicação de referência html-sample.",
    "descriptor":"/html-sample/rest/application.wadl",
    "type":"REST"
}]


      O WADL é a documentação padrão para os serviços REST assim como o WSDL está para os serviços SOAP. A especificação do WADL está disponível em: http://www.w3.org/Submission/wadl/

...

Compatibilidade  com Browsers

O TOTVS | HTML Framework suporta as ultimas versões de cada browser, mas especificamente a ultima e penúltima versão.

...

  • Chrome
  • Firefox
  • Safari
  • Opera (Somente para Windows e Mac OS)
  • Internet Explorer

    • Para o caso do IE 8 e 9, deve ser adicionada duas bibliotecas (RespondJS e HTML5Shiv) externas para permitir o funcionamento correto dos componentes. Conforme exemplo:

      Bloco de código
      languagexml
      firstline1
      titleExemplofirstline1
      linenumberstrue
      collapsetrue
      <!DOCTYPE html>
<html lang="pt-br" class="no-js">
<head>
    
    ...
    
    <!-- HTML5 shim and Respond.js IE8 support of HTML5 elements and media queries -->
    <!--[if lt IE 9]>
      <script src="js/libs/html5shiv.min.js"></script>
      <script src="js/libs/respond.min.js"></script>
    <![endif]-->

</head>
<body></body>
</html>

Restrições 

  1. A tecnologia ou plataforma escolhida para prover os serviços do produto não são tratadas pelo TOTVS | HTML Framework. Desta forma o framework se encarrega apenas dos quesitos de interface;
  2. A forma como os produtos irão prover os serviços também são de responsabilidade dos produtos. Desde que o retorno dos serviços utilize a especificação REST e a estrutura de retorno seja JSON;

Aplicação

Cada produto deverá seguir um padrão especifico para utilização do framework, para cada nova aplicação deverá possuir ao menos uma aplicação centralizadora a qual irá conter os arquivos de core para utilização do TOTVS | HTML Framework.

Esta aplicação centralizadora por sua vez deverá prover as dependências padrões do TOTVS | HTML Framework (bibliotecas, componentes, estrutura, etc...) além de alguns artefatos opcionais de acordo com o padrão de arquitetura desenhado para o projeto/produto.

Aplicação Centralizadora

Este tipo de aplicação podemos considerar como sendo uma aplicação raiz, pode até ser feito uma analogia com uma aplicação de menu a qual irá direcionar para as demais aplicações e estas por sua vez irão consumir recursos do menu (aplicação centralizadora).

...

  • assets: contem os arquivos de acessórios como css imagens e outros desde que seja comum a todas as aplicações e/ou necessário para aplicação centralizadora;

    • css: destinado a arquivos de css;

    • fonts: destinado a arquivos de fontes para labels;

    • img: deve conter as imagens e outros apetrechos visuais para as aplicações;

  • fluig:  deve conter uma página inicial customizada para abertura das views a partir do Fluig;

  • html: contem as páginas para a aplicação centralizadora;

    • templates: deverá conter os arquivos de template para os componentes do framework;

      • fields: diretório para armazenamento específicos dos templates para os componentes de formulário;

  • i18n: deverá conter um arquivo único de tradução para a aplicação centralizadora.

  • js: contem os arquivos JavaScript para aplicação;

    • libs: diretório para armazenamento das bibliotecas JavaScript utilizadas pelo framework e demais aplicações;

    • setup: deve conter os arquivos de customização e estruturação da arquitetura das aplicações.

    Observação: A estrutura aqui definida serve como base para os direcionamentos de URL e abertura dos telas. A alteração desta estrutura pode originar alterações dentro das funcionalidades de roteamento, internacionalização e configuração de estados da aplicação.
Aplicação Convencional

As aplicações convencionais possuem um estrutura reduzida e focada apenas nas views que devem fornecer. Para exemplificar vamos partir do principio que estamos no diretório raiz da aplicação dentro do container web, sendo assim temos a seguinte estrutura:

...

Neste caso os diretórios e subdiretórios: assets, libs, css e outros; irão existir somente caso seja necessário utilizar algum recurso que não seja provido pela aplicação centralizadora.

Arquitetura

A arquitetura pode ser resumida de acordo com a imagem a baixo:

...

  • Tela.*.html: são os arquivos HTML da tela que serão mostrados no browser para representar cada state configurado anteriormente, quando a tela é mostrada para o usuario, o controller configurado no state é associado com essa tela automaticamente.

Deploy dos ERPs com o FLUIG

Image Added

A figura acima ilustra o cenário de um cliente com vários produtos e com acesso externo.

O PROXY nos ERPs permite o Cross-Domain entre as páginas HTML e os serviços REST providos pelos servidores de aplicação dos ERPs.

O PROXY REVERSO na LAN permite o Cross-Domain de páginas vindas entre os servidores HTML, do FLUIG e dos ERPs.

O PROXY REVERSO na DMZ é um requisito de segurança de infra-estrutura, quando é necessário expor o FLUIG e/ou os ERPs à Internet.

O FLUIG passa a acessar os serviços SOAP e/ou REST via o serviço de PROXY dos servidores HTML dos ERPs.

 

Equipes de Desenvolvimento

O TOTVS HTML Framework tem como objetivo único fornecer componentes e ferramentas de desenvolvimento de interface WEB (e Mobile), e limita-se exclusivamente à esta camada, que deve ser comum à todos os produtos da empresa.

Componentes pertencentes a camada logo abaixo, neste caso no servidor de aplicação, são de responsabilidade das equipes de framework/foundation de cada produto/plataforma de desenvolvimento.

Componentes específicos de um determinado segmento devem ser fornecidos e mantidos pelas respectivas equipes de desenvolvimento.