TOTVS HTML Framework

Árvore de páginas

Versões comparadas

Versão antiga 27

changes.mady.by.user Mauricio Rogerio Obenaus

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)Safari
  • 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.