Cairngorm – Parte 3

Dando continuidade da série (parte 1, parte 2) esta terceira parte é referente à view. O original, de Steven Webster, no qual baseio esse estudo que conduzi com minha equipe, está aqui.

Os pontos mais interessante foram as best practices sugeridas, dentre elas uma que sempre sugeri: nomes semânticos para os elementos (componentes, telas e afins) – não me venha com nomes em código!; e a questão de disparar eventos, muito mais utilizado agora no Cairngorm 2 (e reformulado no Flex 2).

Architecting the View
1. User Experience deve:
– Representar o estado atual da aplicação
– Mostrar telas específicas
– Renderizar o model
2. Rich Internet Application
– Comunicação entre o usuário e a aplicação
– A melhor forma de comunicação é a bidirecional
– User Experience “fala” para o usuário renderizando a view de acordo com o estado
– User Experience “escuta” o que op usuário gostaria de fazer, e responde de acordo
– User gesture

Binding the Model to the View
1. Cairngorm garante que dados dinâmicos mostrados no MXML venham do ModelLocator, apenas.
2. Model notifica a View da mudança através do data-binding
– Desenvolvedor não precisa se preocupar em atualizar vários elementos para refletir mudança

Best Practices for MXML Development
1. Desenvolver pensando em componentes
– Fácil de criar componentes que extendem tags base
– Significado semântico (ex: detalhe do produto): facilidade de ler código, inclusive de outros
2. Acople os componentes mas não fixe-os
– Crie seus eventos que descrevam o que está ocorrendo no nível do usuário (não no nível do Flex)
– De “click=” para “ocorreu o evento productAdded”
– Clareza em pontos de integração