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

Assuntos Gerais Notícias
#1

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

#2

Exagero a noticia nao ?

#3

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.

#4

[quote=johnny quest]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.[/quote]

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:

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!

#5

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

#6

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

#7
#8

[quote=GraveDigger]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[/quote]

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.

#9

[quote=fredferrao][quote=GraveDigger]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[/quote]

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.[/quote]
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

#10

[quote=GraveDigger]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.[/quote]

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

#11

[quote=Adelar][quote=fredferrao]
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.[/quote]
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
[/quote]

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

#12