E do que você não gosta no Grails?
11/09/2009 00:00
0
Sou suspeito pra falar: ADORO Grails.
No entanto, nada é perfeito, e acredito que seja um exercício de extrema importância criticar as tecnologias com as quais gostamos de trabalhar (sério: nada é mais irritante do que um deslumbrado).
Sendo assim, gostaria de abrir esta discussão aqui no Grails Brasil: o que você não gosta no Grails?
Já inicio com a minha portanto: reaproveitamento de código em Grails é complicado (o que aliás não é um problema exclusivo do Grails):
suponha que você crie uma funcionalidade em um projeto X, e que precise de suas classes de domínio em um projeto Y. Não há (pelo menos eu não conheço) uma forma prática de reaproveitar estas classes de domínio que não seja copiar arquivos de um diretório para outro.
Outra solução para este problema consistiria em criar plugins, que então seriam reaproveitados em todos os projetos, mas mesmo assim, ainda não é uma solução 100% fácil e tranquila de ser implementada, pois você ainda fica dependente do ambiente de execução do Grails. O ideal, na minha opinião, seria poder colocar as minhas classes em um jar e assim reaproveitá-las em uma aplicação web, desktop ou o que seja.
No entanto, nada é perfeito, e acredito que seja um exercício de extrema importância criticar as tecnologias com as quais gostamos de trabalhar (sério: nada é mais irritante do que um deslumbrado).
Sendo assim, gostaria de abrir esta discussão aqui no Grails Brasil: o que você não gosta no Grails?
Já inicio com a minha portanto: reaproveitamento de código em Grails é complicado (o que aliás não é um problema exclusivo do Grails):
suponha que você crie uma funcionalidade em um projeto X, e que precise de suas classes de domínio em um projeto Y. Não há (pelo menos eu não conheço) uma forma prática de reaproveitar estas classes de domínio que não seja copiar arquivos de um diretório para outro.
Outra solução para este problema consistiria em criar plugins, que então seriam reaproveitados em todos os projetos, mas mesmo assim, ainda não é uma solução 100% fácil e tranquila de ser implementada, pois você ainda fica dependente do ambiente de execução do Grails. O ideal, na minha opinião, seria poder colocar as minhas classes em um jar e assim reaproveitá-las em uma aplicação web, desktop ou o que seja.
0
Eu também gosto muito do Grails, mas para mim é inevitável comparar suas features com as features do Rails, já que trabalho no dia a dia com os dois. Não tenho um preferido. Posso listar aqui diversos coisas que gosto mais em um ou outro.
A primeira delas é o sistema testes do Grails que é muito fechado e acoplado ao JUnit. Além de não ter um modelo de testes que compile as GSPs, obrigando a utilizar selenium ou canoo para qualquer coisa. Um exemplo disso é que em um caso em que eu tinha todos os testes escritos (unitarios de modelo, controller e service) e o teste de integração, com muitos testes. Ao iniciar a aplicação e acessar a página, deu exception na GSP. No Rails, é possível escrever testes unitários para um template. Chama-se o metodo render e usa-se os selector CSS para verificar a presença de qualquer coisa. Muito interessante, pois garante que está compilando. =)
Não gosto da falta de controle de dependências. Mesmo quando instalamos os plugins, temos que configurar na mão no arquivo do IVY quais são os jars que queremos. Isso é muito difícil de se fazer, pois no caso de plugins, teríamos que colocar as dependências do plugin em si, mas onde achamos essa informação? Em lugar nenhum. Tem que ir na sorte, catando no google. De qualquer forma, parece que isso já está melhorando no Grails 1.2. Não é uma solução definitiva, mas vai melhorar.
Pra terminar, não gosto do fato do grails copiar os compilados para ~/.grails/projects e apenas tratar os projetos pelo nome. Isso dificulta em casos de servidores de integração contínua. Vira e mexe tem que se fazer um clean pra facilitar.
De cabeça é disso que eu lembro. =)
A primeira delas é o sistema testes do Grails que é muito fechado e acoplado ao JUnit. Além de não ter um modelo de testes que compile as GSPs, obrigando a utilizar selenium ou canoo para qualquer coisa. Um exemplo disso é que em um caso em que eu tinha todos os testes escritos (unitarios de modelo, controller e service) e o teste de integração, com muitos testes. Ao iniciar a aplicação e acessar a página, deu exception na GSP. No Rails, é possível escrever testes unitários para um template. Chama-se o metodo render e usa-se os selector CSS para verificar a presença de qualquer coisa. Muito interessante, pois garante que está compilando. =)
Não gosto da falta de controle de dependências. Mesmo quando instalamos os plugins, temos que configurar na mão no arquivo do IVY quais são os jars que queremos. Isso é muito difícil de se fazer, pois no caso de plugins, teríamos que colocar as dependências do plugin em si, mas onde achamos essa informação? Em lugar nenhum. Tem que ir na sorte, catando no google. De qualquer forma, parece que isso já está melhorando no Grails 1.2. Não é uma solução definitiva, mas vai melhorar.
Pra terminar, não gosto do fato do grails copiar os compilados para ~/.grails/projects e apenas tratar os projetos pelo nome. Isso dificulta em casos de servidores de integração contínua. Vira e mexe tem que se fazer um clean pra facilitar.
De cabeça é disso que eu lembro. =)
11/09/2009 00:00
0
Ah... lembrei de outra coisa que não gosto....
Os templates do Grails não são tableless... Porco isso hein!!!
Os templates do Grails não são tableless... Porco isso hein!!!
11/09/2009 00:00
0
O Grails tem um grande potencial assim como seu irmão o Rails.
MAS, CONTUDO, PORÉM, TODAVIA, <!-- s:P --><img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" /><!-- s:P --> , o framework ainda apresenta pequenas falhas, assim como, as issues do JIRA que parece mais uma lista interminável(<!-- m --><a class="postlink" href="http://jira.codehaus.org/browse/GRAILS">http://jira.codehaus.org/browse/GRAILS</a><!-- m -->).
O ideal é que os desenvolvedores do Grails pensen em deixar o framework estável e confiável.
MAS, CONTUDO, PORÉM, TODAVIA, <!-- s:P --><img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" /><!-- s:P --> , o framework ainda apresenta pequenas falhas, assim como, as issues do JIRA que parece mais uma lista interminável(<!-- m --><a class="postlink" href="http://jira.codehaus.org/browse/GRAILS">http://jira.codehaus.org/browse/GRAILS</a><!-- m -->).
O ideal é que os desenvolvedores do Grails pensen em deixar o framework estável e confiável.
11/09/2009 00:00
0
[quote="Horus Shadow"]O Grails tem um grande potencial assim como seu irmão o Rails.
MAS, CONTUDO, PORÉM, TODAVIA, <!-- s:P --><img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" /><!-- s:P --> , o framework ainda apresenta pequenas falhas, assim como, as issues do JIRA que parece mais uma lista interminável(<!-- m --><a class="postlink" href="http://jira.codehaus.org/browse/GRAILS">http://jira.codehaus.org/browse/GRAILS</a><!-- m -->).
O ideal é que os desenvolvedores do Grails pensen em deixar o framework estável e confiável.[/quote]
Na realidade, bugs SEMPRE vão existir em qualquer framework. Não sei se podemos reclamar do Grails por ter bugs agora.
Poderiamos na versão 1.0. Eu me lembro que quando fiz minhas palestras no WebDays 2008, parte do conteúdo que apresentei foi justamente como EVITAR alguns dos bugs presentes no mesmo, porém a partir da versão 1.1, não me deparei mais com este tipo de problema.
Eu discordo da postura adotada no lançamento de novas versões do Grails. Na minha opinião, um release como o 1.2 deveria vir apenas com novos recursos ou alguma mudança estrutural ou outra.
NO entanto, deveriam haver n releases 1.1.n com correção de bugs.
MAS, CONTUDO, PORÉM, TODAVIA, <!-- s:P --><img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" /><!-- s:P --> , o framework ainda apresenta pequenas falhas, assim como, as issues do JIRA que parece mais uma lista interminável(<!-- m --><a class="postlink" href="http://jira.codehaus.org/browse/GRAILS">http://jira.codehaus.org/browse/GRAILS</a><!-- m -->).
O ideal é que os desenvolvedores do Grails pensen em deixar o framework estável e confiável.[/quote]
Na realidade, bugs SEMPRE vão existir em qualquer framework. Não sei se podemos reclamar do Grails por ter bugs agora.
Poderiamos na versão 1.0. Eu me lembro que quando fiz minhas palestras no WebDays 2008, parte do conteúdo que apresentei foi justamente como EVITAR alguns dos bugs presentes no mesmo, porém a partir da versão 1.1, não me deparei mais com este tipo de problema.
Eu discordo da postura adotada no lançamento de novas versões do Grails. Na minha opinião, um release como o 1.2 deveria vir apenas com novos recursos ou alguma mudança estrutural ou outra.
NO entanto, deveriam haver n releases 1.1.n com correção de bugs.
11/09/2009 00:00
1
A lista de issue do rails no lightbox é bem gigante também. Eu diria até que é infinita. A diferença? A comunidade rails é mais unida e mais presente. Não que a do Grails não seja, mas a do Rails é mais. =)
11/09/2009 00:00
0
[quote="felipero"]A lista de issue do rails no lightbox é bem gigante também. Eu diria até que é infinita. A diferença? A comunidade rails é mais unida e mais presente. Não que a do Grails não seja, mas a do Rails é mais. =)[/quote]
Na realidade, eu diria que Rails possui um certo "fator cool" que só agora Grails está começando a ter.
Na realidade, eu diria que Rails possui um certo "fator cool" que só agora Grails está começando a ter.
11/09/2009 00:00
0
Acho que até o final desse ano teremos uma resposta da Spring sobre o Framework, essa resposta que falo é um ambiente para desenvolvimento legal em groovy, não aquele antigo que vc apertava Ctrl + Espaço e demorava uma era para aparecer uma lista de métodos que não serviam para nada. Quer quiser acompanhar as novidades da Spring no Grails basta acompanhar este blog http://blog.springsource.com/. Agora sim a coisa anda!! <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->
13/09/2009 00:00
0
Talvez a única coisa que realmente não gosto do Grails, com uma boa razão, é uma parte do mapeador objeto-relacional (GORM). Especificamente a abstração das operações de persistência (save, update, delete) das entidades.
Pra seguir o padrão ActiveRecord no estilo Rails - onde a própria entidade de domínio possui métodos de persistência, o GORM acaba escondendo a natureza do cache de primeiro nível (Unit of Work) existente no Hibernate (que o GORM utiliza por trás pra persistir as entidades). Isto gera uma "abstração furada" (Leaky Abstraction) da sessão do Hibernate para o desenvolvedor.
Por exemplo, em algumas ocasiões as entidades de domínio enviam dados para o banco (flush automático), mesmo se ainda não foram salvas explicitamente com domain.save(), ocasionando registros salvos inesperadamente. Ou o contrário: não enviam dados para o banco (não efetuam flush), mesmo quando um domain.save() foi chamado, gerando problemas inesperados.
Isto fere gravemente o excelente Princípio da Menor Surpresa (Principle of Least Surprise) que encoraja que o resultado de uma operação deve ser ÓBVIA, CONSISTENTE e principalmente PREVISÍVEL. Este pontos acima não são previsíveis através das simples operações (save,update,etc.) da entidade. Principalmente pra quem não conhece Hibernate!
E então, pra arrumar este "furo na abstração", temos a "gambiarra" domain.save(flush:true) que não condiz com toda a elegância do GORM no Grails.
Então, hoje, em casos de uso com associações de entidades de domínios mais complexos, o desenvolvedor acaba apanhado um bocado se não conhecer bem o Hibernate. É uma pena...
Poderiam deixar a abstração menos furada se definissem uma abstração direta do cache intermediário (Unit of Work), ou deixassem o Hibernate do Grails configurado com StatelessSession, se parecendo mais com o Rails - de onde o Grails se inspira. O ideal mesmo seriam estas duas implementações. Uma para cada caso.
De qualquer forma, as vantagens de se utilizar Grails na plataforma Java são tão grandes que compensam tudo isso!. Pode ter certeza!
PS.: Em tempo, dá pra trabalhar diretamente com a Hibernate Session (declarando def sessionFactory) mas não é o ideal pelo alto acoplamento.
Referências:
Active Record - <!-- m --><a class="postlink" href="http://martinfowler.com/eaaCatalog/activeRecord.html">http://martinfowler.com/eaaCatalog/activeRecord.html</a><!-- m -->
Unit of Work - <!-- m --><a class="postlink" href="http://martinfowler.com/eaaCatalog/unitOfWork.html">http://martinfowler.com/eaaCatalog/unitOfWork.html</a><!-- m -->
Leaky Abstraction - <!-- m --><a class="postlink" href="http://www.joelonsoftware.com/articles/LeakyAbstractions.html">http://www.joelonsoftware.com/articles/ ... tions.html</a><!-- m -->
Principle of Least Surprise -http://c2.com/cgi/wiki?PrincipleOfLeastSurprise
Pra seguir o padrão ActiveRecord no estilo Rails - onde a própria entidade de domínio possui métodos de persistência, o GORM acaba escondendo a natureza do cache de primeiro nível (Unit of Work) existente no Hibernate (que o GORM utiliza por trás pra persistir as entidades). Isto gera uma "abstração furada" (Leaky Abstraction) da sessão do Hibernate para o desenvolvedor.
Por exemplo, em algumas ocasiões as entidades de domínio enviam dados para o banco (flush automático), mesmo se ainda não foram salvas explicitamente com domain.save(), ocasionando registros salvos inesperadamente. Ou o contrário: não enviam dados para o banco (não efetuam flush), mesmo quando um domain.save() foi chamado, gerando problemas inesperados.
Isto fere gravemente o excelente Princípio da Menor Surpresa (Principle of Least Surprise) que encoraja que o resultado de uma operação deve ser ÓBVIA, CONSISTENTE e principalmente PREVISÍVEL. Este pontos acima não são previsíveis através das simples operações (save,update,etc.) da entidade. Principalmente pra quem não conhece Hibernate!
E então, pra arrumar este "furo na abstração", temos a "gambiarra" domain.save(flush:true) que não condiz com toda a elegância do GORM no Grails.
Então, hoje, em casos de uso com associações de entidades de domínios mais complexos, o desenvolvedor acaba apanhado um bocado se não conhecer bem o Hibernate. É uma pena...
Poderiam deixar a abstração menos furada se definissem uma abstração direta do cache intermediário (Unit of Work), ou deixassem o Hibernate do Grails configurado com StatelessSession, se parecendo mais com o Rails - de onde o Grails se inspira. O ideal mesmo seriam estas duas implementações. Uma para cada caso.
De qualquer forma, as vantagens de se utilizar Grails na plataforma Java são tão grandes que compensam tudo isso!. Pode ter certeza!
PS.: Em tempo, dá pra trabalhar diretamente com a Hibernate Session (declarando def sessionFactory) mas não é o ideal pelo alto acoplamento.
Referências:
Active Record - <!-- m --><a class="postlink" href="http://martinfowler.com/eaaCatalog/activeRecord.html">http://martinfowler.com/eaaCatalog/activeRecord.html</a><!-- m -->
Unit of Work - <!-- m --><a class="postlink" href="http://martinfowler.com/eaaCatalog/unitOfWork.html">http://martinfowler.com/eaaCatalog/unitOfWork.html</a><!-- m -->
Leaky Abstraction - <!-- m --><a class="postlink" href="http://www.joelonsoftware.com/articles/LeakyAbstractions.html">http://www.joelonsoftware.com/articles/ ... tions.html</a><!-- m -->
Principle of Least Surprise -http://c2.com/cgi/wiki?PrincipleOfLeastSurprise
14/12/2009 00:00
0
Bem interessante Wanderson. Já postou na grails-dev? Acho que dar uma bela discussão e alguns tickets do Jira. <!-- s:D --><img src="{SMILIES_PATH}/icon_biggrin.gif" alt=":D" title="Very Happy" /><!-- s:D -->
14/12/2009 00:00
0
Oi Raphael!
Todas as sugestões são bem-vindas! Vou me registrar por lá.
Somente agora estou tentando me engajar de fato na comunidade, apesar de já ter uma boa bagagem de Grails. Pura questão de foco - neste ano que passou foram muitos compromissos! Vou tentar manter o ritmo. Me ajudem!
Abraços!
Todas as sugestões são bem-vindas! Vou me registrar por lá.
Somente agora estou tentando me engajar de fato na comunidade, apesar de já ter uma boa bagagem de Grails. Pura questão de foco - neste ano que passou foram muitos compromissos! Vou tentar manter o ritmo. Me ajudem!
Abraços!
14/12/2009 00:00
0
Não gosto das constraints de validação que utlizam o banco de dados, como a nullable por exemplo.
20/05/2010 00:00
0
[quote="mchiareli"]Não gosto das constraints de validação que utlizam o banco de dados, como a nullable por exemplo.[/quote]
Interessante esta crítica, porque este é um recurso que normalmente o pessoal gosta muito.
Por que você não gosta das constraints mchiareli?
Interessante esta crítica, porque este é um recurso que normalmente o pessoal gosta muito.
Por que você não gosta das constraints mchiareli?
20/05/2010 00:00
0
Eu apenas não gosto das que ficam diretamente no banco de dados, as outras são ok.
Veja eu acho que isso é uma regra da aplicação, e não faz sentido ficar no banco de dados, prefiro deixar o banco apenas para guardar o dado,sem nenhuma regra, eu posso validar isso na minha aplicação, nao preciso que o banco faça isso por mim.
preferia que regras como nullable, tivessem uma logica propria e não dependessem do banco.
Nunca fui muito fã de banco de dados, principalmente quando o pessoal começa a enfiar procedures.
Veja eu acho que isso é uma regra da aplicação, e não faz sentido ficar no banco de dados, prefiro deixar o banco apenas para guardar o dado,sem nenhuma regra, eu posso validar isso na minha aplicação, nao preciso que o banco faça isso por mim.
preferia que regras como nullable, tivessem uma logica propria e não dependessem do banco.
Nunca fui muito fã de banco de dados, principalmente quando o pessoal começa a enfiar procedures.
20/05/2010 00:00
0
[quote="mchiareli"]Eu apenas não gosto das que ficam diretamente no banco de dados, as outras são ok.
Veja eu acho que isso é uma regra da aplicação, e não faz sentido ficar no banco de dados, prefiro deixar o banco apenas para guardar o dado,sem nenhuma regra, eu posso validar isso na minha aplicação, nao preciso que o banco faça isso por mim.
preferia que regras como nullable, tivessem uma logica propria e não dependessem do banco.
Nunca fui muito fã de banco de dados, principalmente quando o pessoal começa a enfiar procedures.[/quote]
Eu compartilho da sua opinião a respeito do abuso do banco de dados. Assim como você, também acho que os registros no banco de dados devem ser "apenas" o resultado de um processamento, e não a base para se construir uma aplicação.
Veja eu acho que isso é uma regra da aplicação, e não faz sentido ficar no banco de dados, prefiro deixar o banco apenas para guardar o dado,sem nenhuma regra, eu posso validar isso na minha aplicação, nao preciso que o banco faça isso por mim.
preferia que regras como nullable, tivessem uma logica propria e não dependessem do banco.
Nunca fui muito fã de banco de dados, principalmente quando o pessoal começa a enfiar procedures.[/quote]
Eu compartilho da sua opinião a respeito do abuso do banco de dados. Assim como você, também acho que os registros no banco de dados devem ser "apenas" o resultado de um processamento, e não a base para se construir uma aplicação.
20/05/2010 00:00
0
Eu compartilho da sua opinião a respeito do abuso do banco de dados. Assim como você, também acho que os registros no banco de dados devem ser "apenas" o resultado de um processamento, e não a base para se construir uma aplicação.
E se o banco de dados servir para varias aplicações? vamos ter que realizar esta validação em cada uma? utilizando recursos de processamento do banco de dados não deixa menor os custos de processamento na aplicação? sempre achei que fosse melhor utilizar ao máximo os recursos do BD, é claro, no limite de cada tarefa.
A unica coisa que não gostei no grails foi o plugins de portlets, não tive boa experiências com ele.
20/05/2010 00:00
0
Sobre portlet, você não precisa utilizar o plugin. Ele é somente um facilitador.
E plugin é algo que está fora do full-stack framework Grails e é mantido por terceiros. Neste ponto não podemos avaliar o Grails, mas sim a comunidade.
Em tempo, o plugin de portlets não tem mais suporte devido. Confira:
<!-- m --><a class="postlink" href="http://stackoverflow.com/questions/2673221/grails-portlets-for-liferay">http://stackoverflow.com/questions/2673 ... or-liferay</a><!-- m -->
Isso levanta a questão sobre o ecossistema de plugins. Acredito que cada download deveria ser associado a uma doação espontânea mínima.
E plugin é algo que está fora do full-stack framework Grails e é mantido por terceiros. Neste ponto não podemos avaliar o Grails, mas sim a comunidade.
Em tempo, o plugin de portlets não tem mais suporte devido. Confira:
<!-- m --><a class="postlink" href="http://stackoverflow.com/questions/2673221/grails-portlets-for-liferay">http://stackoverflow.com/questions/2673 ... or-liferay</a><!-- m -->
Isso levanta a questão sobre o ecossistema de plugins. Acredito que cada download deveria ser associado a uma doação espontânea mínima.
20/05/2010 00:00
0
[quote="mchiareli"]Não gosto das constraints de validação que utlizam o banco de dados, como a nullable por exemplo.[/quote]
A coisa ruim com relação a isso são as falhas silenciosas de validação.
Você chama o domain.save() e ele pode não ter concluido com sucesso a transação por erros de validação, te obrigando a utilizar a estratégia domain.validate() antes. Fica parecendo checked exceptions! =(
Hoje em dia pra diminuir o problema nós temos o domain.save(failOnError:true) que emite uma exceção caso tenha uma falha de validação.
Mas NOVAMENTE isso fere "de cum força" o Princípio da Menor Surpresa, assim como o domain.save(flush:true) que havia postado neste thread.
De qualquer forma, como já disse, são coisas chatas, mas pequenas diante da ENORME vantagem de se desenvolver com Groovy and Grails.
Mesmo com estes probleminhas, NÃO TROCO POR NADA! =)
PS.: Até hoje não postei isso na grails-dev por estar muito atarefado, mas eu não vou desistir de sugerir algumas coisas e levantar algumas discussões por lá! =)
A coisa ruim com relação a isso são as falhas silenciosas de validação.
Você chama o domain.save() e ele pode não ter concluido com sucesso a transação por erros de validação, te obrigando a utilizar a estratégia domain.validate() antes. Fica parecendo checked exceptions! =(
Hoje em dia pra diminuir o problema nós temos o domain.save(failOnError:true) que emite uma exceção caso tenha uma falha de validação.
Mas NOVAMENTE isso fere "de cum força" o Princípio da Menor Surpresa, assim como o domain.save(flush:true) que havia postado neste thread.
De qualquer forma, como já disse, são coisas chatas, mas pequenas diante da ENORME vantagem de se desenvolver com Groovy and Grails.
Mesmo com estes probleminhas, NÃO TROCO POR NADA! =)
PS.: Até hoje não postei isso na grails-dev por estar muito atarefado, mas eu não vou desistir de sugerir algumas coisas e levantar algumas discussões por lá! =)
20/05/2010 00:00
0
Interessante o que você falou wanderson, realmente eu não havia pensado nisso, é mais o peso da comunidade desenvolver do que do próprio grails, tem razão. E também nunca li este site que você colocou ali, muito legal não tinha ideia porque estava parado, mesmo assim seria interessante uma atualização no plugin quando o Spring Portlet suportar a JSR 286 (Há alguns sites que dizem que o Spring 3 suporta, mas o Spring Portlets não, algo bem confuso).
Uma duvida, há alguma maneira de validar somente um campo em um domain?, vi que tem o domain.validate(), mas seria interessante passar como parâmetro o valor de um atributo e seu valor, simplificaria bastante nas validações com ajax, existe isso?
Uma duvida, há alguma maneira de validar somente um campo em um domain?, vi que tem o domain.validate(), mas seria interessante passar como parâmetro o valor de um atributo e seu valor, simplificaria bastante nas validações com ajax, existe isso?
20/05/2010 00:00
0
Ola'
Que bom caminho este post esta' levando.
Entao, eu sou nova no Grails, entao ainda nao tenho muita opniao formada.\
Uma coisa que eu nao gostei no inicio foi a falta de controle (eu tinah vindo de outros frameworks que nao sao ageis), mas aos poucos fui percebendo que controle e' algo relativo, e tem como controlar sua app com Grails sim. So' esta' me dando trabalho <!-- s:D --><img src="{SMILIES_PATH}/icon_biggrin.gif" alt=":D" title="Very Happy" /><!-- s:D -->
Muito bem, eu concordo (e me desculpem, eu nao lembro quem foi) com o template do grails nao ser tabless. Uhn, nessas horas que eu preciso de ajuda do meu namorado (que entende de padroes css e html e esse escambau todo) para ficar tudo amigavel.
Sobre a conversa das constrains... uhn, me corrijam se eu estiver errada, mas ha outras maneiras no grails de controlar isso. E para mim ainda nao esta' dando problema usa-las. <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->
Desculpem os erros de portugues. Os odeio. E sobe acentuacao, esse teclado e' americano e as configuracoes do Solaris estao me deixando brava!
Que bom caminho este post esta' levando.
Entao, eu sou nova no Grails, entao ainda nao tenho muita opniao formada.\
Uma coisa que eu nao gostei no inicio foi a falta de controle (eu tinah vindo de outros frameworks que nao sao ageis), mas aos poucos fui percebendo que controle e' algo relativo, e tem como controlar sua app com Grails sim. So' esta' me dando trabalho <!-- s:D --><img src="{SMILIES_PATH}/icon_biggrin.gif" alt=":D" title="Very Happy" /><!-- s:D -->
Muito bem, eu concordo (e me desculpem, eu nao lembro quem foi) com o template do grails nao ser tabless. Uhn, nessas horas que eu preciso de ajuda do meu namorado (que entende de padroes css e html e esse escambau todo) para ficar tudo amigavel.
Sobre a conversa das constrains... uhn, me corrijam se eu estiver errada, mas ha outras maneiras no grails de controlar isso. E para mim ainda nao esta' dando problema usa-las. <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->
Desculpem os erros de portugues. Os odeio. E sobe acentuacao, esse teclado e' americano e as configuracoes do Solaris estao me deixando brava!
21/05/2010 00:00
0
[quote="kicolobo"][quote="mchiareli"]Eu apenas não gosto das que ficam diretamente no banco de dados, as outras são ok.
Veja eu acho que isso é uma regra da aplicação, e não faz sentido ficar no banco de dados, prefiro deixar o banco apenas para guardar o dado,sem nenhuma regra, eu posso validar isso na minha aplicação, nao preciso que o banco faça isso por mim.
preferia que regras como nullable, tivessem uma logica propria e não dependessem do banco.
Nunca fui muito fã de banco de dados, principalmente quando o pessoal começa a enfiar procedures.[/quote]
Eu compartilho da sua opinião a respeito do abuso do banco de dados. Assim como você, também acho que os registros no banco de dados devem ser "apenas" o resultado de um processamento, e não a base para se construir uma aplicação.[/quote]
Já viu alguem utilizando o grails com bancos "nosql"? Estava pensando sobre isso estes dias.
Veja eu acho que isso é uma regra da aplicação, e não faz sentido ficar no banco de dados, prefiro deixar o banco apenas para guardar o dado,sem nenhuma regra, eu posso validar isso na minha aplicação, nao preciso que o banco faça isso por mim.
preferia que regras como nullable, tivessem uma logica propria e não dependessem do banco.
Nunca fui muito fã de banco de dados, principalmente quando o pessoal começa a enfiar procedures.[/quote]
Eu compartilho da sua opinião a respeito do abuso do banco de dados. Assim como você, também acho que os registros no banco de dados devem ser "apenas" o resultado de um processamento, e não a base para se construir uma aplicação.[/quote]
Já viu alguem utilizando o grails com bancos "nosql"? Estava pensando sobre isso estes dias.
24/05/2010 00:00
0
Sobre este assunto de bancos de dados, abri um novo post off-topic!
Sobre Aplicações Programadas em Bancos de Dados
<!-- l --><a class="postlink-local" href="http://www.grailsbrasil.com/viewtopic.php?f=19&t=1006">viewtopic.php?f=19&t=1006</a><!-- l -->
Meu intuito é esclarecer que tudo na nossa área precisa de CONTEXTO! Contribuam!
Abraço!
Sobre Aplicações Programadas em Bancos de Dados
<!-- l --><a class="postlink-local" href="http://www.grailsbrasil.com/viewtopic.php?f=19&t=1006">viewtopic.php?f=19&t=1006</a><!-- l -->
Meu intuito é esclarecer que tudo na nossa área precisa de CONTEXTO! Contribuam!
Abraço!
25/05/2010 00:00
0
O que eu mais gosto no Grails é o Groovy.
O que eu menos gosto no Grails é também a sua melhor qualidade: o fato de ser compilado.
Isso complica um pouco deploys.
O que eu menos gosto no Grails é também a sua melhor qualidade: o fato de ser compilado.
Isso complica um pouco deploys.
13/07/2011 18:10
Ainda não faz parte da comunidade???
Para se registrar, clique aqui.
Aprenda Groovy e Grails com a Formação itexto!
Newsletter Semana Groovy
Os melhores blogs de TI (e em português) em um único lugar!
