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:
  
  
  • IIS
  • Apache
  • Tomcat
  • JBOSS
  • Glassfish
    
    
  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; ESPECIFICAR QUANDO ESTIVER DEFINIDO A CAMADA DE SERVIÇO POR PRODUTO.

Restrições (Revisar)

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

Esta aplicação possui a estrutura de diretório mais complexa dentre as aplicações, para exemplificar vamos partir do principio que estamos no diretório raiz da aplicação dentro do container web, tomando esta premissa como base então temos a seguinte estrutura:

• 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:

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:

Desenhar como!?

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

• O exemplo possui uma aplicação centralizadora (html-app) e uma aplicação convencional (html-sample);
• A aplicação de referencia utiliza o um encapsulamento padrão para as chamadas REST, este encapsulamento prevê que todas as chamadas a serviços do produto irão prover um retorno no padrão:
  • 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.
  Devido a este padrão foi implementado uma configuração especifica para AngularJS (transformResponse) que permite manipular o retorno da chamada ao serviço e realizar o tratamento para o modelo padrão das requisições HTTP REST.
  Devido a esta padronização também foi possível utilizar o serviço de notificação e um interceptor para as requisições HTTP para manipulação automática das mensagem retornados pelos serviços.
• Utilizado a configuração de estados assumindo a estrutura de diretórios sugerida, neste caso obedecendo o padrão:
  • <contexto da aplicação>/<contexto da view>/html/<view>/<view>.js
• Já possui o modelo de internacionalização assumindo a estrutura de diretórios sugerida, neste caso obedecendo o padrão:
  • <contexto da aplicação>/<contexto da view>/i18n/translations.js
• Não foi utilizado o guia de estilos do Protheus 12 (liberar o SAMPLE com o guia correto);