Blog do Urubatan
msgbartop
Desenvolvedor, Arquiteto, Palestrante, Coordenador do RSJUG, Patinador e Blogger
msgbarbottom

02 Jun 07 Java on Rails - Produtividade em Java (Parte 3 - Grails)

Eu fiquei em duvida sobre o titulo deste artigo, achei que deveria ser Groovy On Rails, mas eu resolvi seguir a linha “Java On Rails” que eu vinha escrevendo a algum tempo atras (aqui, aqui) e quando eu mencionei o Grails no ano passado.

O Grails é a coisa mais parecida com o Java On Rails que eu encontrei até agora, Grails é um Groovy On Rails que foi escrito em Groovy, uma linguagem dinamica derivada do Java, e que roda na JVM.

Ele foi bastante inspirado no Rails mesmo, e tem inclusive algumas coisas que eu achei mais inteligentes que o proprio Rails (eles poderiam copiar de volta :D ).

Ele também é baseado em um gerador “console” como o Rails, possui “scaffold” como o rails, apenas os comandos são um pouco diferentes, e a linguagem doscontrollers é Groovy em vez de Ruby.

As páginas acessadas “template” para a renderização, podem ser escritas utilizando GSP (Groovy Server Pages) ou JSP (Java Server Pages) no ultimo caso com uma taglib para ajudar bastante no trabalho.

Ele funciona 100% integrado com a especificação de servlets, o que ja é uma vantagem sobre o JRuby que ainda esta desenvolvendo a possibilidade de se fazer o deploy da aplicação como um WAR (Web Archive) padrão Java EE.

Ele tem integração com Hibernate (mesmo possuindo um mapeamento O/R proprio bem parecido com o Ruby), com o Spring Framework, com o Sitemesh, “Suporte Java” a i18n, estrutura da aplicação padronizada como o RoR, validação, banco de dados padrão HSQLDB (o ue significa que não é necessário criar um banco para testar o brinquedo).

Plugins para integração com OpenLazslo, DWR, Converters, XFire, REST, Quartz, ACEGI, Captcha, …

A coisa que eu achei mais inteligente que o RoR foi o comando “install-templates”, que copia os templates que serão utilizados para o “scaffolding” para dentro do diretório da aplicação, possibilitando costumiza-los para que os proximos “scaffolds” utilizem os templates costumizados, o que vai dar uma excelente flexibilidade em o que é gerado para a sua aplicação.

Vamos dar uma olhada rapida nos comandos do grails:

bug-report (a partir da versão 0.4) Gera um zip com os artefatos necessários para se reportar um BUG no JIRA do projeto
clean Limpa o diretório temporário da aplicação
create-app Cria uma nova aplicação “Grails” com toda a estrutura de diretórios e arquivos iniciais.
create-controller Utilitário para criar um controller
create-domain-class Utilitário para criar as classes de domínio
create-data-source Utilitário para criar um DataSource
create-job Utilitário para criar classes que representam “jobs” para o suporte a agendamento de tarefas
create-service Utilitário para criar serviços, por padrão web-services, mas com plugins podem ser REST, RMI, Hessian, Burlap, …
create-taglib Utilitário para criar uma taglib
create-test-suite Utilitário para criar testes unitários
create-webtest Utilitário para criar um teste funcional
generate-controller Utilitário para criar um controller para uma classe de dominio
generate-views Utilitário para criar as views para uma classe de dominio
generate-all Utilitário para criar o controller e as views para uma classe de dominio
get-dependencies Busca as dependencias do projeto utilizando o Ivy
install-ivy Instala o Ivy como gerenciador de dependencias do projeto
install-templates Instala no projeto os templates utilizados para Scaffolding
run-app Executa a aplicação utilizando um Jetty embedded
run-webtest Executa os testes funcionais
test-app Executa os unit tests
war Cria um WAR compativel com Java EE para deploy em qualquer app server

Como pode ser visto no “Quick Start” do projeto, o comando “grails create-app” cria a seguinte estrutura para o projeto:

%PROJECT_HOME% + grails-app
+ conf —> Local para artefatos de configuração, como os Data Sources
+ controllers —> Código dos Controllers
+ domain —> Código das classes de dominio
+ i18n —> Local para resource bundles para internacionalização
+ services —> Local para o código dos “web services”
+ taglib —> Local para as tag libraries
+ util —> Local para classes utilitárias (codecs, …)
+ views —> Local para as views
+ layouts —> Local para os layouts
+ hibernate —> Configuração opcional do Hibernate
+ lib
+ spring —> Configuração opcional para o Spring
+ src
+ groovy —> Local para códigos fonte Groovy opcionais, deve ser utilizado para artefatos diferentes dos localizados no grails-app/*
+ java —> Local para códigos java adicionais
+ war
+ WEB-INF

Como podemos ver, temos toda a vantagem da padronização do RoR, e toda a flexibilidade do Java+Spring+Hibernate+Sitemesh.

Claro, é necessário aprender a linguagem Groovy, mas para utilizar RoR é necessário aprender Ruby.

Vamos então criar uma aplicação básica RoR com um cadastro simples:

  1. grails create-app TesteGrails
  2. cd TesteGrails
  3. grails create-domain-class cliente
  4. Editar o arquivo Cliente.groovy que foi criado em grails-app/domain e adicionar alguns campos (eu adicionei String nome; String url; String email;)
  5. grails generate-all Cliente
  6. grails run-app
  7. acessar http://localhost:8080/TesteGrails/cliente/list

Prontinho, o cadastro de clientes esta 100% funcional …

é possivel utilizar Scaffolding dinâmico como no RoR também, basta alterar o código do controller para:

class ClienteController {

def scaffold = Cliente

}

Agora vamos dar uma olhada no código que foi gerado para nós:

Cliente.groovy (depois dos campos adicionados manualmente)

class Cliente {

String nome;

String url;

String email;

}

ClienteController.groovy

class ClienteController {

def index = { redirect(action:list,params:params) }// the delete, save and update actions only

// accept POST requests

def allowedMethods = [delete:'POST',

save:'POST',

update:'POST']

def list = {

if(!params.max)params.max = 10

[ clienteList: Cliente.list( params ) ]

}

def show = {

[ cliente : Cliente.get( params.id ) ]

}

def delete = {

def cliente = Cliente.get( params.id )

if(cliente) {

cliente.delete()

flash.message = "Cliente ${params.id} deleted."

redirect(action:list)

}

else {

flash.message = "Cliente not found with id ${params.id}"

redirect(action:list)

}

}

def edit = {

def cliente = Cliente.get( params.id )

if(!cliente) {

flash.message = "Cliente not found with id ${params.id}"

redirect(action:list)

}

else {

return [ cliente : cliente ]

}

}

def update = {

def cliente = Cliente.get( params.id )

if(cliente) {

cliente.properties = params

if(cliente.save()) {

redirect(action:show,id:cliente.id)

}

else {

render(view:'edit',model:[cliente:cliente])

}

}

else {

flash.message = "Cliente not found with id ${params.id}"

redirect(action:edit,id:params.id)

}

}

def create = {

def cliente = new Cliente()

cliente.properties = params

return ['cliente':cliente]

}

def save = {

def cliente = new Cliente()

cliente.properties = params

if(cliente.save()) {

redirect(action:show,id:cliente.id)

}

else {

render(view:'create',model:[cliente:cliente])

}

}

}

ClienteTests.groovy

class ClienteTests extends GroovyTestCase {void testSomething() {

}
}

Fora as views que foram geradas automagicamente utilizando GSP.

Coisas que só o Grails (Groovy On Rails) faz por você

  • O projeto criado pelo grails ja vem pré configurado para o eclipse, e se você esta utilizando o Eclipse 3.3 ele ja tem suporte utilizando o update site do Europa, a linguagens dinamicas como o Groovy
  • Se você instalar o plugin do OpenLaszlo com pequenas alterações nos comandos mostrados, ele pode gerar as views do controller utilizando o Ajax do OpenLaszlo
  • Validação estupidamente fácil, configurada na entidade e com reflexo nas validações no HTML

Acho que era isto, a ideia deste post era fazer vocês ficarem pelo menos coriosos sobre o Grails, que na minha opinião é uma forma estupidamente fácil de se criar aplicações web utilizando Groovy e Java, com todo o poder do Spring e do Hibernate por traz dos panos.

Ou seja, o grails é praticamente perfeito seguindo aquele conceito que eu canso de repetir aqui no blog:

é excelente você poder configurar as coisas, a merda é você ser obrigado a configurar como na maior parte dos frameworks em java, mas o grails conseguiu mudar isto!

Alem disto ele ainda incentiva a escrita de testes unitários, e testes funcionais tornando isto facílimo, quase prazeroso.

Tendo dito isto, agora é a sua vez, acesse a página do projeto e comesse a brincar,

Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!

Tags: , , ,

Reader's Comments

  1. |

    Olá Urubatan,

    se tratando em Java On Rails com certeza o Grails não poderia deixar de ser mencionado. Parabéns pelo post!
    Eu brinco com o Grails e até aqui estou gostando muito. No entanto utilizar Java ao invés de Groovy ainda tem suas vantagens. O nome dessas vantagens são IDE, debug ou documentação por exemplo. Esse drama é confirmado quando saimos do feijão com arroz e sofremos para corrigir alguns errinhos básicos. Mas tudo bem: eu sei que é questão de tempo e questão da tecnologia amadurecer.

    Não é tão simples ter um ambiente de desenvolvimento “rápido” usando somente java. No entanto as vezes me pergunto. Cadê os frameworks para scaffolding em java? Frameworks para dar um help na produtividade com templates velocity/freemarker? Ou quem sabe um framework que eu escreva no console “create-application” e ele já crie uma estrutura de aplicação inteirinha bastando apenas escrever em seguida “run-application” para ver o resultado na tela.

    Algo muito interessante no Grails é que ele faz uma integração interessante entre Spring, Hibernate e Sitemesh além de possibilitar integração com outros frameworks. Que tal um novo framework que faça o mesmo: Java + Spring + Spring MVC/Wicket + Sitemesh e integração com outros frameworks? O JBoss Seam utiliza JSF + JPA/Hibernate. JBoss Seam e Grails são bons exemplos de frameworks que agrupam e integram um outro grupo de tecnologias.

    O foco em minha opinião agora é produtividade e acho que em java tem poucas iniciativas focando produtividade. É como se a criatividade tivesse migrado para as novas linguagens! :D
    É isso ai. Só um desabafo. Por enquanto ainda acho que é possível ter uma produtividade alta sem depender de uma linguagem dinâmica. Gostaria também de saber sua opinião.

    Obs: tem algo errado com o seu blog. Algum recurso nele impossiblita de eu abri-lo no i.e. Dá um “Runtime Error!” - R6025 - pure virtual function call. Ai todas as janelas do i.e são fechadas.

    Abraços!

    Reply to this comment
  2. |

    Thiago, eu vi isto acontecendo no IE em uma maquina em um curso que ministrei, mas na minha maquina não consegui reproduzir, nem em casa nem no escritório (IE6 e IE7) …
    Mas estarei mudando o thema em breve, e isto deve resolver o problema eu acho …
    Sem reproduzir o erro fica dificil de eu corrigir, então vou tentar trocar o tema para resolver o problema …

    Quanto a ser possivel ser produtivo só com java, acredito que seja possivel sim, o Seam é um exemplo disto.

    Quanto a debug no Grails é possivel debugar inclusive o código escrito em Groovy utilizando o eclipse, vou ver se consigo escrever um passo a passo esta semana para postar aqui :D
    PS.: quanto a produtividade em java, da uma olhada no Java On Rails - Produtividade em Java (Parte 2 J2ee Spider)

    Reply to this comment
  3. |

    Olá,

    quanto ao debug com o Groovy eu até havia conseguido. O que foi chato é que o Groovy Plugin estava com um bug que não permitia debugar dentro das closures. O problema é que por enquanto os plugins estão simples e em pleno desenvolvimento (ou seja, instáveis).

    Acabei de dar uma lida no post sobre J2EE Spider. Interessante! Depois olharei o framework com mais calma. Obrigado pela dica!

    Quanto ao problema no i.e, no stress. Sou mais firefox… rsrs..

    Até +

    Reply to this comment
  4. |

    Muito bom…já tinha visto um pouco de Grails, pretendo começar a brincar em breve também.

    @Thiago
    Não sei conhece, mas existe o AppFuse ( http://www.appfuse.org ) que integra uma grande quantidade de frameworks e ainda funciona com code generation também. É realmente produtivo, ele gera as classes de DAO, actions do framework web, jsps, e testes unitários também.

    Reply to this comment
  5. |

    tenho que ar mais uma olhada no appfuse, eu jurava que ele servia só para o start da aplicação, depois para criar actions novas e coisas assim ele não fazia mais nada …

    Valeus a dica

    Reply to this comment
  6. |

    Na versao 2 que está sendo desenvolvida ainda só tem code generation para o Struts2 por enquanto, mas a 1.9.x tem pra todos incluidos no pacote =)

    Reply to this comment
  7. |

    Olá David,

    valeu pelo toque! Assim como o Urubatan não pensei que o AppFuse fosse somente para dar um start no projeto. Eu também pensava que o fim dele fosse apenas aprendizagem. Acho que subestimei o projeto. E o pior é que eu já visitei o site várias vezes e nunca prestei atenção direito! :(
    Vou ter que olhar para o appfuse com mais calma e de preferência hoje mesmo! Pelo que entendi então o equinox (https://equinox.dev.java.net/) faz o mesmo que o appfuse e seria uma outra opção (mais simples)?

    Urubatan, se o appfuse for tudo o que tá parecendo ser você vai ter que criar um novo post chamado: “Java on Rails - Produtividade em Java (Parte X- AppFuse)”. risos!

    Abraços!

    Reply to this comment
  8. |

    @Thiago

    Na verdade o Equinox é uma versão light do AppFuse ( na verdade ate mudou de nome, chama-se AppFuse Light mesmo ), ele vem com menos “features” que o Appfuse, não vem com a parte de autenticação pronta por exemplo…mas a finalidade é a mesmo.

    Reply to this comment
  9. |

    Caro urubatan… acompanho com frequencia seu blog e primeiramente gostaria parabenizar você pelo excelente trabalho… sempre postando com qualidade… mas também gostaria saber se você pretende continuar com a seria de “4 dias com ruby on rails” pois estava gostando muito dos artigos…

    Abraços

    Reply to this comment
  10. |

    vou continuar sim, o 3o dia deve sair no inicio da proxima semana :D

    Reply to this comment
  11. |

    so mais uma perguntinha… você usou o netbeans para ruby on rails? se sim achou melhor que o redrails?

    Reply to this comment
  12. |

    olha, usei o netbeans mas não gostei muito, prefiro o radrails ou o IntelliJ IDEA (que tem um suporte para ruby muito bom :D )

    Reply to this comment
  13. |

    Caro Urubatan… estou em duvida sobre em quem apostar… grails ou Ruby on Rails… estou terminando uma especialização e tenho que entregar uma monografia :/ então pensei em fazer sobre algo novo para mim mas que eu pudesse usar no mercado de trabalho (trabalho com desenvolvimento web atualmente com jsf e hibernate/jpa)… então reslvi fazer a monografia no ramo do “desenvolvimento agil para web com…” de primeiro ia fazer com JSF+JPA… mas convenhamos o JSF ainda esta meio longe de ser realmente produtivo… então me veio a ideia do Ruby on Rails de quem ouvi falar muito bem… mas agora lendo seu post fiquei na duvida se poderia optar pelo grails devido a sua compatibilidade com java… vc poderia me dar sua opnião sobre qual seria rel=almente mais produtivo e qual poderia ser mais promissor para o mercado de trabalho…

    obrigado :)

    Reply to this comment
  14. |

    olha, os dois são muito bons …
    mas se você quer algo novo para você, recomendo o Ruby On Rails …
    O Grails utiliza diversas tecnologias bastante conhecidas do mundo Java, como Spring Framework, Sitemesh e Hibernate …

    Mas quem vai ter que escolher um é você …
    Recomendo testar, pelo menos por algumas horas cada um deles, para depois decidir :D

    Reply to this comment
  15. |

    [...] (claro que ja precisa ter o grails instalado como eu ensino neste  post). [...]

    Reply to this comment

Leave a Comment