...

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

Restrições (Revisar)

...

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.