Camada de Visualização (Commons UI)
Conforme citado na seção de contextualização, a arquitetura proposta visa eliminar os problemas identificados em diversos projetos já executados, onde foi possível identificar a falta de padronização para realizar tarefas comuns no processo de desenvolvimento. Assim, temos como objetivo principal desta seção o detalhamento do projeto Commons UI que provê soluções para que seja possível equalizar, o que era previamente caótico, em uma atividade produtiva e padronizada. Em busca deste equalizador, foram estudadas soluções e padrões de mercado que balizam o desenvolvimento de software atualmente.
O framework AngularJS foi a opção escolhida após compararmos as soluções disponíveis. A possibilidade de extensão do framework nos proporciona a flexibilidade necessária para criar componentes personalizáveis que atendem plenamente as nossas necessidades. Além do benefício da extensibilidade, o framework possui uma documentação detalhada, comunidade participativa e componentes genéricos já desenvolvidos e inclusos na solução. Para maiores detalhes, consulte o guia para desenvolvedores do AngularJS.
Esta seção será dividida em três grandes tópicos: estrutura, detalhamento da estrutura e melhorias futuras. O primeiro tópico aborda a organização do projeto e responsabilidade de cada componente, descrevendo breviamente o comportamento dos componentes que compõem a estrutura do projeto. O tópico de detalhamento mostra detalhadamente o funcionamento dos componentes, a comunicação entre diferentes componentes e sua utilização pelo desenvolvedor. E por fim, o tópico de melhorias, no qual irá listar diversas melhorias que podem ser realizadas pela equipe de arquitetura para facilitar na construção de novos componentes e manter a atual estrutura da arquitetura estável.
O diagrama abaixo ilustra, de forma macro, a comunicação e organização dos componentes na atual versão da arquitetura.
Estrutura
Conforme a imagem abaixo, o projeto é estruturado por pastas, cada qual refletindo a responsabilidade de seus componentes. Como este projeto é inteiramente composto de arquivos Javascript, não existem dependencias de outros projetos.
| Pasta | Descrição |
|---|---|
| Directives | Contém todas as diretivas customizadas que estão disponíveis para uso dos desenvolvedores. Estas diretivas foram criadas para atender os requisitos da arquitetura e não interferem nas diretivas do AngularJS. |
| Filters | Contém filtros customizados que estão disponíveis para uso dos desenvolvedores. Estes filtros foram criadas para atender os requisitos da arquitetura e não interferem nas diretivas do AngularJS. |
| Lang | Contém funções utilitárias, não disponibilizadas pela API Javascript nativa dos navegadores. Podemos citar como exemplo as funções: each e curry. |
| Providers | Contém providers utilizados internamente pela arquitetura para evitar alto acoplamento entre as diretivas. |
| Services | Contém serviços declarados através da API do AngularJS que estão disponíveis para injeção e podem ser utilizados pelos desenvolvedores para padronizar e agilizar o processo de desenvolvimento de novas funcionalidades. |
| Style | Contém arquivos .css para padronização de elementos de UI. |
| Vendor | Contém as bibliotecas previamente citadas neste documento já minificadas. |
Além das pastas que agrupam os componentes por responsabilidade, o projeto possui o arquivo treelayer-bootstrap que provê um módulo onde estão listadas todas as dependencias. Este arquivo existe para que quando necessário, projetos especifiquem como dependência apenas este módulo e todos os componentes estarão automaticamente associados ao projeto.
Providers
Nesta seção abordaremos como cada provider disponível na arquitetura funciona internamente. Providers são objetos expostos para toda a aplicação, passíveis de injeção e podem ser utilizados dentro de um bloco de configuração do AngularJS. Para maiores informações leia a documentação oficial sobre providers.
Message Provider
A arquitetura utiliza apenas um provider, o MessageProvider. Este é um componente do AngularJS que pode ser configurado em um bloco de configuração, como por exemplo URLs de validação e mensagens, e oferece uma interface pública para componentes do AngularJS (controllers, directives, filters). Abaixo temos um exemplo da utilização do MessageProvider na configuração de URLs de validação e mensagens.
Tem como responsabilidade buscar, armazenar mensagens (de validação ou descrição) e controlar o fluxo utilizando-se de listeners para avisar outros componentes de que a a busca de mensagens foi realizada com sucesso.
Busca de Mensagens
A partir de uma chamada da principal directive, tl-object, é disparada uma requisitção HTTP para um método genérico da arquitetura para buscar mensagens internacionalizadas. Esta funcionalidade baseia-se no nome do objeto passado para a directive tl-object para buscar as mensagens. Mensagens são compostas de labels, descriptions, validations, etc.
As URLs previamente configuradas ao inicializar um aplicação AngularJS servem como endpoint para esta funcionalidade.
Armazenamento de Mensagens
Após a resposta do servidor, se ocorrida com sucesso, todas as mensagens são armazenadas em cache no formato raw, ou seja, sem alteração nenhuma. Assim que possível outras diretivas irão processar estas mensagens e preencher outras áreas de cache deste provider.
Controle de Fluxo
Logo após a busca de mensagens e a resposta do servidor, todas as diretivas que se registraram neste provider serão avisadas que há mensagens não processadas. A directive tl-ref iniciará sua execução preenchendo o cache referenceMessages a com uma nova estrutura, oriunda do cache no formato raw.
Se você possui dúvidas quanto a funcionalidade das directives citadas nesta seção, leia as seções de directives Object e Ref.
Services
Nesta seção abordaremos como cada service disponível na arquitetura funciona internamente.
Diretivas
Nesta seção abordaremos como cada directive disponível na arquitetura funciona internamente.