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
).
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:
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:
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.
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: artigo, Java, produtividade, Trabalho
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!
É 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 commentThiago, 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
Reply to this commentPS.: quanto a produtividade em java, da uma olhada no Java On Rails - Produtividade em Java (Parte 2 J2ee Spider)
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 commentMuito bom…já tinha visto um pouco de Grails, pretendo começar a brincar em breve também.
@Thiago
Reply to this commentNã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.
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 commentNa 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 commentOlá 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@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 commentCaro 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 commentvou continuar sim, o 3o dia deve sair no inicio da proxima semana
Reply to this commentso mais uma perguntinha… você usou o netbeans para ruby on rails? se sim achou melhor que o redrails?
Reply to this commentolha, usei o netbeans mas não gostei muito, prefiro o radrails ou o IntelliJ IDEA (que tem um suporte para ruby muito bom
)
Reply to this commentCaro 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 commentolha, 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ê …
Reply to this commentRecomendo testar, pelo menos por algumas horas cada um deles, para depois decidir
[...] (claro que ja precisa ter o grails instalado como eu ensino neste post). [...]
Reply to this comment