O documento discute o desenvolvimento de aplicações ricas para internet (RIA) usando Javascript. Apresenta Javascript como uma opção viável para RIA, ao contrário do que sugere o senso comum. Explica como usar Orientação a Objetos, organização de código, documentação e testes para superar as limitações percebidas da linguagem. Defende o padrão MVVM e as bibliotecas jQuery e Knockout para separar as responsabilidades e facilitar a manutenção do código.
2. O que se espera de RIA?
- Interação
- Velocidade
- Workflow fluído
- O que há de melhor em aplicações
desktop
3. Atualmente, existem duas opções para
RIA:
• Desenvolver o comportamento em
uma tecnologia nativa(Javascript)
• Desenvolver o comportamento em
uma tecnologia externa(Flash,
Silverlight, JavaFX, etc)
4. RIA = Spaghetti?
Senso comum sobre Javascript:
•Limitada
•Desorganizada
•Difícil de testar
•Incompatível entre browsers
diferentes
5. Derrubando o mito
Orientação a Objetos(numa linguagem Orientada a Protótipos):
// objeto estático
var LATIDOS = {
"pastor alemão": "AUFF!",
"pincher": "AU!"
}
// classe pai
var Animal = function() {};
// classe filha
var Cachorro = function(raca) {
this.raca = raca; // Atributo
this.latir = function() { console.log(LATIDOS[raca]); }; // método
};
Cachorro.prototype = new Animal(); //Herança
var fido = new Cachorro("pastor alemão");
fido.latir(); //imprime "AUFF!"
6. Organização
-Cada classe pode residir num arquivo separado, basta criar um padrão para
a hierarquia de pastas(ex.: /models,/helpers,/lib,etc)
- Em produção, devido a uma limitação da web, browsers podem requisitar
de 1 a 4 arquivos no máximo por conexão.
- Solução: Em produção, juntar todos os arquivos em um só, se houver
necessidade.
lib/jquery.js
helpers/validations.js
models/animal.js
models/cachorro.js
application.js
7. Documentação
- Desenvolvedores detestam escrever ”manual do sistema”
- Mal necessário?
- Comentários de código são suficientes
- Padrão JAVADOC
- JSDoc-toolkit
8. JAVADOC
/**
* Classe que segue o design pattern IdentityMap, útil para guardar um cache local de objetos.
* @name IdentityMap
* @class
*/
var IdentityMap = function() {
function I() {};
I.prototype = new Array();
/**
* Comparação entre objetos pelo valor.
* @name IdentityMap#find
* @param id Um id único para o objeto da request
* @param params Objeto contendo os parâmetros da request
* @function
*/
I.prototype.find = function(id,params) {
return $.grep(this,function(d) {
return d.id === id && ko.utils.stringifyJson(d.params) === ko.utils.stringifyJson(params);
})[0];
};
return new I();
};
9.
10. Como testar Javascript
- Desde que haja uma separação clara do comportamento da página e dos elementos da página,
testes unitários são uma excelente opção.
Conheça a biblioteca qUnit:
test("Este teste deve ser positivo", function() {
ok(true, "Teste ok");
});
test("Este teste deve quebrar", function() {
ok(false, "Teste quebrado");
});
11.
12. Incompatibilidades
-A especificação do Javascript(e do
HTML e CSS) é regida pelo W3C,
mas cada browser implementa
diferente.
-Como resolver os conflitos?
- jQuery salva o dia!
13. jQuery = Simplicidade +
Elegância
- Simplifica o acesso ao DOM
- Minimiza conflitos entre browsers
diferentes
14. JS puro x jQuery
O que você prefere?
JS - document.getElementById("example")
ou
jQuery - $(“#example”)
JS – var d = document.getElementById("example");
d.setAttribute('type', 'text');
d.setAttribute('name','maildrop[]');
d.setAttribute('autocomplete','off');
Ou
jQuery - $(“#example”).text(“type”).attr(“name”,”maildrop[]”).attr(“autocomplete”,”off”);
Ou ainda
jQuery - $(“#example”).attr({text:’type’,name:’maildrop[]’,autocomplete:’off’});
16. Então você passa a usar
jQuery...
...e descobre que:
-As alterações manuais de conteúdo continuam
- Continua difícil mapear as dependências de
alterações
- $() pra todo lado
18. Por que tantas linhas?
-Ocultação manual de conteúdo
- Revelação manual de conteúdo
- Adição manual de conteúdo
- Subtração manual de conteúdo
19. O que outros fazem?
Existem dois tipos de framework web:
- Os que mantém o estado(stateful)
Ex.: JSF, Wicket, etc.
- Os que não mantém o estado(stateless)
Ex.: Struts, Play!, VRaptor, etc.
Ambos com vantagens e desvantagens para alcançar o
mesmo objetivo.
20. Caminhando no meio
Solução híbrida: MVVMC(Modelo-View-View
Model-Controller)
- Isola-se totalmente a View de seu
comportamento(View Model)
- O comportamento torna-se facilmente testável
- O Controller emagrece em responsabilidades
21. Buscando o dream team
da web
- Lingua franca da web(HTML/CSS/JS)
- Formatos padrões de dados na web(XML/JSON)
- Comunicação padrão com o servidor(AJAX)
- Se os padrões forem respeitados, tanto faz o backend
22. Conheça Knockout.js
- Biblioteca javascript para MVVMC
- Atualização automática de elementos
vinculados a variáveis
- Busca automática de dependências
25. Case real
Fale Conosco UMC Externo
- Com jQuery e Knockout(- de 200 linhas)
- Fácil manutenção, dependências
rastreadas automaticamente, fácil de
testar.
26. Separação de
Responsabilidades
- O que o MVVMC conseguiu:
- Emagrecer o Controller. Agora ele autoriza e observa o
Modelo.
- Permite utilizar a camada de persistência que você achar
melhor, sem se preocupar com problemas em outras partes
do sistema.
- Permite utilizar a linguagem que você achar melhor, sem se
preocupar com problemas em outras partes do sistema.
28. Resumo da ópera
-O comportamento do sistema está no lado cliente(View +
View Model), onde a interação
ocorre(HTML/CSS/JS(jQuery + Knockout).
- O Modelo contém as regras de negócio.
- O Controller autoriza interações e observa o Modelo.
FIM