terça-feira, 31 de março de 2009

[snippet] Adicionando inputs ao pressionar enter

Inserindo mais inputs no enter:

adminEssays.form = {};

adminEssays.form.addInput = function(target) {
var nextInput;
inputs = $("#category-subs").children('input');
if(inputs.length == 0) {
nextInput = 0;
}
else {
nextInput = 0;
for (var a = 0; a < inputs.length; a++) {
id = parseInt(inputs[a].id.substr(21));
if (id >= nextInput) {
nextInput = id + 1;
}
}
}
id = "category-subcategory-" + nextInput;
html = "< input type='text' size='70' id='" + id + "' class='category-subcategory' name='subcategory[]' style='display:block'/>";
if(nextInput == 0) {
$('#category-subs').html(html);
}
else {
$(target).after(html);
}
$(".category-subcategory").bind("keypress",adminEssays.form.inputEnter);
}

adminEssays.form.submitForm = function(id) {
JsonC.submitForSfAction('adminEssays/insertSubcategories',{},'form-insert-subcategories','form-insert-subcategories-loading');
}

adminEssays.form.inputEnter = function(evt) {
if(evt.keyCode == 8 || evt.keyCode == 46) {
var tgt = $(evt.currentTarget);
if(tgt.val() == '') {
if( $('#category-subs').children().length > 1 ) {
var inputToFocus;
if(tgt.next().length > 0) {
inputToFocus = tgt.next()[0];
}
else {
inputToFocus = tgt.prev()[0];
}
tgt.remove();
inputToFocus.focus();
}
return false;
}
}
if(evt.keyCode == 13) {
prox = $(evt.currentTarget).next().length;
if(prox > 0) {
$($(evt.currentTarget).next()[0]).focus();
}
else {
adminEssays.form.addInput(evt.currentTarget);
$($(evt.currentTarget).next()[0]).focus();
}
}
};

quinta-feira, 5 de março de 2009

Criando uma estrutura de arvore para o jsTree


public function createTreeStructure($dir) {
$ar = array(
'attributes'=>array('id'=>'node-root'),
'data'=>'TESTS',
'children'=>$this->createChildren($dir)
);
return $ar;
}

public function createChildren($dir) {
static $n=0;
$it = new RecursiveDirectoryIterator($dir);
$arAll = array();
foreach($it as $file) {
if(strpos($file,'.svn') !== false) continue;
$ar = array(
'attributes'=>array('id'=>'node-'.$n),
'data'=>$file->getFilename()
);
if($file->isDir()) {
$ar['children'] = $this->createChildren($file);
}
$arAll[] = $ar;
}
return $arAll;
}

O valor de longo prazo de um software é diretamente proporcional a qualidade do código.

Já imaginou se todo gerente e toda organização tivessem esta consciência? Seria bem mais fácil de fazer um bom trabalho. Pena que de maneira geral o brasileiro ainda não tem visão de médio e longo prazo.

O que acontece é que o custo de desenvolvimento de um software, se for bem feito, pode reduzir muito o custo do próximo pelas bibliotecas geradas. E também a manutenção em bom código é muito mais fácil.

segunda-feira, 2 de março de 2009

Module Pattern

Existem diversos bons artigos na net a este respeito. Aqui não vou tentar explorar todas as possibilidades deste padrão. Pretendo apenas dar uma explicação básica do seu funcionamento.

O "Module Patern" tira proveito dos "closures" do JS. Quando uma função declara variáveis dentro dela e também declara outras funções ou objetos estes objetos e funções têm acesso às variáveis declaradas. Ex:


pessoa = function(nome,telefone) {
var nome = nome;
var telefone = telefone;
this.nome2 = "nome2 - " + nome;
return {
mostra: function() {
document.writeln('Nome:' + nome + '< br / >');
document.writeln('Telefone:' + telefone + '< br / >');
}
};
}


A função "mostra" do objeto retornado no código acima, por estar definida dentro da função pessoa, tem acesso às variáveis "nome" e "telefone".

O interessante é que mesmo depois de a função pessoa ter sido executada, o objeto continua tendo acesso àquelas variáveis. Isto quer dizer que se chamarmos:


p = pessoa('joao','3344 5678');


vai acontecer o seguinte:

1 - a função pessoa será executada declarando as variáveis "nome" e "telefone"
2 - ela vai retornar um objeto, definido por um código JSON, com um método mostra()
3 - este método mostra vai ter acesso às variáveis "nome" e "telefone" já declaradas.
4 - como a função já foi executada, não temos mais como mexer nas variáveis "nome" e "telefone" a não ser pelo "mostra".
5 - com isso criamos um escopo "privado" para as variaveis definidas.

O mesmo método pode ser usado para retornar uma função:


mostraLista = function(nome,telefone) {
var lista = {'segredo1':'noite','segredo2':'dia'};
return function() {
for(i in lista) {
document.writeln(i + ':' + lista[i] + '< br / >');
}
}
}();


Neste caso repare que depois da declaração já executamos a função. Com isso fazemos o seguinte:

1 - a função é executada declarando o objeto "lista";
2 - ela retorna uma outra função, que fica atribuida a "mostraLista"
3 - esta função retornada fica com acesso "privado" a variável "lista"

assim podemos chamar


mostraLista();


para que este método seja executado com acesso ao objeto. Porém não podemos acessar diretamente por "mostraLista.lista" pois este objeto não existe, o que existe é o acesso dele à variável da função que já foi executada. Caso você queira experimentar, veja que o valor será igual a "undefined".

terça-feira, 17 de fevereiro de 2009

Chamada a métodos no Js.

Este post é do tipo "um código vale mais do que mil palavras", assim sendo dificilmente você vai aprender alguma coisa apenas vendo o código escrito. Porém se você pegar cada pequeno bloco de código e rodar (O que pode ser feito, acredito, até com o firebug), você vai provavelmente entender os tipos possíveis de chamada em js e o que acontece com a palavra-chave "this" em cada um dos tipos. Podemos entender isso como qual o escopo no qual a função é rodada.

Vale uma ressalva de que na maioria, o conteúdo que escrevo aqui, aprendi no excelente livro que recomendo: Javascript: The Good Parts - O'REILLY, Douglas Crockford.

Bão, ao código...

O Js é uma linguagem atípica, herança por "prototype", sem classes, funções são objetos, vinculação tardia da palavra chave "this", etc... Por conta disso muita gente (eu inclusive) que começa a trabalhar com ele não entende nada. Assim vejo que é importante esclarecer aspectos "simples" da linguagem, como o que acontece quando chamamos uma função.

Aqui vão exemplos de quatro tipos de chamada:

Chamada á Função

// quando uma função não pertence a nenhum método...
function ola() {
document.writeln('ola
');
// o this neste caso é vinculado ao objeto global.
document.writeln(this);
}
ola();

####### com funções internas
/*
já no caso da função estar dentro de uma outra é necessário
uma "solução de contorno" para ter acesso às propriedades da externa.
*/
var ola2 = function() {
var that = this;
this.texto = "ola";
var fala = function() {
document.writeln(that.texto + "2
");
// segundo o livro, se usasse this direto aqui dentro não
// funcionaria pois ele ficaria vinculado ao objeto global.
// mas no exemplo abaixo, funciona.
document.writeln(this.texto + "---2
");
this.texto2 = 'aaaaaa';
}
fala();
document.writeln('texto2:' + this.texto2 + "
");
}
//ola2.fala(); -> daria erro pois não foi ligado ao this de ola2, é apenas funçao interna.
ola2();


Chamada ao Construtor
* esta maneira é indicada como a "pior dos dois mundos", pois imita uma linguagem com classes, mas não tem, e não deixa claro o uso do "prototype".

var Pessoa = function(nome) {
this.nome = nome;
}
/*
chamada ao construtor:
um novo objeto é criado com um link escondido para o valor do prototype da função
*/
p = new Pessoa("Fulano");
// veja que o método foi adicionado depois do objeto ser criado
Pessoa.prototype.escreveNome = function() {
document.writeln('+++++'+this.nome+'+++++
');
}
// procura em p, não tem, busca no Pessoa.prototype...
p.escreveNome();

p.escreveNome = function() {
document.writeln('-----'+this.nome+'-----
');
}

// procura em p, tem, usa o dele mesmo
p.escreveNome();

// remove o método do objeto p
delete(p.escreveNome);

// procura em p novamente, não tem pois foi apagado, usa novamente o do prototype
p.escreveNome();



Chamada ao Método

var o = {
linha:"",
aumentaLinha: function() {
this.linha += "---";
},
mostraLinha: function() {
document.writeln(this.linha + '0' + this.linha + '
');
}
}

// a vinculação tardia do "this" ao objeto ocorre apenas na chamada ao método.
for(var a = 0; a<30; a++) {
// duas maneiras de se chamar o mesmo método:
o.mostraLinha();
o['aumentaLinha']();
}

Chamada Com Apply

// apply é um método presente em todas funções de js.
// lembrando que as funções de js são objetos e podem ter métodos.
mostraNome = function(extra) {
document.writeln("this.nome: " + this.nome + "
");
document.writeln("param extra: " + extra + "
");
}
mostraNome();
document.writeln("valor de mostraNome.apply:" + mostraNome.apply + "
");
document.writeln("
");
/*
apply chamará o método mostraNome, vinculando o this ao objeto passado
no primeiro parâmetro. E e ele vai passar para o mostra nome o array
de parâmetros passado no segundo parâmetro.
*/
mostraNome.apply({nome:"João "},["pereira dos santos"])
//

sexta-feira, 13 de fevereiro de 2009

Chamando o callback do callback no jquery.

Me deparei com um problema ao precisar chamar o callback de vários nós de uma arvore para abrir um de cada vez no jquery. Ou seja, tem que abrir a raiz e passar o callback para abrir o filho, só que no callback de abrir o filho (callback do callback) chamar o callback de abrir o neto e assim por diante até onde for necessário.

Depois de fritar os miolos um poucos, resolvi da seguinte maneira:
Na "classe" TaskTreeC coloquei um método que inicializa algumas variáveis no escopo dela mesma e também define um lock:

  
this.openParents = function(id,callback) {
// para não dar conflito sendo chamada antes de terminar uma operação em andamento.
if(TaskTreeC.locked) return;
TaskTreeC.locked = true;
stack = [];
TaskTreeC.getParentStack(id,stack);
TaskTreeC.stack = stack;
TaskTreeC.recursiveIndex = 0;
TaskTreeC.openStackCallback = function() {
TaskTreeC.locked = false;
if(callback) callback();
}
TaskTreeC.openStack();
}


Primeiramente a função recebe um id de um item interno na arvore e chama getParentStack para poder pegar um array com os ids de todos os pais daquele item. Então armazena isso, cria um índice e um callback final que será chamado depois de todo o processo. Então ela chama o método openStack que faz o "serviço sujo".

No meu caso eu não preciso mostrar os elementos percorridos, mas sim abrir os filhos de cada um deles. Assim o método openStack ficou da seguinte maneira:


this.openStack = function() {
if(TaskTreeC.recursiveIndex < TaskTreeC.stack.length) {
id = TaskTreeC.stack[TaskTreeC.recursiveIndex];
TaskTreeC.recursiveIndex++;
if(TaskTreeC.getChildren(id).length) {
// pega o div que tem os filhos...
node = $('#node-content-'+id);
if(node.is(':visible')) {
// se já estiver aberto, segue em frente sem fazer nada.
TaskTreeC.openStack();
}
else {
// mostra com um tempo para o browser renderizar
var t=setTimeout(
"TaskTreeC.removeHiddenCache(id);"+
"node.show('blind',{},500,TaskTreeC.openStack);"+
"TaskTreeC.closeChildren(id);", // fecha os "netos"
200
);
}
}
else {
// chama o callback final
if(TaskTreeC.openStackCallback) {
var t=setTimeout("TaskTreeC.openStackCallback();",300);
}
}
}
else {
// chama o callback final
if(TaskTreeC.openStackCallback) {
var t=setTimeout("TaskTreeC.openStackCallback();",300);
}
}
}



Outros métodos usados:



this.getParentStack = function(id,stack) {
node = $('#node-'+id);
parentId = UtilC.getAttrUpTheTree( node.parent() , 'taskId' );
if(parentId) {
TaskTreeC.getParentStack(parentId,stack);
}
stack[stack.length] = id;
}

//UtilC
this.getAttrUpTheTree = function(item,attrName) {
//attrib = $(item).attr(attrName);
if(
$(item).attr(attrName) != undefined &&
( typeof $(item).attr(attrName) === 'string' )
) {
return $(item).attr(attrName);
}
else {
parentNode = $(item).parent()[0];
if(parentNode != undefined) {
return RouterC.getAttrUpTheTree($(item).parent()[0],attrName);
}
else return null;
}
}


OBS: acho que este código pode ser melhorado utilizando um module pattern, dê uma olhada no outro post.

quarta-feira, 11 de fevereiro de 2009

Dicas para escrita e uso de testes

Mantenha TODOS os testes passando e atualizados.

Toda vez antes de dar commit, faça um update e rode toda a suite de testes na sua máquina. Caso algum teste quebre, concerte o que precisa ser concertado antes de mandar para o repositório. Lembre-se que o código pertence a todos. Você pode consultar quem escreveu o código/teste, mas se tem um teste quebrado na sua máquina, é seu dever fazê-lo passar.

Deixar testes desatualizados no sistema pode gerar um efeito de bola de neve e mais na frente atrapalhar muito o desenvolvimento. Além disso manter testes quebrados no sistema certamente vai gerar mais erros e diminuir a confiança da equipe no processo de testes.

Escreva testes atômicos do ponto de vista do sistema.

Cada teste deve ser contido em si. Se o teste depende de algum estado do sistema, busque criar o cenário antes de rodar o teste. (ex: o teste do captcha para o login depende de ter a contagem limpa. Assim limpamos a contagem e rodamos o teste.) Também é uma boa prática limpar a casa depois de usar. Assim quando terminarmos de rodar o teste é importante excluir registros e informações que possam interferir em outros testes.

A classe de teste também deve ser o mais auto-suficiente possível. Não crie interdependências entre testes nem use métodos de outra classe te teste. Isso pode dar sérios problemas e dificuldades de manutenção.

Escreva testes atômicos do ponto de vista das funcionalidades.

A não ser se você estiver fazendo um teste de integração, não escreva testes que testam tudo de uma vez. Teste cada funcionalidade de uma vez. Isso deixa os testes fáceis de manter e os relatórios muito melhores. Lembre que a lista dos testes faz as vezes de uma especificação do negócio em muitos casos.

Por exemplo. Ao invés de escrever: "A listagem deve ser mostrada corretamente." Escreva algo como: "deve mostrar a soma dos valores no campo Valor Total", "deve paginar caso haja mais de 15 registros", etc...

Escreva testes rápidos

Busque manter os testes o mais rápido que for possível. Ao caminhar com o desenvolvimento teremos cada vez mais teste e não queremos que o build fique muito lento. Por isso precisamos economizar ao máximo em cada um dos testes.

No selenium evite expressões como "waitForText" ou "waitFor..." qualquer coisa que você não tenha certeza que não vai aparecer. Busque esperar por elementos certos na página e então dê um assert para ver se ele existe. Um bom elemento para usarmos em requisições de Ajax é o indicador de progresso.

Escreva testes que independam ao máximo da interface

Ao escrever um teste, busque testar elementos que você sabe que não vão ser alterados durante o processo de desenvolvimento. Por exemplo, ao invés de testar por uma mensagem, busque testar por elementos da página que provavelmente não vão mudar com o tempo. Ou então vc pode buscar pela constante que indica o valor da mensagem e não pela string.