Olá a todos,
em 2009/2010 gravei para a DevMedia um curso chamado “Grails: do início ao fim”.
Agora, em 2011, estou criando uma nova série de vídeos sobre o assunto, desta vez completamente aberta ao público E com todo o código gerado disponível no GitHub.
Acredito que assim eu possa ajudar ainda aqueles que pretendem aprender Groovy/Grails, mas tenham dificuldade em encontrar material.
O link para o curso é este: http://videograils.itexto.com.br
Espero que gostem. 
excelente iniciativa!
Excelente iniciativa , esta de parabens mesmo…
Aguardando videos novos ;D
MUITO bom…
Sou um leitor das antigas do seu blog… aprendi muita coisa lá e tenho certeza que este curso será muito útil para VÁRIAS pessoas.
Estarei acompanhando o desenrolar das aulas.
Inté…
Umas dúvidas de iniciante…
O crud que ele cria é bem simples… (componentes visuais)
se eu for implementar o PrimeFaces teria como?
se sim, daria mais trabalho do que fazer um projeto JSF + Hibernate normal?
[quote=everton.battini]Umas dúvidas de iniciante…
O crud que ele cria é bem simples… (componentes visuais)
se eu for implementar o PrimeFaces teria como?
se sim, daria mais trabalho do que fazer um projeto JSF + Hibernate normal?[/quote]
Oi Everton, respondendo às suas dúvidas, vamos lá
No caso do Grails, é usado por default o GSP (Groovy Server Pages), que atua como um substituto para o JSP tradicional (resolve diversas lacunas). Há como usar JSF com Grails, mas não compensa, porque o ganho de produtividade com GSP é bem maior, mesmo se comparado com o JSF 2.
É dado foco ao componente visual mais conhecido por todos os webdesigners, o HTML puro, ao contrário do JSF, que muitas vezes complica a vida de quem trabalha com a parte visual (design) das páginas. Com relação aos componentes, você tem facilidades imensas na criação de tags (da uma olhada no primeiro vídeo da série, em que eu passo por alto em cima deste tópico), além do reaproveitamento de código via template.
Muito bom… valeu pela dica 
Assisti os vídeos, são excelentes! Eu recomendo!
Parabéns Kiko!
parabens, gostei dos videos
Parabens, kico
Eu estou com alguns projetos pessoais em grails e seu blog e forum tao ajudando bastante.
Mais esses videos agora, show de bola.
[quote=kicolobo][quote=everton.battini]Umas dúvidas de iniciante…
O crud que ele cria é bem simples… (componentes visuais)
se eu for implementar o PrimeFaces teria como?
se sim, daria mais trabalho do que fazer um projeto JSF + Hibernate normal?[/quote]
Oi Everton, respondendo às suas dúvidas, vamos lá
No caso do Grails, é usado por default o GSP (Groovy Server Pages), que atua como um substituto para o JSP tradicional (resolve diversas lacunas). Há como usar JSF com Grails, mas não compensa, porque o ganho de produtividade com GSP é bem maior, mesmo se comparado com o JSF 2.
É dado foco ao componente visual mais conhecido por todos os webdesigners, o HTML puro, ao contrário do JSF, que muitas vezes complica a vida de quem trabalha com a parte visual (design) das páginas. Com relação aos componentes, você tem facilidades imensas na criação de tags (da uma olhada no primeiro vídeo da série, em que eu passo por alto em cima deste tópico), além do reaproveitamento de código via template.[/quote]
Kicolobo, parabens e obrigado pela iniciativa, tenho “tentado” aprender Groovy/Grails a partir da documentação e de materiais, certamente acompanharei suas aulas com interesse. Sobre o que disse acima, é um ponto que me motiva a aprender a tecnologia mas nao sei se concordo totalmente, por exemplo o colega citou o PrimeFaces, que contem varios componentes “prontos” que encapsulam rotinas de Javascript, que na minha opiniao é algo desgraçado de se mexer. Ou seja, usando um framework “ágil” como o Grails, VRaptor, Play!, etc, o trabalho da camada view ficaria com o desenvolvedor (e normalmente o cara que programa o back-end programa o front tambem). Em suma, na minha opinião posso dizer que não existe agilidade em se programar com Jquery, Ajax na unha, manipular o DOM, etc. E em uma tecnologia como o JSF o programador estaria relativamente “poupado” desse trampo, que na minha opinião é horrível (e olha que conheço bem Javascript, HTML, CSS e tal, mas o Javascript em particular é algo que eu tenho quase nojinho de mexer, hehe)
Imagino que provavelmente discordarão e irão me detonar nessa thread :lol: , mas gostaria de ouvir a sua opiniao e dos colegas sobre esse cenário.
[quote=alias][quote=kicolobo][quote=everton.battini]Umas dúvidas de iniciante…
O crud que ele cria é bem simples… (componentes visuais)
se eu for implementar o PrimeFaces teria como?
se sim, daria mais trabalho do que fazer um projeto JSF + Hibernate normal?[/quote]
Oi Everton, respondendo às suas dúvidas, vamos lá
No caso do Grails, é usado por default o GSP (Groovy Server Pages), que atua como um substituto para o JSP tradicional (resolve diversas lacunas). Há como usar JSF com Grails, mas não compensa, porque o ganho de produtividade com GSP é bem maior, mesmo se comparado com o JSF 2.
É dado foco ao componente visual mais conhecido por todos os webdesigners, o HTML puro, ao contrário do JSF, que muitas vezes complica a vida de quem trabalha com a parte visual (design) das páginas. Com relação aos componentes, você tem facilidades imensas na criação de tags (da uma olhada no primeiro vídeo da série, em que eu passo por alto em cima deste tópico), além do reaproveitamento de código via template.[/quote]
Kicolobo, parabens e obrigado pela iniciativa, tenho “tentado” aprender Groovy/Grails a partir da documentação e de materiais, certamente acompanharei suas aulas com interesse. Sobre o que disse acima, é um ponto que me motiva a aprender a tecnologia mas nao sei se concordo totalmente, por exemplo o colega citou o PrimeFaces, que contem varios componentes “prontos” que encapsulam rotinas de Javascript, que na minha opiniao é algo desgraçado de se mexer. Ou seja, usando um framework “ágil” como o Grails, VRaptor, Play!, etc, o trabalho da camada view ficaria com o desenvolvedor (e normalmente o cara que programa o back-end programa o front tambem). Em suma, na minha opinião posso dizer que não existe agilidade em se programar com Jquery, Ajax na unha, manipular o DOM, etc. E em uma tecnologia como o JSF o programador estaria relativamente “poupado” desse trampo, que na minha opinião é horrível (e olha que conheço bem Javascript, HTML, CSS e tal, mas o Javascript em particular é algo que eu tenho quase nojinho de mexer, hehe)
Imagino que provavelmente discordarão e irão me detonar nessa thread :lol: , mas gostaria de ouvir a sua opiniao e dos colegas sobre esse cenário.[/quote]
Que nada cara, tem razão! Uma vez peguei um projeto que possuía 80% de regras no javascript. Imagina como foi horrível trabalhar nesse projeto!! O desenvolvedor se dizia ninja em Javascript, também era um ninja em gerar bugs!! 
[quote=alias][quote=kicolobo][quote=everton.battini]Umas dúvidas de iniciante…
O crud que ele cria é bem simples… (componentes visuais)
se eu for implementar o PrimeFaces teria como?
se sim, daria mais trabalho do que fazer um projeto JSF + Hibernate normal?[/quote]
Oi Everton, respondendo às suas dúvidas, vamos lá
No caso do Grails, é usado por default o GSP (Groovy Server Pages), que atua como um substituto para o JSP tradicional (resolve diversas lacunas). Há como usar JSF com Grails, mas não compensa, porque o ganho de produtividade com GSP é bem maior, mesmo se comparado com o JSF 2.
É dado foco ao componente visual mais conhecido por todos os webdesigners, o HTML puro, ao contrário do JSF, que muitas vezes complica a vida de quem trabalha com a parte visual (design) das páginas. Com relação aos componentes, você tem facilidades imensas na criação de tags (da uma olhada no primeiro vídeo da série, em que eu passo por alto em cima deste tópico), além do reaproveitamento de código via template.[/quote]
Kicolobo, parabens e obrigado pela iniciativa, tenho “tentado” aprender Groovy/Grails a partir da documentação e de materiais, certamente acompanharei suas aulas com interesse. Sobre o que disse acima, é um ponto que me motiva a aprender a tecnologia mas nao sei se concordo totalmente, por exemplo o colega citou o PrimeFaces, que contem varios componentes “prontos” que encapsulam rotinas de Javascript, que na minha opiniao é algo desgraçado de se mexer. Ou seja, usando um framework “ágil” como o Grails, VRaptor, Play!, etc, o trabalho da camada view ficaria com o desenvolvedor (e normalmente o cara que programa o back-end programa o front tambem). Em suma, na minha opinião posso dizer que não existe agilidade em se programar com Jquery, Ajax na unha, manipular o DOM, etc. E em uma tecnologia como o JSF o programador estaria relativamente “poupado” desse trampo, que na minha opinião é horrível (e olha que conheço bem Javascript, HTML, CSS e tal, mas o Javascript em particular é algo que eu tenho quase nojinho de mexer, hehe)
Imagino que provavelmente discordarão e irão me detonar nessa thread :lol: , mas gostaria de ouvir a sua opiniao e dos colegas sobre esse cenário.[/quote]
Sabe, eu concordo d+ da conta com você
E sim, é possível e não é tão chato quanto falei.
Existem plugins pra isto: http://www.grails.org/plugin/jsf2 e http://grails.org/plugin/icefaces
Que bom que concordam, folgo em saber que nao sou o único que nao gosta de Javascript :lol: .
No geral tenho a impressão que a comunidade torce o nariz pro JSF preferindo a a abordagem action-based, e nao entendo bem o porque…talvez por limitações intelectuais da minha parte :lol: , mas realmente discordo (minha opiniao, é claro, hehe) que trabalhar com Jquery e Javascript seja mais “ágil” do que ter um componentezinho bonito qualquer do [seu preferido aqui]Faces pronto pro meu uso…Kicolobo, em sua opinião, o ganho de produtividade do Grails (usando como exemplo) compensa o sacrifício que será atuar na view, em uma página complexa?
Perdoem os questionamentos e colocações de iniciante, amigos.
[quote=alias]Que bom que concordam, folgo em saber que nao sou o único que nao gosta de Javascript :lol: .
No geral tenho a impressão que a comunidade torce o nariz pro JSF preferindo a a abordagem action-based, e nao entendo bem o porque…talvez por limitações intelectuais da minha parte :lol: , mas realmente discordo (minha opiniao, é claro, hehe) que trabalhar com Jquery e Javascript seja mais “ágil” do que ter um componentezinho bonito qualquer do [seu preferido aqui]Faces pronto pro meu uso…Kicolobo, em sua opinião, o ganho de produtividade do Grails (usando como exemplo) compensa o sacrifício que será atuar na view, em uma página complexa?
Perdoem os questionamentos e colocações de iniciante, amigos.[/quote]
Oi Alias,
bom: eu adoro Javascript
Se compensa ou não, depende muito do projeto. Meu caso é similar ao seu, fim do JSF, que na época era a coisa mais linda do mundo pra mim. Mas conforme o tempo foi passando, eu percebi algumas deficiências no JSF (minha vivência real é na primeira versão, então pode desconsiderar com relação à segunda ok?)
Então conheci Grails, e de cara, o primeiro problema resolvido foi o da integração com meus componentes favoritos. Como é fullstack, de cara eu podia continuar usando as minhas bibliotecas favoritas.
A criação de “componentes” também era BEM mais fácil. Em Grails criar taglibs ou templates é absurdamente fácil e, diria, também muito mais natural. Como no meu caso Javascript não era o problema, e eu sempre gostei de ter o meu HTML limpo, o GSP caiu como uma luva
O modelo baseado em actions também era bacana pra mim, porque muitas vezes eu podia desenvolver uma API de forma muito rápida
E finalmente, tinha também o reaproveitamento de código: eu ainda podia usar minhas taglibs legadas, incluindo componentes JSF se eu quisesse.
Ah, e claro: por trás de tudo eu ainda tinha o Groovy que, na época (e ainda hoje), dava um BANHO de produtividade em cima do Java. É mais lento? Com certeza, mas não chega a ser um problema pros meus requisitos e, de qualquer maneira, eu sempre posso implementar alguma coisa em Java puro se houver necessidade REAL de performance.
No meu caso então valeu muito à pena, pois as dores de cabeça que eu tinha com o JSF simplesmente sumiram, e a minha produtividade aumentou HORRORES.
Mas claro, cada caso é um caso.
Grails X JSF
Também perdi horrores de tempo configurando o Hibernate, Spring etc com o JSF e quando finalmente estou “pegando o jeito” (realmente tem alguns processos muuuuuito repetitivos no desenvolvimeto) vejo que existe algo totalmente “fora da caixa”… o Grails!
Muito bom o video e a intenção. Visitei seu blog e realmente vou acompanhar mais de perto.
… Mas tenho que confessar que a primeira coisa que eu fiz depois de ver os videos foi procurar sobre JSF + Grails… especialmente para usar os componentes dos “***faces” da vida…
Vou dar uma olhada nesses 2 plugins e ver o quão fácil seria aplicar…
A propósito, também prefiros os components por encapsularem linhas e mais linhas de javascript =)
Parabéns kicolobo pelo material e iniciativa.
Eu também acho que o “calcanhar de aquiles” do Grails é a parte da View. É quase dificil imaginar um sistema sem grandes requisitos nessa camada, pois a usabilidade depende dela diretamente.
É tão fácil criar taglibs no grails, isso é fato… mas não há uma biblioteca de tags que realmente seja boa opção em RIA. Testei algumas que quebram algum galho, mas sequer chegam perto, por exemplo, das do jquery plugin para Struts2 (projeto do qual sou colaborador).
http://code.google.com/p/struts2-jquery/
http://www.weinfreund.de/struts2-jquery-showcase/ (show case)
http://www.weinfreund.de/struts2-jquery-grid-showcase/index.action (show case só da grid)
Mesmo quem gosta e é bom em Javascript/Jquery com certeza gosta de ter o trabalho reduzido por meio de tags.
Quando eu estiver com mais tempo - nas férias, imagino - penso em “recriar” essas taglibs para Grails e disponibilizar como plugin.
[quote=jyoshiriro]Eu também acho que o “calcanhar de aquiles” do Grails é a parte da View. É quase dificil imaginar um sistema sem grandes requisitos nessa camada, pois a usabilidade depende dela diretamente.
É tão fácil criar taglibs no grails, isso é fato… mas não há uma biblioteca de tags que realmente seja boa opção em RIA. Testei algumas que quebram algum galho, mas sequer chegam perto, por exemplo, das do jquery plugin para Struts2 (projeto do qual sou colaborador).
http://code.google.com/p/struts2-jquery/
http://www.weinfreund.de/struts2-jquery-showcase/ (show case)
http://www.weinfreund.de/struts2-jquery-grid-showcase/index.action (show case só da grid)
Mesmo quem gosta e é bom em Javascript/Jquery com certeza gosta de ter o trabalho reduzido por meio de tags.
Quando eu estiver com mais tempo - nas férias, imagino - penso em “recriar” essas taglibs para Grails e disponibilizar como plugin.[/quote]
Oi jyoshiriro, na verdade, não precisa ser dar a este trabalho.
Desde a versão 1.2 do Grails você pode usar as bibliotecas de tags convencionais, então todo este legado pode ser reaproveitado de forma quase transparente sem problema.
Na verdade haverá a necessidade, sim.
Ocorre que essas taglibs que citei foram feitas com alto acoplamento com as classes do Struts2 e com seu servlet fllter 
Já havia tentado usar e fazer uma “leve” adaptação, mas não deu.
Simplesmente não funciona declarar a taglib com uma diretiva em cima e usar a tag na página. Não rola.
[quote=jyoshiriro]Na verdade haverá a necessidade, sim.
Ocorre que essas taglibs que citei foram feitas com alto acoplamento com as classes do Struts2 e com seu servlet fllter
Já havia tentado usar e fazer uma “leve” adaptação, mas não deu.
Simplesmente não funciona declarar a taglib com uma diretiva em cima e usar a tag na página. Não rola.[/quote]
É, mas neste caso ai é pedir um pouco demais né?
Neste caso, elas estariam presas no Struts 2, você teria um trabalho tão grande pra portar pra qualquer outro framework que realmente não compensa