TOTVS HTML Framework

Árvore de páginas

Versões comparadas

Versão antiga 12

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 RemovedImage 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.

...

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 Removed

Descrever item a item ?!

Getting Started

Adicionar um screencast para o primeiro Hello World?

Aplicação de Referência

Está disponível para download uma aplicação de referencia utilizando todos os conceitos e recursos implementados. Esta aplicação está com o código fonte devidamente documentado para facilitar o entendimento.

  • Download (Não esquecer de adicionar a aplicação antes de liberar o projeto)
Instalação

Para utilização da aplicação de referencia basta realizar o download e extrair o conteúdo do zip no deploy do container web. Esta aplicação possui um alguns serviços REST implementados em Java para exemplificar alguns conceitos, sendo necessário que o container web seja um Tomcat ou outro com suporte a Java.

Observações

...

  • data: objeto genérico que pode conter um único objeto ou uma lista de objetos;
  • length: utilizado normalmente para quando o objeto contido no atributo 'data' é do tipo lista e possui paginação; neste caso a propriedade length recebe a quantidade total de registros da consulta;
  • message: lista de mensagens de erro ou informativo resultante do serviço;
    • code: titulo ou código da mensagem;
    • type: tipo da mensagem, podendo assumir: danger, error, warning, question e info;
    • detail: detalhamento ou texto da mensagem.

...

  • <contexto da aplicação>/<contexto da view>/html/<view>/<view>.js

...

  • <contexto da aplicação>/<contexto da view>/i18n/translations.js

 

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.

 

...