Um tanto quanto interessante esse framework, com a mesma ideologia do ruby on rails vale apena um investimento… nao cheguei a olhar ele com mais detalhes, mas tentar evitar essa forma de template com algo mais nao tão “diferente” pode ser uma općão…
no mais pra quem já conhece a ideologia do 37signals e do proprio rails ( webserver embutido… cobertura 100% de testes… etc… ) … esse parece ser um bom framework!
[quote=fabiozoroastro]Não chegaram um pouco tarde demais?
Kd o Mentawai? Ainda existe?[/quote]
Existe sim.
E ja tem até integração para usar com o Adobe Flex 
O Play Framework tem umas features bem interessantes para a versão 1.1. Vocês chegaram a dar uma olhada na documentação? Vejam:
Scala
http://www.playframework.org/documentation/1.1-trunk/scala
LambdaJ
http://www.playframework.org/documentation/1.1-trunk/lambdaj
Vocês acham que adicionar suporte para Scala pode trazer bons benefícios para o projeto?
Vocês utilizariam os recursos do lambdaj, como por exemplo, Closures?
PriceWatcher priceWatcher = new PriceWatcher();
Car.forEach(cars); {
of(priceWatcher).setPrice(var(Car.class));
}
Realmente, não é um apenas um “framework web”, é uma plataforma no mesmo estilo do Grails. Sei lá, acho que o Grails ja está aí e tem mais maturidade para quem investe em desenvolvimento orientado a linguagens dinamicas, etc. A fatia do bolo do play! fica para os visionários, por enquanto.
Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
[quote=javamaniaco]Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
[/quote]
E voce acha que um framework que cria tantas camadas de abstracao como os “Rails Styles” o fazem sem memoria ?
Acho que esta na hora de voce comecar a realizar testes e não “ouvir o cara que disse, que um dia…”
O Grails é um exemplo de como vc nao precisa criar uma “plataforma iteira” para conseguir algo descente…
Mas como eu sempre digo… nao precisa cortar os pulsos 
dar tempo ao tempo 8)
[quote=javamaniaco]Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
[/quote]
Sua aplicação web tem quantos usuários pra isso ser um problema?
[quote=javamaniaco]Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
[/quote]
Olá
em que embasamento vc diz isso?
[quote=ramilani12][quote=javamaniaco]Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
[/quote]
Olá
em que embasamento vc diz isso?[/quote]
Faz um CRUD e coloca uns profiling pra rodar. Ai vc me diz a diferença. Se não souber fazer isso, lamento.
[quote=chun][quote=javamaniaco]Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
[/quote]
E voce acha que um framework que cria tantas camadas de abstracao como os “Rails Styles” o fazem sem memoria ?
Acho que esta na hora de voce comecar a realizar testes e não “ouvir o cara que disse, que um dia…”
O Grails é um exemplo de como vc nao precisa criar uma “plataforma iteira” para conseguir algo descente…
Mas como eu sempre digo… nao precisa cortar os pulsos
[/quote]
Olha, o mesmo exemplo em Rails, com JRuby, até pode ser, o Grails ganha em menos memória. Mas vamos ver se esse ai que lançaram não papa memória como o Grails, ou vai dizer que pra rodar um aplicativo besta agora vou ter que reservar 256MB de memória dedicada só pra começar?
Se for assim, volto pro velho Servlet-JSP, é mais demorado, mas não come memória.
O grails não consome muita memória até porque 80%+ é feito em java. O problema do footprint gigante é o groovy coloca 45mb só de ExpandoMetaClasses durante o boot.
@mochuara
Esse problema do footprint inicial alto não interfere muito quando escalando verticalmente. O consumo por thread é bem baixo. É sim um problema serio quando se precisa hospedar em maquinas com pouca memória(menos de 512mb).
E esse play não é bem novo, existe desde 2007/2008 acho. E é até uma prova de conceito legal, usar tudo estatico e stateless. Mas nao parece que vai crescer muito.
Por ser stateless e sem spring, etc o consumo de memória do Play é extremamente baixo.
Grails e SpringRoo(que sim é muito novo) são muito mais maduros, evoluem muito mais rápido e acho que são mais promissores para atrair programadores java.
PS: A melhor ide pra se programar em grails nao é mais o Netbeans, mas o Eclipse com SpringSource Tool Suite, principalmente a versão 2.2.1. Em poucos meses os caras da SpringSource conseguiram ultrapassar o NB e devem ultrapassar até o Intellij logo logo.
[quote=xymor]O grails não consome muita memória até porque 80%+ é feito em java. O problema do footprint gigante é o groovy coloca 45mb só de ExpandoMetaClasses durante o boot.
[/quote]
Durante o boot nada. Fica monitorando 24 horas e você perceberá que um CRUD besta fica alocando memória que o mesmo com até o JSF + Hibernate e Spring não ocorre. E é apenas um CRUD. Quando você começa a manipular o danado, mexer mesmo, a memória vai comendo, sem dó. Depois os objetos demoram mais para serem desalocados. Mais pesado que Grails até hoje que vi só o JRuby com Rails e o Seam.
Eu sei que programadores adoram otimizar até o ultimo bit da sua aplicação mas avaliar framework web pelo consumo de memória que é muito mais barato do que tempo de desenvolvimento mostra a falta de visão que alguns, ainda que tecnicamente competentes, têm das reais necessidades enfrentada pelas empresas que precisam colocar uma projeto web no ar.
[quote=javamaniaco][quote=chun][quote=javamaniaco]Pode chorar Chun, quem não conhece que compre sua ideia. O Grails come memória e ponto. Aliás, ele é um papa memória.
[/quote]
E voce acha que um framework que cria tantas camadas de abstracao como os “Rails Styles” o fazem sem memoria ?
Acho que esta na hora de voce comecar a realizar testes e não “ouvir o cara que disse, que um dia…”
O Grails é um exemplo de como vc nao precisa criar uma “plataforma iteira” para conseguir algo descente…
Mas como eu sempre digo… nao precisa cortar os pulsos
[/quote]
Olha, o mesmo exemplo em Rails, com JRuby, até pode ser, o Grails ganha em menos memória. Mas vamos ver se esse ai que lançaram não papa memória como o Grails, ou vai dizer que pra rodar um aplicativo besta agora vou ter que reservar 256MB de memória dedicada só pra começar?
Se for assim, volto pro velho Servlet-JSP, é mais demorado, mas não come memória.[/quote]
Voce nunca ouviu falar em “pré alocação” ?
“Heap” para voce eh algum tipo de condimento para macarronada ?
Profillers adicionam um overhead gigantesco na execucao , não podem ser utilizados para medir “consumo” de forma burra (crtl+alt+del , ir no processo java e ver quanto ele consome)
E sim , quanto mais abstrair , mais memoria e mais recursos voce vai precisar… isso é FATO…
Se vc quer performance escovando o ultimo bit… entao volte para os cgi-bin escritos em C…
Como mudar linguagem e framework não deve ser problema para nós desenvolvedores, simplesmente mude de framework. Se você desaprova o consumo de memória, seja mais um a rejeitar o framework. Com tantas opções de frameworks bons (assim como o próprio Grails) dê a você mesmo o luxo de rejeitá-los por estes detalhes. Utilizar o framework é como se fosse um voto, confirmando de que ele está indo no caminho certo. Prefira aquele que está, no seu ponto de vista, indo para o caminho certo 
[quote=javamaniaco][quote=xymor]O grails não consome muita memória até porque 80%+ é feito em java. O problema do footprint gigante é o groovy coloca 45mb só de ExpandoMetaClasses durante o boot.
[/quote]
Durante o boot nada. Fica monitorando 24 horas e você perceberá que um CRUD besta fica alocando memória que o mesmo com até o JSF + Hibernate e Spring não ocorre. E é apenas um CRUD. Quando você começa a manipular o danado, mexer mesmo, a memória vai comendo, sem dó. Depois os objetos demoram mais para serem desalocados. Mais pesado que Grails até hoje que vi só o JRuby com Rails e o Seam.[/quote]
O consumo é maior que uma app em java puro, claro, mas não identifiquei tanto esse problema talvez por estar usando o G1GC.
O problema com do consumo excessivo por um CRUD pode ser devido a um bug na validação. Qual a versão testada?
apenas mais um “grao de areia na praia”.
kkkk Sotaque de japonês da porra o cara do vídeo…
Poxa gostei, eu que já mexi um tempinho com rails achei bem fácil. Espero que isso amadureça