Escopo

Esta seção aborda capacidade e limitações da atual versão da arquitetura e utiliza-se da aplicação modelo (Shield) como exemplo.

Capacidades

• Injeção de elementos HTML através de diretivas customizadas: adiretiva tl-key fornecida pela arquitetura tem como responsabilidade realizar as injeções de conteúdo e elementos, mutando-se conforme as tags em que é declarada. Esta diretiva esta intrinsecamente ligada as diretivas: tl-ref, tl-object e tl-context. Todas, em colaboração fornecem aos usuários da arquitetura: internacionalização e injeção de elementos HTML. Abaixo temos um exemplo ilustrativo de seu funcionamento.

<div class="inline-field-container">
	<input type="text" class="field-short" tl-key="name" ng-model="model.name" />
</div>

<div class="inline-field-container ng-scope">
	<label>Name</label>
	<input type="text" class="field-medium ng-pristine ng-valid" tl-key="users.name" ng-model="model.0x1.name" id="model.window.users.name.1" />
	<div class="description">User display name.</div>
	<div class="description" name="validation.name">May not be null.</div>
</div>

<div class="inline-field-container ng-scope">
	<label>Name</label>
	<input type="text" class="field-medium ng-pristine ng-valid" tl-key="users.name" ng-model="model.0x1.name" id="model.window.users.name.1" />
</div>

• Internacionalização
• Métodos genéricos para operações CRUD simples
• Data-binding na camada de View

• Injeção de dependências: aplicações podem disponibilizar serviços através da injeção de dependências pelo construtor da classe, tendo como único requisito que esta classe implemente uma interface que declare seus métodos públicos. Logo abaixo temos um exemplo desta implementação através de injeção de dependência utilizando construtores.

public interface IInjectable {
	void foo();
}
 
public class Injectable extends IInjectable {
	public void foo() { 
		System.out.println("foo");
	}
}
 
public class Injected {
	public Injected(IInjectable injectable) {
		injectable.foo();
	}
}

• Mapeamento objeto relacional
• Controle Transacional (limitado)
• Padronização de elementos UI através de classes CSS
• Widgets (calendário, modal panel)
• Serialização/Deserialização genérica (podendo ser customizada pelo desenvolvedor)
• Validação de POJOS de forma genérica
• Tratamento de erros de forma transparente
• Persistência transparente, idependente do framework de persistência utilizado (Hibernate, TopLink, AO)

Limitações

• Não suporta pilha de modal: temos na tela de Aplicações um relacionamento ManyToOne com Companhias. A tela de detalhe de aplicação constitui uma modal contendo todos os campos de aplicação e um combobox mostrando as companhias disponíveis. Com a atual arquitetura não é possível editar estas companhias a partir de uma aplicação. Para realizar esta operação seria necessário sobrepor a modal corrente de detalhe com uma modal de datalhe de companhia, controlando o fluxo de operações. A solução é abrir uma nova aba do navegador, realizar a operação e então continuar trabalhando com a aplicação em edição.

• Não é possível redirecionar o usuário para uma tela de detalhe de outro objeto: novamente tomando como exemplo a tela de Aplicações e Companhias, ao tentar editar uma companhia vinculada a aplicação corrent, devido a limitação de pilhas de modal, o usuário poderia ser redirecionado para a tela de detalhe da companhia. Esta operação não é suportada pois não é possível alterar as telas e abrir a modal de edição de companhia. A solução é abrir uma nova aba do navegador, realizar a operação e então continuar trabalhando com a aplicação em edição.

• Ainda não há implementação para lançar mensagens genéricas ou de negócio na tela de lista: nas telas de detalhe, no topo da modal, logo após a divisão de textos informativo é apresentado uma lista de erros de negócio (se houver erros, caso contrário nada é apresentado). Estes erros são comumente lançados como exceções do tipo BusinessException e tratados pela arquitetura. Esta implementação esta disponível apenas para telas de detalhe, a tela de listas ainda não possui tal funcionalidade.

• Série de valores para elementos do tipo combobox, multipicker etc, são informadas no arquivo de internacionalização, desta forma perdendo a possibilidade de oferecer configurações para o usuário: conforme o exemplo de código abaixo, séries são informadas diretamente no arquivo de propriedades que contem as mensagens de internacionalização. O formato {value | label} deve ser seguido para representar propriedades que envolvem séries. Como os valores são informados neste arquivo, não é possível implementar séries configuráveis pelo usuário final.
   

model.period.rule.values.1 = r|Revoked
model.period.rule.values.2 = g|Granted 

• Internacionalização é baseada no idioma do navegador e não em um perfil de usuário configurado: a arquitetura baseia-se no atributo Accept-Language do protocolo HTTP 1.1 para recuperar as configurações de idioma. Conforme podemos ver na imagem abaixo, os idiomas configurados no navegador são passados neste atributo, em uma formatação que envolve separar os idiomas por vírgula e outros valores padrões (facilitando a interpretação por um regex). Se o usuário deseja mudar o idioma, muda-se o idioma no navegador e atualiza-se a página.