Guia em vídeo de Grails

This message was edited 1 time. Last update was at 16/11/2011 02:18:45

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!

This message was edited 1 time. Last update was at 16/11/2011 05:26:14

Excelente iniciativa , esta de parabens mesmo..
Aguardando videos novos ;D

Thread.start() Membro desde: 13/01/2009 11:02:09 Mensagens: 37 Offline

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é..

What is classpath? Membro desde: 25/04/2011 19:33:20 Mensagens: 5 Offline

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?

everton.battini wrote: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?

Oi Everton, respondendo às suas dúvidas, vamos lá

se eu for implementar o PrimeFaces teria como?

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

JavaEvangelist Membro desde: 29/01/2003 11:36:27 Mensagens: 354 Offline

Assisti os vídeos, são excelentes! Eu recomendo!

Parabéns Kiko!

Virtual Machine Man Membro desde: 26/05/2009 15:57:49 Mensagens: 707 Offline

parabens, gostei dos videos

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 518 Offline

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.

This message was edited 1 time. Last update was at 17/11/2011 08:50:30

kicolobo wrote:

everton.battini wrote: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?

Oi Everton, respondendo às suas dúvidas, vamos lá

se eu for implementar o PrimeFaces teria como?

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.

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

, mas gostaria de ouvir a sua opiniao e dos colegas sobre esse cenário.

GUJ Master Membro desde: 13/09/2007 13:34:23 Mensagens: 1041 Offline

alias wrote:

kicolobo wrote:

everton.battini wrote: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?

Oi Everton, respondendo às suas dúvidas, vamos lá

se eu for implementar o PrimeFaces teria como?

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.

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 , mas gostaria de ouvir a sua opiniao e dos colegas sobre esse cenário.

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!!

alias wrote:

kicolobo wrote:

everton.battini wrote: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?

Oi Everton, respondendo às suas dúvidas, vamos lá

se eu for implementar o PrimeFaces teria como?

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.

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 , mas gostaria de ouvir a sua opiniao e dos colegas sobre esse cenário.

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

Virtual Machine Man Membro desde: 11/06/2007 11:09:34 Mensagens: 596 Online

Que bom que concordam, folgo em saber que nao sou o único que nao gosta de Javascript

.

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

, 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.

alias wrote:Que bom que concordam, folgo em saber que nao sou o único que nao gosta de Javascript .

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 , 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.

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?)

* Componentes: realmente, há componentes maravilhosos por ai. O problema era quando eu queria desenvolver um. Era um inferno.
* A parte visual também era complicada: muitas vezes o código gerado não era conforme os padrões web, o que me causava alguns problemas com alguns clientes mais exigentes com esta questão
* O modelo baseado em componentes do JSF na época era muito ruim: aquela história de basicamente tudo ser feito com POST era um pé no saco pra mim. Muitas vezes tudo o que eu queria era um GET simples
E as promessas do JSF também não haviam se cumprido
* Desenvolvimento visual ainda é um lixo
* Aquela velha promessa de que o JSF também seria usado para mobile não vingou
* Desenvolvimento de componentes continuou sendo complicadíssimo
* Eu gastava um tempo MONSTRO integrando JSF com Hibernate, Spring, Log4j, etc.
* Malditos arquivos XML. Era um horror! Sei que no JSF2 melhorou bastante, mas no 1 era simplesmente um I.N.F.E.R.N.O.

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.

Notícias, artigos e o maior fórum brasileiro sobre Java