Play Framework 2.0 será integrado ao pacote de ferramentas de desenvolvimento da Typesafe

JavaEvangelist Membro desde: 19/07/2006 18:53:36 Mensagens: 319 Offline

Uma revolução silenciosa no mundo Java parece estar acontecendo. A Typesafe(empresa por trás da linguagem Scala) anunciou que integrará a próxima versão do Play Framework a seu pacote de ferramentas de desenvolvimento(que atualmente inclui um binário de Scala, o framework Akka, o sbt e plugins para o Eclipse e alguns editores de texto). A empresa está inclusive cedendo programadores para adiantar o lançamento do Play 2.0, atualmente em beta.

As principais promessas do Play 2.0 são compilar até mesmo arquivos de configuração, melhorando ainda mais a sua já famosa validação "on the fly", além de adotar Scala como uma das linguagens oficiais paralelamente a Java.

Segue o anúncio oficial:
http://typesafe.com/company/news/15856

Segue também um curioso exemplo de erro de compilação num arquivo de rotas:
https://github.com/playframework/Play20/wiki/JavaRouting

Exagero a noticia nao ?

JavaEvangelist Membro desde: 01/02/2010 10:48:39 Mensagens: 372 Offline

Boa noticia.

Mas ainda não ficou claro o que irá acontecer com o framework Lift, que tem o mesmo objetivo do Play.
Mas de qualquer forma é interessante essa noticia, da escolha do Play, que é um baita framework.

johnny quest wrote:Boa noticia.

Mas ainda não ficou claro o que irá acontecer com o framework Lift, que tem o mesmo objetivo do Play.
Mas de qualquer forma é interessante essa noticia, da escolha do Play, que é um baita framework.

Não irá acontecer nada com ele. Ele continua sendo uma outra opção de framework web scala, como tantas outras que existem.

Há uma thread na lista do lift sobre isto: Play as a part of Typesafe stack, what is Lift's answer?, onde inclusive o David Polak fala que foi convidado para entrar para a Typesafe:

Just to set the record straight, I declined an invitation to work with TypeSafe (no, I will not discuss the reasons, not even privately, so don't even ask). The lack of endorsement is from me to TypeSafe, not from TypeSafe to Lift.

A Typesafe é apenas mais uma empresa, que adicionou um framework web ao seu stack!

Sobre o Play! 2.0, fiquei com vontade de dar uma olhada nele, nesta versão o suporte a Scala ficou nativo, antes era via plugin, inclusive parece que tem mais suporte a Scala do que java nesta versão.
Mas primeiro quero terminar meus estudos do Lift, para entao poder compara-los e escolher o que melhor me atende!

O bom do play é que tem um site mais amigavel e bem documentado, o Lift deixa a desejar um pouco neste quesito!

Gostei muito da notícia. A versão 2.0 do Play vai ser show de bola, mal posso esperar

Correndo o risco de gerar uma briga ao invés de uma discussão saudável, mas lá vai:

Sou o único preocupado com o tipo de código que esses frameworks Rails-like geram no longo prazo ?

A meu ver, usando esses frameworks que estimulam Active Record e esse excesso de responsabilidades em uma entidade*(mais um struct com acesso ao DB que uma entidade de fato) a tendência é ir fazendo algo cada vez menos OO, ao menos do ponto da coerência do objeto.

Sei que é possível fazer diferente com esses frameworks, mas dificilmente alguém vai, conscientemente selecionar um framework e fazer algo diferente dos moldes que ele propõe(sacrificando assim a tão divulgada produtividade).

Pela minha experiência grande parte dos grandes softwares surgem a partir de pequenas versões, então aquela idéia de que esses frameworks poderiam ser aplicados a projetos de menor parte também é perigosa.

Gostaria de ouvir a opinião de vocês, não sei se estou sendo purista demais.

Abs

JavaTeenager Membro desde: 08/10/2011 13:21:59 Mensagens: 150 Offline

The language is a well-meaning attempt to create something with a higher abstraction level. But what got created is a language that has huge inherent complexity and doesn't really address the true issues that developers face today, yet is being pitched as being a suitable replacement for Java, something which I find to be bonkers.

http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html

This message was edited 1 time. Last update was at 22/11/2011 09:01:23

GraveDigger wrote:Correndo o risco de gerar uma briga ao invés de uma discussão saudável, mas lá vai:

Sou o único preocupado com o tipo de código que esses frameworks Rails-like geram no longo prazo ?

A meu ver, usando esses frameworks que estimulam Active Record e esse excesso de responsabilidades em uma entidade*(mais um struct com acesso ao DB que uma entidade de fato) a tendência é ir fazendo algo cada vez menos OO, ao menos do ponto da coerência do objeto.

Sei que é possível fazer diferente com esses frameworks, mas dificilmente alguém vai, conscientemente selecionar um framework e fazer algo diferente dos moldes que ele propõe(sacrificando assim a tão divulgada produtividade).

Pela minha experiência grande parte dos grandes softwares surgem a partir de pequenas versões, então aquela idéia de que esses frameworks poderiam ser aplicados a projetos de menor parte também é perigosa.

Gostaria de ouvir a opinião de vocês, não sei se estou sendo purista demais.

Abs

O Play não sei pq nunca estudei, mas o Lift oferece 3 opções de camada de persistencia: Record, Mapper(Esta dizem ser parecida com o Active Record: " At a high level, Mapper takes a design direction that is similar, but not
completely truthful to the Active Record pattern") e JPA.

A indicada como mais robusta é o Record, mas falam que para a maioria dos casos de apps pequenos e tals, voce pode começar com Mapper que da conta do recado.

fredferrao wrote:

GraveDigger wrote:Correndo o risco de gerar uma briga ao invés de uma discussão saudável, mas lá vai:

Sou o único preocupado com o tipo de código que esses frameworks Rails-like geram no longo prazo ?

A meu ver, usando esses frameworks que estimulam Active Record e esse excesso de responsabilidades em uma entidade*(mais um struct com acesso ao DB que uma entidade de fato) a tendência é ir fazendo algo cada vez menos OO, ao menos do ponto da coerência do objeto.

Sei que é possível fazer diferente com esses frameworks, mas dificilmente alguém vai, conscientemente selecionar um framework e fazer algo diferente dos moldes que ele propõe(sacrificando assim a tão divulgada produtividade).

Pela minha experiência grande parte dos grandes softwares surgem a partir de pequenas versões, então aquela idéia de que esses frameworks poderiam ser aplicados a projetos de menor parte também é perigosa.

Gostaria de ouvir a opinião de vocês, não sei se estou sendo purista demais.

Abs

O Play não sei pq nunca estudei, mas o Lift oferece 3 opções de camada de persistencia: Record, Mapper(Esta dizem ser parecida com o Active Record: " At a high level, Mapper takes a design direction that is similar, but not
completely truthful to the Active Record pattern") e JPA.

A indicada como mais robusta é o Record, mas falam que para a maioria dos casos de apps pequenos e tals, voce pode começar com Mapper que da conta do recado.

A versão atual utiliza JPA para a persistência, mas a idéia é que na versão 2.0 qualquer tipo de persistência seja possível (mesmo de bancos não relacionais).

A versão atual é focada principalmente na produtividade. Creio que o framework estabelecerá uma boa relação entre as características de qualidade de código/arquitetura/design e produtividade na próxima versão (2.0).

[]'s

GraveDigger wrote:Sou o único preocupado com o tipo de código que esses frameworks Rails-like geram no longo prazo ?

A meu ver, usando esses frameworks que estimulam Active Record e esse excesso de responsabilidades em uma entidade*(mais um struct com acesso ao DB que uma entidade de fato) a tendência é ir fazendo algo cada vez menos OO, ao menos do ponto da coerência do objeto.

Quando eu programo Java eu uso os famosos DAOs, mas qual o problema do ActiveRecord?. Eu gosto muito de Rails e acho esse padrão (ActiveRecord) infinitamente superior. Eu não consigo entender como alguém que já usou as facilidades do Rails como o Arel, Named Scopes, Validações e Nested Attributes. prefere usar DAOs. O código com Rails fica muito mais elegante, enxuto e reutilizável. Por isso eu vejo com bons olhos esses frameworks que visam trazer isso pro Java

Desde quando Entidade rica é menos OO? Pra mim menos OO é entidade com com propriedades públicas e mais nada. Separar em camadas não significa OO. Até em C vc cria um Struct com propiedades públicas e cria uma camada pra acessar ele no banco

Adelar wrote:

fredferrao wrote:
O Play não sei pq nunca estudei, mas o Lift oferece 3 opções de camada de persistencia: Record, Mapper(Esta dizem ser parecida com o Active Record: " At a high level, Mapper takes a design direction that is similar, but not
completely truthful to the Active Record pattern") e JPA.

A indicada como mais robusta é o Record, mas falam que para a maioria dos casos de apps pequenos e tals, voce pode começar com Mapper que da conta do recado.

A versão atual utiliza JPA para a persistência, mas a idéia é que na versão 2.0 qualquer tipo de persistência seja possível (mesmo de bancos não relacionais).

A versão atual é focada principalmente na produtividade. Creio que o framework estabelecerá uma boa relação entre as características de qualidade de código/arquitetura/design e produtividade na próxima versão (2.0).

[]'s

O record do Lift faz isto, na verdade ele é meio que uma especificação, no core do lift ja vem implmentado record para MongoDB, CouchDB e Squeryl, este ultimo suporta uma variedade de DB's: Supported Databases

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