Estudei Ruby on Rails com Wendell em meados de 2008 e, desde então fico insatisfeito e desmotivado com a baixa produtividade da plataforma JEE. Já estava no momento de experimentar algo novo no trabalho, mas mudar para Rails era uma decisão muito radical para o momento. Foi então, que há cerca de dois ano decidi estudar Grails e aplicá-lo no trabalho.
Grails é um framework Web escrito em Groovy que promete trazer mais produtividade ao ambiente JEE. Como Groovy e Java possuem o mesmo código de execução (bytecode) a adoção do novo framework seria mais simples e menos traumática. Além disso, é possível usar a sintaxe Java em Groovy, o que diminui a curva de aprendizado da linguagem.
O primeiro projeto que decidimos implementar em Grails foi um pequeno sistema para cadastramento dos feras (disponível em http://www.ufpb.br/feras) aprovados no vestibular da UFPB. Sumariamente o sistema possui dois perfis: aluno e administrador. O primeiro acessa o sistema para atualizar dados pessoais e imprimir um comprovante de cadastro, e o segundo usa o sistema para confirmar quais feras entregaram o comprovante (com os demais documentos comprobatórios) no setor responsável pelo cadastramento dos alunos.
O projeto foi concluído no tempo estimado e já passou por várias atualizações desde então. Na última delas, precisei alterar um campo de entrada do formulário do tipo password para o tipo text, pois os parâmetros cpf e senha são usados para acessar o sistema e, como a senha padrão do fera é a data de nascimento dele, optamos por deixar o sistema mais intuitivo informando ao usuário que ele deveria digitar sua data de nascimento.
Para receber os dados do formulário gsp (Groovy Server Pages) foi criada a classe Command (http://grails.org/doc/latest/guide/single.html#commandObjects) abaixo:
class LoginCommand {
String login
String password
static constraints = {
login(blank:false, nullable:false)
password(blank:false, nullable:false)
}
}
No entanto, o password foi substituído pela data de nascimento do fera no formato (DD/MM/YYYY) e para tanto foi necessário alterar a classe LoginCommand e sobreescrever o getter que retornava o password, para que as barras digitadas pelo usuário fossem removidas. Inicialmente o getter foi implementado como descrito abaixo:
def getPassword() {
return this.password?.replaceAll('/','')
}
Entretanto, o método não estava sendo invocado. Após algumas pesquisas descobri (http://colinharrington.net/blog/2009/01/gorm-override-a-setter-on-a-grails-domain/) que a assinatura do método deve ser a mesma do correspondente JavaBean, ou seja, o código correto é:
String getPassword() {
return this.password?.replaceAll('/','')
}
E tudo voltou a funcionar! Mas por que o código inicial não funcionou? A resposta é simples: esquecendo alguns detalhes, Groovy é Java e, por isso obedece às regras de sobreescrita de um método, e uma delas diz:
Os argumentos devem ser do mesmo tipo e retornar tipos compatíveis.
Por padrão não é necessário escrever os métodos getters e setters das classes de domínio Groovy, pois o compilador os cria automaticamente. Assim, nossa classe LoginCommand possui os getters e setters das variáveis de instância login e password, ambas do tipo String. Ao tentarmos implementar o método getPassword usando a palavra chave def, descartando o método gerado automaticamente, criamos outro método com assinatura public Object getPassword(), pois os tipos de retorno não são compatíveis. Dessa forma, o método getter padrão não existe mais e o mecanismo do framework Grails, que liga o formumlário gsp à classe Command, passa a não funcionar.
