Há uma maneira mais simples de se obter o mesmo resultado: def pesquisa() { // restante oculto render(contentType:"o mime type de sua escolha") { o...

Há uma maneira mais simples de se obter o mesmo resultado: def pesquisa() { // restante oculto render(contentType:"o mime type de sua escolha") { objetoQualquer } } Neste caso, o Grails irá percorrer todos os atributos deste objeto gerando o resultado no formato passado como valor para o parâmetro contentType. O problema desta abordagem é que você pode gerar documentos enormes acidentalmente caso haja um grafo complexo no que for renderizado. Não considero uma solução tão elegante, portanto. Outro problema é que quando estamos renderizando documentos, na prática estamos criando APIs. Dado que os atributos de nossas classes podem variar, esta variação poderia quebrar todos os clientes que dependam desta API que você acabou de criar. E ainda é possível simplificar ainda mais esta renderização. Como? Usando o marshalling automático de classes de domínio usando conversores especiais para os formatos XML e JSON. Trata-se de uma funcionalidade tão fácil de ser usada que nem há muito o que ser dito. Vamos aos exemplos: // Basta incluir esta instrução de importação de classes import grails.converters.* // e na sua action... // Como fazemos com JSON? def renderizarJSON() { // Como renderizamos para JSON uma // lista de categorias render Categoria.list() as JSON } // E para gerar XML? def renderizarXML() { render Categoria.list() as XML } Simples assim. :) Marshalling e unmarshalling Um termo que costuma confundir iniciantes é marshalling, possivelmente por não haver uma tradução direta para o português. Marshalling é o ato de estarmos gerando conteúdo em algum formato (XML, JSON) tendo como base um objeto. E o unmarshalling? O contrário: você irá instanciar objetos e popular todos os seus atributos tendo como base um documento em um formato específico. Content negotiation Muitas vezes você usará Grails para implementar APIs REST (ou SOAP). Se este for o seu caso, você ficará feliz pelo fato de o framework oferecer suporte a content negotiation. Isso significa que você pode fornecer diferentes representações do mesmo recurso, como XML, JSON ou uma página HTML que é o padrão. No caso, isso pode ser feito através do fornecimento do cabeçalho HTTP Accept pelo cliente, pedindo, por exemplo, que a resposta seja enviada no formato XML ou através da inclusão do parâmetro format na URL, como http://localhost:8080/concot/categoria?format=xml, que está pedindo que seja fornecido o conteúdo no formato XML. Por padrão, toda requisição HTTP feita à nossa aplicação costuma vir com o cabeçalho Accept, cujo valor default é */*. Para fornecimento no formato JSON, este precisaria vir com o valor application/JSON e, para XML, application/XML. A partir do Grails 2.0, você pode inclusive customizar a sua resposta de acordo com o formato pedido pelo cliente: request.withFormat { xml { // trate o formato XML aqui, // exatamente como faria se fosse um render } json { // JSON } '*' { // HTML padrão } } Integer, long, double, boolean etc.? Como preencher automaticamente os atributos de um objeto complexo, como uma classe de domínio, a partir daqueles parâmetros? Como validar estes parâmetros de tal modo que, estando nossa action esperando um parâmetro do tipo numérico, realmente venha algo condizente com esta condição? Preenchimento de formulários: como tornar esta tarefa menos árdua para o programador? Todos esses problemas são resolvidos por aqueles que se predispõem a escrever frameworks para desenvolvimento web. No caso do Grails, muito do que vemos nesta área é na realidade apenas o reaproveitamento da base adotada pelo framework: o Spring MVC. Resumindo, o que é data binding? É o ato de ligarmos os parâmetros fornecidos ao framework pelo protocolo HTTP às propriedades de um objeto ou mesmo a um grafo complexo de objetos de forma transparente para o desenvolvedor, que não mais precisa se preocupar com os problemas que citei. Este procedimento pode ocorrer de diferentes maneiras. Nesta seção serão expostas as mais comuns no dia a dia do programador Grails. Data binding baseado em mapas Vejamos como é o formulário de cadastro de categorias gerado pelo scaffolding cujo código modifiquei ligeiramente para facilitar seu entendimento inicial: Nome:
Há duas novas tags aqui. A primeira é , que usamos para gerar um formulário cujo atributo action, que representa a URL de destino da submissão esteja correta. Ele recebe dois parâmetros que identificam corretamente qual a action a ser executada: action e controller. Em seu interior temos outra tag: , que irá renderizar um campo textual identificado por “nome”. Em seguida, temos um campo do tipo submit, que nada mais é do que o botão de submissão deste formulário. O data binding baseado em mapas pode ser feito como na implementação alternativa da action save a seguir: def save() { // Data binding em ação def categoria = new Categoria(params) // restante da action pode ser ignorado } Nesse caso, estamos apenas usando o próprio funcionamento dos POGOs. Lembra que se passarmos para uma classe Groovy um mapa em seu construtor, este irá automaticamente preencher todos os atributos dela? É apenas isso o que fazemos aqui. Se um dos atributos de Categoria fosse do tipo int, boolean, long ou qualquer outro que em Java é primitivo, a própria linguagem se encarregaria de fazer as conversões necessárias para nós. Há outras maneiras de se usar o objeto params, você também pode usá-lo após a instanciação do seu objeto. Isso é muito comum em actions de edição, por exemplo: def update() { def categoria = Categoria.get(params.long('id')) // Define todos os atributos do nosso objeto em // uma única linha categoria.properties = params // restante da action } Na realidade, Grails vai um pouco além do mero aproveitamento do comportamento padrão dos POGOs. Imagine que meu objeto params seja similar ao exposto a seguir, relativo à persistência de um objeto do tipo Item. ['categoria.id':'1', nome:'Motor'] O atributo categoria.id poderia vir, por exemplo, de uma caixa de seleção. Veja a que o scaffolding cria para o cadastro de itens na imagem: Fig. 7.9: Cadastro de itens Até o momento apenas vimos o binding com uma entidade de domínio: agora estamos vendo com duas: Item e seu atributo do tipo Categoria. Grails é inteligente o suficiente para perceber que há um atributo chamado categoria em nossa classe Item que aponta para outra classe de domínio. Antes de executar o data binding, Grails obterá uma instância de Categoria com o identificador passado como parâmetro e, em seguida, o injetará em nosso objeto. Depois, pode até mesmo alterar algum atributo deste objeto anexado. Imagine que estejamos também modificando o nome da categoria durante a submissão a partir de uma listagem de parâmetros: ['categoria.id':'1', 'categoria.nome':'Motores', nome:'Motor'] Executando o código a seguir: def save() { def item = new Item(params) item.save() } Quando o objeto Item for persistido, a categoria cujo identificador é o número 1 terá seu nome alterado para "Motores". Usando a assinatura da action Outra maneira bastante elegante de tirarmos proveito do data binding do Grails é através da assinatura da nossa action, ou seja, a partir dos parâmetros que ela espera. Voltando ao exemplo da action save, sabe como ela é implementada por padrão pelo scaffolding do Grails? Assim: def save(Categoria categoriaInstance) { // conteúdo da action ignorado neste exemplo } Havendo um único parâmetro na assinatura da action, o data binding será feito diretamente sobre este tal como pôde ser visto. Esse código, na prática, executa o trabalho feito pelo data binding por mapas. A diferença está apenas no modo como escrevemos nosso código. Uma grande vantagem desta modalidade de binding é que a escrita de testes fica mais fácil e também podemos tirar máximo proveito da tipagem estática, garantindo com isto um desempenho superior para aquele código. Lidando com erros Podem ocorrer erros durante o processo de binding? Yeap! Você pode ter erros de tipagem. Imagine que um dos atributos da sua classe de domínio seja do tipo numérico mas seja submetido um valor textual. Novamente, a solução é bastante simples. Vamos supor que estamos lidando com a persistência de uma cotação. Apenas para lembrar, esta é a declaração da