TOTVS HTML Framework

Árvore de páginas

Versões comparadas

Versão antiga 9

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

    serviços para IDE e para a aplicação a ser construida

    ; ESPECIFICAR QUANDO ESTIVER DEFINIDO A CAMADA DE SERVIÇO POR PRODUTO.

Restrições (Revisar)

  • ; 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
      titleExemplo
      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.

Os Browser suportados sã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
      titleExemplo
      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;
  3. ETC...

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:

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

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

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

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:

Image Added

O usuário irá interagir com algum formulário e/ou recurso provido pela view (página HTML) esta por sua vez, irá acessar os serviços provenientes dos ERP's para esta view.

Observação: O TOTVS | HTML Framework se reserva a suportar apenas a camada de iteração do usuário com as views, das views com a chamada aos serviços; a construção e fornecimento dos serviços é de responsabilidade de cada produto.

No que diz respeito a interação do usuário com as views e das views com os serviços, temos a seguinte estruturação:

 

Image Added

Todo este modelo acima é baseado no RequireJS para realização do carregamento dos recursos e dependências sob demandada, evitando overloads desnecessários. Sendo assim, temos dois pontos de entrada:

  • index.html:Possui toda as camadas comuns a todas as views, uma vez que o AngularJS trabalha no modelo SPA o index.html normalmente fica com a responsabilidade de apresentar as abas, contexto do usuário logado entre outras informações;

  • fluig/index.html: Possui a mesma estrutura do index.html entretanto, está sobre o diretório fluig. Quando a view for aberta a partir do Fluig, este fluig/index.html deverá ser referenciado, pois o mesmo não deve possuir abas e/ou outras informações de contexto ou sessão; se resumindo a apresentar o conteúdo da ui-view.

Ao solicitarmos um dos pontos de entrada (index.html) o RequireJS irá se encarregar de iniciar o controle de dependências e bibliotecas através do main.js e iniciar o AngularJS Application através do index.js:

  • main.js: Arquivos de script simples de configuração do RequireJS no qual são declarados alias para outras bibliotecas e injeção de bibliotecas e componentes de acordo com necessidades de cada biblioteca/componente;

  • index.js: Centro da aplicação, neste é instanciado a aplicação AngularJS e os AngularJS Controllers necessários para funcionamento e gerenciamento das views. Neste também realizamos as demais configurações obrigatórias e opcionais para o TOTVS | HTML Framework:

    • events.js: arquivo simples para documentação e especificação de eventos a serem disparados pela aplicação centralizadora;

    • config-states.js: responsável por alterar a configuração de mapeamento de rotas do AngularJS para atender as necessidades da aplicação. As rotas estáticas devem ser adicionadas diretamente ao $stateProvider, as demais views da aplicação irão ser carregadas por exceção através do 'otherwise' do $urlRouterProvider.

    • config-http.js: alguns provedores de serviços (produtos) podem especificar um padrão para retorno de todas as chamadas de serviços. Nestes casos é preciso customizar o retorno das requisições HTTP para que fiquem adequadas ao Padrão REST;

    • factory-http-interceptors.js: Responsável por interceptar as requisições HTTP e realizar alguns controles como quantidade de chamadas realizadas ao servidor para apresentação da tela de carregamento, timeout de sessão, entre outros;

    • filter-i18n.js: definição de um AngularJS Filter para tradução, este deve ser implementado de acordo com as especificações e necessidade de cada aplicação ou produto.

    • service-notify.js: Especificação de um AngularJS Controller genérico para controle de notificações. Este serviço é responsável por apresentar mensagens e notificações ao usuário loagado no sistema.,

Alguns itens atrelados ao index.js podemos considerar como opcionais (itens em pontilhado conforme imagem acima). Estes itens por sua vez tem sua necessidade e existência condicionadas  a definição do produto para implementação da camada de serviço e definição de implementação dos demais itens requeridos. O modelo apresentado na figura acima foi o modelo adotado para a Aplicação de Referência deste framework.

  • components.js: bibliotecas de componentes de layout e input de dados para utilização nos programas; Normalmente adicionado como dependencia para o AngularJS Application;
  • totvs-resource.js: é um wrapper para o $resource para ser customizado futuramente, por exemplo para consumir SOAP ao inves de REST;
  • totvs-custom.js: implementa o serviço e diretivas para permitir que as telas HTML sejam customizaveis;

Para cada tela que será aberta, normalmente haverão os seguintes recursos:

  • Tela.js: Neste arquivo, que é o primeiro arquivo a ser carregado pela aplicação centralizadora, deverá conter a definição dos estados da Tela (view). Neste arquivo é realizado o relacionamento entre a URL (que será utilizada para chamar a view) e a view a ser iniciada; Este mapeamento é iniciado através da configuração realizada no states.js. Por padrão toda view é aberta no state de 'start'; Para isto é utilziado o componente AngularJS UI Router, o qual permite que sejam elaboradas views com sub-views, possibilitando o desenvolvimento de telas mais flexíveis;
  • Tela-services.js: script no qual são declarados os AngularJS Controllers e AngularJS Services para utilização na tela. Normalmente nas documentações de angular e exemplos na internet, o registro dos serviços, controllers e etc... são fetos diretamente na chamada do método correspondente utilizando funções anônimas. Para melhorar a legibilidade do código, definimos os todas essas funções em funções nomeadas e registramos todas ao final do arquivo;
  • 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.