Introducing Play 2.0

2,439 views
Skip to first unread message

Guillaume Bort

unread,
Sep 7, 2011, 5:39:15 AM9/7/11
to play-fr...@googlegroups.com
Hi everyone,

Since 2007, we have been working on making Java web application
development easier. Play started as an internal project at Zenexity
and was heavily influenced by our way of doing Web projects: focusing
on developer productivity, respecting Web architecture, and using from
the start a fresh approach to packaging conventions - breaking where
it made sense the so-called JEE best practices.

In 2009, we decided to share these ideas with the community as an open
source project. The immediate feedback was extremely positive and the
project gained a lot of traction. Today - after two years of active
development - Play has several versions, an animated community of
3,000 people, with a growing number of applications running in
production all over the globe.

Opening a project to the world certainly means more feedback, but it
also means discovering and learning about new use cases, requiring
features and un-earthing bugs that we were not specifically considered
in the original design and assumptions. During the two years of work
on Play as an open source project we have worked to fix all of these
kind of issues, as well as to integrate new features to support a
wider range of scenarios. As the project has grown, we have learned a
lot from our community and from our own experience - using Play in
more and more complex and varied projects.

In the meantime, technology and the Web have continued to evolve. The
Web has become the central point of all applications. HTML, CSS and
Javascript technologies have evolved quickly - making it almost
impossible for a server side framework to follow. The whole Web
architecture is fast moving towards real-time, and the emerging
requirements of today's project profiles means SQL no longer works as
the exclusive datastore technology. At the programming languages level
we've witnessed some monumental changes with several JVM languages,
including Scala, gaining popularity.

That's why we think it's now time to move on, and to consider the next
major version of Play. Welcome Play 2.0!

Native support for Java and Scala
---------------------------------

In Play 1.1, we started exploring the possibility of using the Scala
programming language for writing Play applications. We initially
introduced this work as an external module to be able to experiment
freely without impacting the framework itself.

Properly integrating Scala into a Java-based framework is not trivial.
Considering Scala’s compatibility with Java, one can quickly achieve a
first naive integration that simply uses Scala’s syntax instead of
Java’s. This, however, is certainly not the optimal way of using the
language. Scala is a mix of true object orientation with functional
programming. Leveraging the full power of Scala requires rethinking
most of the framework’s APIs. After several versions we now have a
clean Scala module that allows the use of most of Play's features from
Scala, in a Scala-ish manner.

Now, we are reaching the limits of what we can do with Scala support
as a separate module. Initial design choices we made in Play 1.x,
relying heavily on Java reflection API and byte code manipulation,
have made it harder to progress without completely rethinking some
essential parts of Play’s internals. Meanwhile, we have created
several awesome components for the Scala module, like the new
type-safe template engine and the brand new SQL access component
Anorm. So we have decided that, to fully unleash the power of Scala
with Play, we are moving Scala support from a separate module to the
core of Play 2.0, which will be designed from the beginning to
natively support Scala as a programming language.

Java, on the other hand, is certainly not getting any less support
from Play 2.0; quite the contrary. The Play 2.0 build provides us with
an opportunity to enhance the development experience for Java
developers. Backed by our experience throughout the project we have a
clear idea of what we need to achieve and what mistakes we have to
avoid.

Powerful build system
---------------------

From the beginning we have chosen a fresh way to run, compile and
deploy Play applications. At the time it may have looked like an
esoteric design - but it was crucial to providing an asynchronous HTTP
API instead of the standard Servlet API, short feedback cycles through
live compilation and reloading of source code during development, and
promoting a fresh packaging approach. Consequently, It was difficult
to make Play follow the standard JEE conventions.

Today, this idea of container-less deployment is more and more
accepted in the Java world. It's a design choice that has allowed the
Play framework to run natively on platforms like Heroku, which
introduced a model that we consider the future of Java applications
deployment on elastic PaaS platforms.

Existing Java build systems, however, were not flexible enough to
support this new approach. Since we wanted to provide straightforward
tools to run and deploy Play applications, in Play 1.x we created a
collection of Python scripts to handle all build and deployment
related tasks.

But developers using Play for more enterprise-scale projects, which
require build process customization and integration with their
existing company build systems, were a bit lost. The Python scripts we
provide with Play 1.x are in no way a fully featured build system and
are not easily customizable. That's why we've decided to go for a more
powerful build system for Play 2.0.

As we need a modern build tool, flexible enough to support Play
original conventions and able to build Java and Scala projects, we
have chosen to integrate SBT in Play 2.0. This, however, should not
scare existing Play users who are happy with the simplicity of Play
build. We are leveraging the same simple play new, run, start
experience on top of an extensible model: Play 2.0 will come with a
preconfigured build script that will just work for most users. On the
other hand, if you need to change the way your application is built,
deployed, etc., a Play project being a standard SBT project will hand
you all the power to customize and adapt it to your special needs.
This also mean better integration with Maven projects out of the box,
the ability to package and publish your project as a simple set of jar
files to any repository, and especially live compiling and reloading
at development time of any depended project even for standard Java or
Scala libraries projects.

Focused on type safety
----------------------

One benefit of using Java as programming language for writing Play
applications is that the Java compiler can check certain parts of your
code. This is not only useful for detecting mistakes early in the
development process, but it also makes it a lot easier to work on
large projects with a lot developers involved.

Adding Scala to the mix for Play 2.0, we will clearly benefit from
even stronger compiler guarantees - but that’s not enough. In Play
1.x, the template system is dynamic, based on the Groovy language, and
the compiler can’t do much for you. As a result, errors in templates
can only be detected at runtime. The same goes for verification of
glue code with controllers.

We really want to push further this idea of having Play check most of
your code at compilation time in the 2.0 version. Accordingly, we have
decided to use the Scala based template engine as the default for Play
applications - even for developers using Java as the main programming
language. This doesn't mean that you have to become a Scala expert to
write templates in Play 2.0, just like you were not really required to
know Groovy to write templates in Play 1.x. Scala will be mainly used
to navigate your object graph in order to display relevant information
with a syntax that is very close to the Java one. However if you want
to unleash the power of Scala to write advanced templates
abstractions, you will quickly discover how Scala, being expression
oriented and functional, is a perfect fit for a template engine.

And that's not only true for the template engine: the routing system
will also be fully type-checked. Play 2.0 will check all your routes'
descriptions, and verify that the everything is coherent, including
the reverse routing part.

As a nice side effect, being fully compiled, the templates and route
files will be easier to package and reuse and you can expect high
performance gain on these parts at runtime.

Built for asynchronism
----------------------

Today's web applications are integrating more concurrent realtime
data, so web frameworks need to support a full asynchronous HTTP
programming model. Play 1.x was initially designed to handle classic
Web applications with many short lived requests. But now, the event
model is the way to go for persistent connections - though comet,
long-polling and WebSockets.

Play 1.2 already provides great asynchronous HTTP support and
WebScokets using continuations. Play 2.0 will be architected from the
start under the assumption that every request is potentially long
living. We want, for instance, to generalize Controller and
WebsocketController concepts into one single simple model that fits
all needs.

But that’s not all: we also need a powerful way to schedule and run
long running tasks. Although the original Play 1.0 Jobs model was
introduced for this, we really need something more powerful and
robust. The Actor based model is unquestionably the best model today
to handle highly concurrent systems, and the best implementation of
that model available for both Java and Scala is Akka - so it's going
in. We will be introducing native Akka support for Play applications,
making it possible to write highly distributed systems.

Datastore and Model integration
-------------------------------

Datastore is no longer synonymous with "SQL database", and it probably
never was. A lot of interesting models of datastores are becoming
popular, providing different properties for different scenarios. For
this reason it has become difficult for a Web framework like Play to
make bold assumptions regarding the kind of datastore that will be
used by developers. A generic play.db.Model concept in Play no longer
makes sense, since it is almost impossible to abstract over all these
kinds of technology with a single API.

We want to make it really easy in Play 2.0 to use any datastore
driver, ORM, or any another database access library without any
special integration with the Web framework. We simply want to offer a
minimal set of helpers to handle common technical issues, like
managing the connection bounds. We also want, however, to maintain the
full-stack aspect of Play framework by bundling default tools to
access classical databases for users that don't have specialized
needs.

Today, the preferred way for a Play Java application to access an SQL
database is the Play Model library that is powered by Hibernate. But
since it's annoying in a stateless Web framework like Play to manage
stateful entities such as the ones defined in the official JPA
specification, we have provided a special flavor of JPA keeping things
as stateless as possible. This forced us to hack Hibernate in a way
that is probably not sustainable in the long term. To address this, we
plan to move to an existing implementation of stateless JPA called
EBean. If you don't care too much about what is used under the hood
then it will change almost nothing for you, but if you really want to
use Hibernate or even another official JPA implementation you will be
able to do it without any special integration with Play. And if you
are using Scala we will continue to bundle Anorm.

Changes for current Play users
------------------------------

Play 2.0 will be a major release so it is unlikely that it will be
compatible at the API level with previous versions. Of course at the
architecture level you will find the same set of components, organized
in the same way, and most importantly, you will live the same 'Play
experience'.

What about my existing Play applications? How difficult will it be to migrate?

Don't worry, we don't expect you to migrate your existing applications
to Play 2.0. The Play 1.x versions will continue to be maintained and
you don't need to move to Play 2.0. We ourselves have many Play 1.x
web applications running and we will of course continue to support
them.

Remember: Play 1.2.3 is still the best way to write Web applications
in Java while Play 2.0 is still under development, and will continue
to be maintained and developed by the core team and contributors. Play
2.0 is an opportunity to move to for your next project, or the next
major rewrite of your application.

Getting started
---------------

Play 2.0 is still under heavy development and APIs are likely to
change, but you can already have a look to our preview versions. We
have set up a new GitHub repository to host the development, and we
have released a first preview version.

On the dedicated page at http://www.playframework.org/2.0, you can
track progress on this exiting project.

Have fun!

--
Guillaume Bort, http://guillaume.bort.fr

GrailsDeveloper

unread,
Sep 7, 2011, 6:12:57 AM9/7/11
to play-framework
Hi,

that sound like a good new direction for play. Would be great to have
the possibility to use the Scala-Template right now in a java-play-
project. Perhaps someone can show how this is possible. This enables
to avoid a migration of the templates.
2 question are still open to me:

1. Will the new framework mainly developed in Scala? I think this is
an important issue, because at the moment it's really easy for an
experienced java developer to analyze the code and create patches. How
will it be in the future? In other words, will you try to write as
much code as possible in Java and use only Scala where necessary or
the other way around?

2. CRUD based at the moment bold on JPA. Will there be a CRUD-Module
in the future?

Wish you great luck and a quick progress on Play 2.0. A beta at the
end of the year sounds great to me.

Niels
> On the dedicated page athttp://www.playframework.org/2.0, you can

Pascal Voitot Dev

unread,
Sep 7, 2011, 6:27:33 AM9/7/11
to play-fr...@googlegroups.com
Globally, this sounds good new directions...

I have the same questions as Niels.

Moreover, when you foresee to integrate EBean, please also think about other frameworks (mine is siena as you may know) which will need to be integrated and do not wire everything too much tightly. In an ideal world, I would like to be able to remove completely EBean if I don't want it and replace it by Siena!

Anyway, I'm eager to see next steps and if you need help, don't hesitate to ask!

regards
Pascal


--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.


Bing Ran

unread,
Sep 7, 2011, 6:34:35 AM9/7/11
to play-fr...@googlegroups.com
I kind of like having another pure Scala framework created that is a port of the current Play Java and let the current Play be pure Java.

Bing

Guillaume Bort

unread,
Sep 7, 2011, 6:36:12 AM9/7/11
to play-fr...@googlegroups.com
> 1. Will the new framework mainly developed in Scala? I think this is
> an important issue, because at the moment it's really easy for an
> experienced java developer to analyze the code and create patches. How
> will it be in the future? In other words, will you try to write as
> much code as possible in Java and use only Scala where necessary or
> the other way around?

Most part of the core (HTTP and asynchronous invocation handling) will
be written in Scala, because it is really easier and more robust
(avoiding mutable states in this part will just make it easier to
debug and maintain).

But all the Java related API will be written in Java. Because we want
to provide an idiomatic API for Java and not force Java developers to
deal with Scala types. Also we want to have a clean Javadoc for the
Java API.

> 2. CRUD based at the moment bold on JPA. Will there be a CRUD-Module
> in the future?

I don't think so, or perhaps as an external module for particular ORM.
But trying to provide an unified CRUD module for all persistence
engines we can imagine is way too difficult. Anyway I think that the
current CRUD module is not flexible enough. It mainly solve the need
of writing a lot of repetitive screens, but It think it can be solved
with a better form/paginated list, tag components instead. But nothing
is decided yet.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

Guillaume Bort

unread,
Sep 7, 2011, 6:39:02 AM9/7/11
to play-fr...@googlegroups.com
> Moreover, when you foresee to integrate EBean, please also think about other
> frameworks (mine is siena as you may know) which will need to be integrated
> and do not wire everything too much tightly. In an ideal world, I would like
> to be able to remove completely EBean if I don't want it and replace it by
> Siena!

It exactly what we count on. That's why, even if we provide a default
ORM for Java to keep the fullstack aspect of Play, allowing users to
create quickly web applications, we won't integrate it too much with
the other parts of the framework. It is really important for us that
we can use whatever persistence engine you want with Play 2.0, without
need to hack it.

Please track the progress, and if you think that we make choice that
could limit integration with other persistence engine, in particular
Siena, tell us!

Pascal Voitot Dev

unread,
Sep 7, 2011, 6:44:52 AM9/7/11
to play-fr...@googlegroups.com
On Wed, Sep 7, 2011 at 12:39 PM, Guillaume Bort <guillau...@gmail.com> wrote:
> Moreover, when you foresee to integrate EBean, please also think about other
> frameworks (mine is siena as you may know) which will need to be integrated
> and do not wire everything too much tightly. In an ideal world, I would like
> to be able to remove completely EBean if I don't want it and replace it by
> Siena!

It exactly what we count on. That's why, even if we provide a default
ORM for Java to keep the fullstack aspect of Play, allowing users to
create quickly web applications, we won't integrate it too much with
the other parts of the framework. It is really important for us that
we can use whatever persistence engine you want with Play 2.0, without
need to hack it.

great :)
 

Please track the progress, and if you think that we make choice that
could limit integration with other persistence engine, in particular
Siena, tell us!


Yes now that Siena is near its final version 1.0.0 (just need mongoDB impl to definitely prove the design works), I will look at play2.0 a bit nearer and will tell you if I see any problems... Your scala evolution will certainly help me to develop the Siena4Scala also!
 
Pascal

Guillaume Bort

unread,
Sep 7, 2011, 6:46:46 AM9/7/11
to play-fr...@googlegroups.com
Developing a Web framework like Play is a lot of work, and maintaining
2 different versions would be terribly difficult. It's already the
case currently with the Scala module that is always behind the main
framework.

We prefer to merge efforts to provide a single perfect framework that
will support Scala and Java independently.

Pascal Voitot Dev

unread,
Sep 7, 2011, 6:51:28 AM9/7/11
to play-fr...@googlegroups.com
I agree with you...
Now that I know better Scala (and love it more and more), I know that you can write the core in Scala and make it fully available to any Java application and provide some external full-Java APIs without any problem.
The only drawback is for people who liked to modify the code and now they will need to know Scala. But anyway, I agree with you, maintaining 2 frameworks would be crazy!

pascal

Hristo Deshev

unread,
Sep 7, 2011, 7:08:32 AM9/7/11
to play-fr...@googlegroups.com
This is both good and bad news. While new and shiny stuff is always great, I guess nobody likes the idea of having a completely different Play framework. I hope you guys are able to define a clear migration path for 1.2.3. users that want to move to 2.0. Especially the ones like me that use the Scala plugin.

One question - will play-scala 1.x eventually move to Scala 2.9.1? I hope that feature isn't planned for the 2.0 version only.

Best,
Hristo

Guillaume Bort

unread,
Sep 7, 2011, 7:18:08 AM9/7/11
to play-fr...@googlegroups.com
> This is both good and bad news. While new and shiny stuff is always great, I
> guess nobody likes the idea of having a completely different Play framework.
> I hope you guys are able to define a clear migration path for 1.2.3. users
> that want to move to 2.0. Especially the ones like me that use the Scala
> plugin.

If you are using the Scala module currently, the migration path to
Play 2.0 will be easy. The most important change that will make
migration to Play 2.0 difficult is the new type safe template engine.
But if you are already using it it will be easy.

> One question - will play-scala 1.x eventually move to Scala 2.9.1? I hope
> that feature isn't planned for the 2.0 version only.

Problem is that Scala 2.9.0 breaks the Java reflection API (they done
it for good reasons however). So migrating the Scala module to 2.9.x
breaks almost everywhere it uses Java reflection API(binding,
fixtures, etc.). It's almost impossible to migrate without rewriting
these parts.

Ivan Meredith

unread,
Sep 7, 2011, 7:24:16 AM9/7/11
to play-fr...@googlegroups.com
Nice! Great to see scala 2.9 in the repo :D

I see anorm hasn't bean ported yet... btw, I take it you meant ebean
for java, anorm still preferred for scala?

Dave Cheong

unread,
Sep 7, 2011, 7:35:00 AM9/7/11
to play-fr...@googlegroups.com
Thanks for the update Guillaume. 

Looks like you are continuing to push the envelope with Play. I know it must have been hard to make the call to make a drastic non-backward compatible change in Play 2.0, but I think it's the right move. I wonder how this will impact the 3rd party modules already available for Play 1.x. How different are things? Would a lot of the modules need to be upgraded?

For me, Play has really been a boon to productivity. I use it all the time and recommend it to everyone I come across. The biggest hurdle is definitely the view/templating layer - it is where I spend 70% of my time at when coding a Play application. There's still a lot of hand crafting and because of its nature, IDE support is pretty bad. I hope the new templating technology alleviates this problem.

dave

Michael Boyd

unread,
Sep 7, 2011, 7:47:17 AM9/7/11
to play-framework
I use Play every day in many sites, and I'm now really excited about
Play 2! I'm sure it will be great.

However, can I make one suggestion? Don't re-invent the wheel with
type-safe declarations in the Scala templates.
Instead, I think you should use the declarations used in a popular JS
templating library -- preferably Closure Templates/Library.
I do this right now in tags and views, and it makes converting to
Closure Templates much easier:

*{
@param {String} _title
@param {Collection} _items
@param {play.mvc.Router.Route?} _pageLoadUrl (the ? indicates
optional)
}*
...the actual template here...
<h1>${_title}</h1>

Rakesh Waghela

unread,
Sep 7, 2011, 8:02:19 AM9/7/11
to play-fr...@googlegroups.com
Windows is not supported yet ?

Ivan Meredith

unread,
Sep 7, 2011, 8:05:34 AM9/7/11
to play-fr...@googlegroups.com
I imagine you just need to make a windows version of
https://github.com/playframework/Play20/blob/master/play

On 8 September 2011 00:02, Rakesh Waghela <java...@gmail.com> wrote:
> Windows is not supported yet ?
>

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/4WHeNxHSXCAJ.

Daryl

unread,
Sep 7, 2011, 8:21:56 AM9/7/11
to play-framework
Hi

I am going to disagree with some people here, and make a plea to go
the extra mile to make upgrades from old versions as painless as
possible.

You are obviously trying to move things forward, but don't annoy
existing users. We have been using play for live client projects since
version 1.0.1, we are currently running all live applications
(currently about 20) on 1.0.3.3. We have already struggled to upgrade
to 1.2.3 due to fairly large API changes, which in many cases could
have been minimised by keeping some backwards compatible methods while
still adding the new functionality. But the changes have been quite
ruthless and constantly having to revisit old code to upgrade play
versions is a pain many commercial developers could do without. Yes we
can leave applications on the old version, but by deprecating methods
and having them point to newer versions is much nicer for developers
than ruthlessly dumping them. We often want to utilise some of the
fixes & new features, but don't because of the pain to upgrade an
application to support a newer version.

We are not all playing at this (excuse the pun), we are trying to run
commercial development businesses, and don't want to be penalised for
being an early adopter by people taking theoretical high ground on
backwards compatibility. Backwards compatibility is price that
successful and stable projects have to live with. I appreciate this is
major version we are talking about here, but the more consideration
for this the better.

So having said that, and with all the talking of making things modular
and plug and play etc. Can things such as the database/storage plugin,
and template languages all be managed as modules. If you could do
this, it would make an upgrade easier, by selecting the JPA/hibernate
module and Groovy template modules as default (per application, not in
Play itself), then the upgrade path will be simpler. Then if you could
specify the database and template settings in an annotation per
controller, it would allow existing code to run, while gradually
converting and creating new functionality on the new modules.

I guess this was rather long and rambling, but essentially, please be
very careful with this. Many of us live in the real world, not fantasy
play land, we need to keep up with latest versions, so make the
upgrade path as simple as possible. I don't always think this happened
with Play. To continue its success, I think it is needed.

Also any ETA on this? It is on my schedule to put the leg work in to
upgrade to Play 1.2.3 over the next couple of months. Is it even worth
doing this? If there is going to be no more substantial development on
the Play 1 branch, I will stick with 1.0.3.2, and only consider the
move to Play 2.

thanks

Daryl.

Guillaume Bort

unread,
Sep 7, 2011, 8:26:56 AM9/7/11
to play-fr...@googlegroups.com
> Nice! Great to see scala 2.9 in the repo :D
>
> I see anorm hasn't bean ported yet... btw, I take it you meant ebean
> for java, anorm still preferred for scala?

It is what will be provided out of the box in the fullstack approach.
But nothing will prevent you to use anything else, either Java or
Scala based.

Guillaume Bort

unread,
Sep 7, 2011, 8:29:15 AM9/7/11
to play-fr...@googlegroups.com
> However, can I make one suggestion? Don't re-invent the wheel with
> type-safe declarations in the Scala templates.

We don't want to reinvent the wheel. The whole approach and syntax is
borrowed from ASP.net Razor template engine. And signature declaration
are just plain Scala declaration.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

Guillaume Bort

unread,
Sep 7, 2011, 8:54:05 AM9/7/11
to play-fr...@googlegroups.com
It is very difficult for a major 2.0 release to promise backward
compatibility without adding a lot of complexity to the project.

What's matter for us is to continue to support and maintain the
previous versions that are already running so many applications. And
we will do it. As you know, when we had the security alert lately, we
fixed all versions, including the 1.0.3.x. And we will continue to do
it, even after the 2.0 release. We have also a lot of applications
running on Play 1.x and we will surely not rewrite them all, or
abandon them.

If you have already several applications running on Play 1.0.3.3 for
your customers, it's fine, there is no need to migrate them. Just
consider 2.0 for you next project, or if it's worse it for a
particular application.

On the other hand, I'm sure than once the 2.0 version will be ready,
the community will help to port the current Groovy template engine or
JPA based Model API as Play 2.0 modules to ease migration of old
projects. It should be fairly easy, just for now we want to focus on
developing the core of the next major version.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

zka

unread,
Sep 7, 2011, 9:31:02 AM9/7/11
to play-framework
Hi,

it sounds great.

I already download the preview, for some reason i prefer java, so
with the new scala template engine, it is possible to place view in
folders ?

views/
my_folder_as_controller_name/
index.scala.html
another_controller_name/
index.scala.html

?

Daryl

unread,
Sep 7, 2011, 9:31:57 AM9/7/11
to play-framework
Thanks Guillaume.

I think the point I was hoping to make, is that the work on making
storage/template functionality pluggable is the key here, then having
modules for Play 1 compatibility is the obvious stepping stone for
upgrades. I would expect the compatibility modules to come later,
ensuring this support and ease of use/configuration is my biggest
concern.

The added bonus of being able to configure this on a controller basis
would also help, allowing the changes to be made over time, while
still supporting the newer options. Is selection of storage/templates
using an annotation per controller an option? If this could be built
in at this early stage, then it gives much more flexibility for
applications to be gradually upgraded? I have seen previous requests/
questions on here, that would have been possible by selecting module/
plugin options per controller, so I think any consideration for this
would be appreciated.

thanks

Daryl.

T.J. Crowder

unread,
Sep 7, 2011, 9:42:02 AM9/7/11
to play-framework
Hi,

Sounds very exciting! Don't let either of the following detract from
the main point that this sounds cool, and it's fantastic to see Play
moving forward, unlike so many projects that get a couple of years in
and just...stop. Clearly not the case here!

I'm sorry to hear you're rewriting a lot of the core in Scala because
it's not a language I know and I have an irrational bias toward
languages that are syntactically derived from B (so C, C++, Java,
JavaScript, C#, etc.). I realize I don't have to know Scala to create
Play apps, but I liked the idea of being able to get my hands dirty on
the internals as necessary (and hopefully contribute back). But I
guess either I'll have to not do that, or I'll have to bite the bullet
and learn a new language. (I've been doing this for well over 20
years, it won't be that much of a problem.)

Since you're going to be doing a lot of work in the source, could I
put in a request for *ALL* public API methods and fields to be fully
Javadoc'd? With more than one-liners (or one-liners linking to the
appropriate further documentation), ideally, but in many cases the
current API docs have no descriptions in the Javadoc at all, or such
minimal ones that they may as well not be there (the annotations in
particular suffer here).

I'm not complaining. Play is clearly a great framework and there is a
fair bit of documentation, but if you're going to be kicking around in
the source *anyway*, improving the Javadoc as you go could be a big
win.

Cheers -- and best of luck with Play 2!
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com

Guillaume Bort

unread,
Sep 7, 2011, 9:50:27 AM9/7/11
to play-fr...@googlegroups.com
> The added bonus of being able to configure this on a controller basis
> would also help, allowing the changes to be made over time, while
> still supporting the newer options. Is selection of storage/templates
> using an annotation per controller an option? If this could be built
> in at this early stage, then it gives much more flexibility for
> applications to be gradually upgraded? I have seen previous requests/
> questions on here, that would have been possible by selecting module/
> plugin options per controller, so I think any consideration for this
> would be appreciated.

No need annotation for that. It will clearly be different API, so if
you use a statically compiled template it will just be a standard
method call, but if you want to evaluate a Groovy template (if a port
if available in 2.0) you will just have to call render()

Arthur

unread,
Sep 7, 2011, 10:54:06 AM9/7/11
to play-framework
It is great that Play is moving on and not becoming stale.

I've just been looking through the kiki sample code; not downloaded it
yet as I'm currently at work. In the views, the controllers package
is being imported using the line
@import controllers._

Couldn't the controllers always be imported by default; so that this
piece of boilerplate isn't needed at the beginning of every view.

See https://github.com/playframework/Play20/blob/master/samples/kiki/app/views/hello.scala.html
for example.
> popular, providing different properties for different ...
>
> read more »

Guillaume Bort

unread,
Sep 7, 2011, 11:03:25 AM9/7/11
to play-fr...@googlegroups.com
> Couldn't the controllers always be imported by default; so that this
> piece of boilerplate isn't needed at the beginning of every view.

Probably, nothing is final yet. But in 2.0 we will not block users to
use another namespace for controllers anyway.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

jgeiger

unread,
Sep 7, 2011, 11:04:17 AM9/7/11
to play-fr...@googlegroups.com
How usable is Play 2.0 right now? If I'm starting a new app today is it in a usable state that would let me do actual development? Are the pieces listed in the roadmap in place or just suggestions for now?

Thanks.

Pascal Voitot Dev

unread,
Sep 7, 2011, 11:06:01 AM9/7/11
to play-fr...@googlegroups.com
On Wed, Sep 7, 2011 at 5:03 PM, Guillaume Bort <guillau...@gmail.com> wrote:
> Couldn't the controllers always be imported by default; so that this
> piece of boilerplate isn't needed at the beginning of every view.

Probably, nothing is final yet. But in 2.0 we will not block users to
use another namespace for controllers anyway.


the most boring IMO are the implicits also... quite verbose
 

Guillaume Bort

unread,
Sep 7, 2011, 11:51:42 AM9/7/11
to play-fr...@googlegroups.com
No you can't use for now, this is just a preview.

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.

> To view this discussion on the web visit

> https://groups.google.com/d/msg/play-framework/-/H7nsQLwGxQkJ.

will

unread,
Sep 7, 2011, 12:31:44 PM9/7/11
to play-framework

This is a fantastic release, especially with the native support for
Akka and async request.

Slightly off topic, does anyone know the comparison between Akka and
Node.js in term of memory consumption per connection, max connections
supported, and message latency? I'm investigating using Node.js for a
project with large number of connections but small message data set
(e.g. 100K idle connections per node but hundreds of bytes messages
occasionally to 1K connections). Thanks.

Sylvain Wallez

unread,
Sep 7, 2011, 1:24:21 PM9/7/11
to play-fr...@googlegroups.com
Le 07/09/11 11:39, Guillaume Bort a �crit�:
That's why we think it's now time to move on, and to consider the next
major version of Play. Welcome Play 2.0!

The plan looks really good!

The 2.0 website says " To get involved, please follow the development mailing list". Where is this list? I'm really interested in lurking there and possibly contribute once I feel comfortable enough with the new code base (and can stand the development pace).

Thanks,
Sylvain
-- 
Sylvain Wallez - http://bluxte.net

Rakesh Waghela

unread,
Sep 7, 2011, 1:28:25 PM9/7/11
to play-fr...@googlegroups.com

The author of the Lift Web Framework justifies the coexistence of Java and Scala both.
But it should not be enforced. Play ! is a revolution of Java world. Hopefully Java elements of Play ! prevails.

Especially in Template creation. why couldn't we have a template system with Java ? If it already exists as a module(Japid) in 1.x why not promote and make it better  in 2.x ?

Quote from that blog post

"What has changed is that I've realized that there's a vast quantity of development shops where the developers show up, have a few meetings, write a few lines of code and go home.  I've had experience with three instances of that kind of company over the last year.  One adopted Scala, is struggling, but trying to do the right thing despite problems with Java written in Scala, recruiting developers, and internal resistance.  One made the decision not to adopt Scala (although there's a little Scala that the VP Eng doesn't know about in production, but it's maintained by one person for whom Scala is vastly better at the task than Java.)  One made the decision to roll back from Scala back to Java because the institutional cost of replacing half their development staff, sending 25% of the remaining staff to expensive courses, and foregoing outsourcing parts of the project outweighed the value that Scala was bringing to the top 3 developers (although it was a very tough and close call.)"

My request to Experienced Play Developers / Authors
Don't miss the big business world heavily invested in Java **Language** .
Play ! has just taken the baby steps in the real business shops.. let it grow !

durre

unread,
Sep 7, 2011, 3:08:43 PM9/7/11
to play-framework
I'm still "high" on Play 1.2 and I'm loving every second of my
javaprogramming with play. I'm a bit afraid to look at the Scala
module and loose the momentum I'm in right now. This will change once
2.0 makes the first real release, then I'll make the plunge for new
webapps.

I'm just thrilled to see such a focused and productive core developers
that keep the framework I love on the cutting edge. Hope to join you
there soon :)

Thanks!
> That's why we think it's now time to move on, and to consider the next
> major version of Play. Welcome Play 2.0!
>

Manh Do

unread,
Sep 7, 2011, 3:24:13 PM9/7/11
to play-framework
I've been using Play! and I'm loving it so far.

It looks like you are planning to integrate Akka Actors. This is
definitely good news and it's definitely a step forward in providing
better concurrency.

Have you try looking into the Disruptor framework? I've ran several
tests and its performance is quite good. Configuring an asynchronous
ordered event processing is quite easy as well. I am planning to use
the Disruptor in my application in conjunction with Play.

Here's a link if you're interested: http://code.google.com/p/disruptor/

I am thinking that utilizing the Disruptor for request dispatching
would be quite beneficial.

In either case, I can't wait to for the release of Play 2.0. When do
you expect Play 2.0 to be release? I am in the midst of creating a
high performance / scalability application and am anxious to
intergrate with the next version of Play 2.0 for its Akka support.
> > WebScokets using continuations. Play 2.0 will be...
>
> read more »

si

unread,
Sep 7, 2011, 4:15:42 PM9/7/11
to play-fr...@googlegroups.com
perfect path, intelligent decision. It seems play will be more than next gen spring. There isn't a web framework that can compete with play 1.2 in any platform already; and play 2.0 is a dream come true in the programming world IMO, thanks guys.

Serdar Irmak

Guillaume Bort

unread,
Sep 7, 2011, 4:19:24 PM9/7/11
to play-fr...@googlegroups.com
> I am thinking that utilizing the Disruptor for request dispatching
> would be quite beneficial.

We are using Akka internally for requests dispatching, and performance
are awesome. You can test the sample application.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.

Keith Swallow

unread,
Sep 7, 2011, 4:33:22 PM9/7/11
to play-fr...@googlegroups.com
Congrats on the 2.0. I've heard a couple calls for improved modularity on this thread. I think that the main strong suit of Play (like the Rails 1.x line) was integration of best-of-breed technologies.

The newer Rails stacks are less useful when it comes to getting a new app up and running. I would like to caution all the Play maintainers against too much modularity. If the seams show a lot then the barrier to entry rises and a main benefit (and appeal) of the framework is lost.

Best,

Keith

Sadache Aldrobi

unread,
Sep 7, 2011, 4:41:49 PM9/7/11
to play-fr...@googlegroups.com
I would suggest to anyone having any doubts regarding Play 2.0 to download the preview, try it, create applications, test them, go to the repository, browse source code, read it and judge by yourself. The whole idea is keep close to the community though the implementation of the 2.0.


--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.




--
www.sadekdrobi.com
ʎdoɹʇuǝ

Manh Do

unread,
Sep 7, 2011, 4:48:18 PM9/7/11
to play-framework
Awesome. I will test it once I get home. :)
> >> > applications - even for developers using Java as the main programming...
>
> read more »

descsuit

unread,
Sep 7, 2011, 5:47:17 PM9/7/11
to play-framework
There has been some mention of reinventing the wheel and when I
started using the Scala plugin one thing lit up a warning sign for me
and that was Anorm.

I'm using Squeryl on my current project and I like it a lot. I looked
at Scala-Query and my Scala chops were just not up to it (barely are
with Squeryl). There are about 3 other database integration packages
for Scala now. So I was wondering, why Anorm? Is it really just an
in-house project?

I could see the same argument being made for the templating engine,
but that is much more tightly integrated with the rest of the project.

Anyway, in general sounds good..

Oh one other question.. you mention having good Java idiomatic APIs,
will there be Scala idiomatic API's as well? Seems like a lot of work
to maintain them both and keep them in sync. Currently the Scala
plugin is lagging and it has a very partial API retool.

Alan

Sadache Aldrobi

unread,
Sep 7, 2011, 6:17:49 PM9/7/11
to play-fr...@googlegroups.com
On Wed, Sep 7, 2011 at 11:47 PM, descsuit <alan.mo...@gmail.com> wrote:
There has been some mention of reinventing the wheel and when I
started using the Scala plugin one thing lit up a warning sign for me
and that was Anorm.

I'm using Squeryl on my current project and I like it a lot.  I looked
at Scala-Query and my Scala chops were just not up to it (barely are
with Squeryl).  There are about 3 other database integration packages
for Scala now.  So I was wondering, why Anorm?  Is it really just an
in-house project?

There is nothing in the market that has the same model as Anorm. Anorm is an API, more like a JDBC with less pain. If you opt for ORMs then choose one and use it, and as you suggest we are not going to re-implement an extra ORM.
 

I could see the same argument being made for the templating engine,
but that is much more tightly integrated with the rest of the project.


Same thing, unfortunately we haven't found anything in the market with roughly the properties we were looking for.

I am not looking for conclusions here, but it is interesting to observe that every component of the framework that people appreciate today had the same "don't reinvent the wheel" critics in the beginning.
 
Anyway, in general sounds good..

Oh one other question.. you mention having good Java idiomatic APIs,
will there be Scala idiomatic API's as well?  Seems like a lot of work
to maintain them both and keep them in sync.  Currently the Scala
plugin is lagging and it has a very partial API retool.

From the sample application in the preview:

    def list(page:Int, sort:String) = {
        
        val p = if(page > 0) page else 1
        
        Secured(p != 42) { 
            Cached(p, sort) { 
                Action {
                    println("Listing page " + p + " using " + sort)
                    Html(views.html.list(p, sort).toString)
                } 
            }
        }  
} 



public class JavaApplication extends Controller {

    @Cached
    public static Result index() {
        System.out.println("REQUEST -> " + request());
        String url = routes.JavaApplication().hello(5, "World").url();
        return Html(javaIndex.apply(url));
    }
I hope this shows an example of how can we address Idiomatic Scala and Java in the same project. It is not easy but we take it seriously.


Sadek

 
Alan


--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.




--
www.sadekdrobi.com
ʎdoɹʇuǝ

Alison Winters

unread,
Sep 7, 2011, 8:57:32 PM9/7/11
to play-framework
Very interesting stuff Guillaume, it sounds like the team has been
thinking long and hard about the right way forward for Play.

Like some other group members, I also feel some trepidation about
moving so much toward Scala. Although I know it is gaining acceptance
in the real world, Java, Python and even Groovy feel like more
widespread technologies. Also they are all easy to understand, being
standard object-oriented/procedural languages. Scala is a big paradigm
shift for most developers, and I think that will definitely discourage
community contributions. I know you guys will write a good Java API to
access the front end, but I hope module developers and other
"hardcore" contributors will still be able to add features and
functionality without having to delve too deeply into Scala.

I do like the direction overall, though. Although I've never used SBT,
it does seem much tidier to use it for build and deployment (vs custom
Python scripts). I think this is going to be the most important
rationale for upgrading current apps in production. Everyone wants
nicer deployment :) I also like the conciseness of the ASP.NET/Razor-
style template syntax, even if it does mean having to use weird Scala
for loops and closures to do things. I am very familiar with the
quirks of Hibernate, but I think using EBean by default will be a
great advantage for developers new to Java, and it will probably
perform well enough for most projects anyway. It all looks very
exciting.

As a user with Play running in production, I am very interested in how
you will be continuing to support the 1.x branch. I don't expect any
new features now that you are focused on 2.0, and I know you will
probably only be working on bugs that actually break things (rather
than those that are simply annoying), but can we see some kind of
roadmap for those? It would be good to know what is planned to be
addressed for "1.4" and what is just going to be abandoned in the 1.x
tree and targeted for 2.0.

Also the announcement page on the web site looks really cool, nice
coding :)

Alison

Ivan Meredith

unread,
Sep 7, 2011, 9:11:38 PM9/7/11
to play-fr...@googlegroups.com
One request I have is that as you port parts over to play2, please
make them independant libs were possible. A good example is the WS
library, its brillant, I wish I could use it in legacy java apps when
I have to talk to new rest end points. Another is anorm, if I had
anorm as a jar today, it would simplify a migration of a app I
maintain to play. :)

> --
> Guillaume Bort, http://guillaume.bort.fr
>

Xuefeng Wu

unread,
Sep 7, 2011, 10:17:11 PM9/7/11
to play-fr...@googlegroups.com
Thank you play! team and I hope the dream come true more soon.

Is there possible that the typesafe team will contribute or support play!2 and let things happen early?

Christian Koch

unread,
Sep 8, 2011, 2:04:04 AM9/8/11
to play-fr...@googlegroups.com
Good Job! We like the (for Java frameworks) uncommon concepts and we hope that they will remain in Play 2.0.

v6ak

unread,
Sep 8, 2011, 2:22:13 AM9/8/11
to play-framework
It definitely can be ported o Windows without Cygwin. (if exists file,
%someUglyChars0, ...)

On Sep 7, 2:05 pm, Ivan Meredith <i...@ivan.net.nz> wrote:
> I imagine you just need to make a windows version ofhttps://github.com/playframework/Play20/blob/master/play
>
> On 8 September 2011 00:02, Rakesh Waghela <javain...@gmail.com> wrote:
>
>
>
> > Windows is not supported yet ?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "play-framework" group.
> > To view this discussion on the web visit
> >https://groups.google.com/d/msg/play-framework/-/4WHeNxHSXCAJ.

Aishwarya Singhal

unread,
Sep 8, 2011, 2:59:31 AM9/8/11
to play-framework
+1 for native Scala and Akka support! I like the sound of it. Thanks
and keep up the good work!

Is there any place I could post some of my wish list (apart from
what's already included in 2.0) ?

PS: Developing with the play-scala support seems to be slower than the
Java one because, if I remember correctly, sbt holds on to a bit of
memory as the code is compiled on the fly. With sbt coming in
mainstream play, is something being done to ease that too (say run sbt
in a separate process and may be have inter process communication) ?

Best regards
Aishwarya

v6ak

unread,
Sep 8, 2011, 3:03:14 AM9/8/11
to play-framework
It should be simple to do so, since Play will move to SBT :-)

I've one question. I've currently a Play!-Scala project with some
Maven-Scala modules. Now, I've to call mvn install on the parent Maven
project, clean a part of Ivy cache (provided that the version has not
been changed), call play modules --sync in the Play! project directory
and restart the Play! app.

If I switch to SBT, how much would it simplify these steps?
* The Play app would probably be able to be moved to a SBT module.
* Since SBT is based on Ivy, there would be no need for cleaning Ivy
cache. (OK, I can do this also in 1.2.* branch.)
* Would I have to restart the Play! app?
* I probably would not need to sync dependencies.
* When downloaded the app from source, would there be a simple command
that would compile everything, test everythingg and run the Play app?

Regards,
Vít Šesták 'v6ak'

On Sep 8, 3:11 am, Ivan Meredith <i...@ivan.net.nz> wrote:
> One request I have is that as you port parts over to play2, please
> make them independant libs were possible. A good example is the WS
> library, its brillant, I wish I could use it in legacy java apps when
> I have to talk to new rest end points. Another is anorm, if I had
> anorm as a jar today, it would simplify a migration of a app I
> maintain to play. :)
>
> ...
>
> read more »

Guillaume Bort

unread,
Sep 8, 2011, 3:16:44 AM9/8/11
to play-fr...@googlegroups.com
> As a user with Play running in production, I am very interested in how
> you will be continuing to support the 1.x branch. I don't expect any
> new features now that you are focused on 2.0, and I know you will
> probably only be working on bugs that actually break things (rather
> than those that are simply annoying), but can we see some kind of
> roadmap for those? It would be good to know what is planned to be
> addressed for "1.4" and what is just going to be abandoned in the 1.x
> tree and targeted for 2.0.

Nothing is decided yet, but we will surely not backport important
changes like the new build system, scala support or the type safe
routing and template engine to the 1.x serie.

However it is likely than we will try to port the existing Groovy
template or the Hibernate based Model engine to the 2.x serie (after
the 2.0 release) to ease the migration. But not as standard default
components.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.

> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

grandfatha

unread,
Sep 8, 2011, 4:25:27 AM9/8/11
to play-framework
I always had the fear that Play would get fragmented, because of the
Scala module and the consequence of having to build to separate APIs,
which essentially means having to maintain two different web
frameworks.

I think it is a good idea to unify both in a 2.0 release, because it
is unhealthy to create two different frameworks under the same name.


I hope that while building 2.0, Play#s core developers will remember
that ...


(1) simplicity
(2) developer usability
(3) general feeling of enjoying the use of the tool / APIs


is what brought Play to where it is right now. We dont need another
Lift just for the sake of jumping on the Scala bandwagon. Play has
become big, because it is essentially Django/Rails for the Java world.
If Play 2.0 does not support (1), (2) and (3) in the same way Play 1.0
supported it, I think it would mean its downfall and its usage only
among Scala enthusiasts, which would be a pity since it is making its
move right now into more conservative development shops and becoming
mainstream since it is just plain Java.


tl;dr : Dont fuck up the developer usability of Play by switchting so
much to Scala, please!



Rakesh Waghela

unread,
Sep 8, 2011, 4:30:34 AM9/8/11
to play-fr...@googlegroups.com
Dont fuck up the developer usability of Play by switchting so 
much to Scala, please!  


+1 for templates !

Daryl

unread,
Sep 8, 2011, 4:46:20 AM9/8/11
to play-framework
> The newer Rails stacks are less useful when it comes to getting a new app up and running.
> I would like to caution all the Play maintainers against too much modularity. If the seams
> show a lot then the barrier to entry rises and a main benefit (and appeal) of the framework is lost.

I think this is where the initial design and planning is vital. It
needs to have the modularity to swap modules/plugins in and out. This
has become an increasingly common request on Play 1.0, and it has to
be considered important for this functionality to be included in such
a major rewrite. The trick will be to select the best defaults and
make the ability to create a new app and run straight away without any
configuration as in the current version. Swapping out modules to meet
particular needs will be a conscious decision on the part of a more
experienced developer.

Selecting the best defaults will also be an interesting decision. The
current JPA/groovy templates have a fairly easy learning curve,
allowing beginners to just dive in. If the something more complicated
is bundled as default, it could put beginners off. Maybe there should
be different bundled versions that allow you to get up and running
quickly with different options. Its a fine line between introducing
beginners/ease of use and allowing more experienced users to configure
things as needed.

Interesting times ahead :)

Xuefeng Wu

unread,
Sep 8, 2011, 4:49:56 AM9/8/11
to play-fr...@googlegroups.com
If play!2 is easy and productivity enough, It may could interest developer who  don't know scala or even java.
As the rails which bring new developer into Ruby world.

stefaan luckermans

unread,
Sep 8, 2011, 5:03:04 AM9/8/11
to play-fr...@googlegroups.com
We are one of the companies that try to use Play to build an enterprise app. We have a multi-year planning and our fear now is that in time Play 1.1.1 will no longer be supported and will force us to re-develop all we are currently developing.

For us Play 1.2 was even a big step, because we ruled out the use of maven as to bothersome and about scala? We never heard of it and don't really plan to use it.

Or client are big banks and insurance companies and therefore we stick to old familiar java …

The only 2 things that we are interested in are asynchronous HTTP, because we plan to build a lot of dashboards as well as easy portability to the systems of our clients.

I hope that the Play people could set up a sort of help desk to help companies as ours to decide which Play to use and/or when to make the migration to which version of Play.

The initial ease we found in Play 1.1.1 was fading with Play 1.2 and is now even more fading with Play 2.0.

Interesting detail. My developers are java developers, but not java developers 'pure sang'. They all have a testing background and one of the major reasons to choose for Play was the possibility to approach our app in a test driven way.

I just hope we made the right decision by going with Play ….



Stefaan Luckermans 
Owner of Thaste IT

Gasthuisvest 30
2500 Lier
 
Cell phone: +32 472 103 204
 


On 08 Sep 2011, at 10:49, Xuefeng Wu wrote:

If play!2 is easy and productivity enough, It may could interest developer who  don't know scala or even java.
As the rails which bring new developer into Ruby world.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/GVHW1bbtw1sJ.

Pascal Voitot Dev

unread,
Sep 8, 2011, 5:21:35 AM9/8/11
to play-fr...@googlegroups.com
Guillaume, I'm becoming Scala fan more & more but, according to what some people say, do you think that play2.0 will allow writing modules in Java (and not only in Scala) as simply as now? I mean, a basic developer could write a module without needing to learn Scala...
Following what stefaan said, I think people need to be reassured about the easiness of the Java Api layer to accept play2.0 based on a Scala core... They will come naturally to Scala if they need but basic java developers won't switch to Scala for sure... Some big companies are still stuck on Struts1 and to convince them to try something else, complete technology switch is generally not the best argument...

The short learning curve and the easiness are certainly the best arguments of play in the java world.

Thanks
Pascal
PastedGraphic-1.tiff
PastedGraphic-2.tiff

Ivan Meredith

unread,
Sep 8, 2011, 7:14:26 AM9/8/11
to play-fr...@googlegroups.com
I doubt there is any requirement to write modules in scala. In play 1.x its not like you are limited to java either. I have a module I wrote in clojure for kicks, and the play-scala module is written in scala.
PastedGraphic-2.tiff
PastedGraphic-1.tiff

Guillaume Bort

unread,
Sep 8, 2011, 7:32:54 AM9/8/11
to play-fr...@googlegroups.com
> Guillaume, I'm becoming Scala fan more & more but, according to what some people say, do you think that play2.0 will allow writing modules in 
> Java (and not only in Scala) as simply as now? I mean, a basic developer could write a module without needing to learn Scala...

It can depend of the kind of extensions you want of course, but writing plugins/modules in Java will always be possible.
PastedGraphic-1.tiff
PastedGraphic-2.tiff

homerdoe

unread,
Sep 8, 2011, 11:46:59 AM9/8/11
to play-framework
What attracted me for Play was the folowing things:

1-Speed of reloading(Python scripts)
2-Java
3-JPA

Although i like Scala, i just cannot understand how can someone make
some big business apps without a proper IDE for it.

Seems to me that all the advantages that made me use Play, will be
gone because the scala template and sbt are going to be slower than
the ones java have today. It wont be that easy to use a ORM(JPA)
(millions still do and will for the foreseeable future). And java will
almost be a second citizen.

To conclude, i think all the things that made me go to play will be
gone!

I just dont understand the problem people have with groovy.

Im sorry guys but play may be gone for me, just hope you reconsider
those decisions.
> >>  *Stefaan Luckermans*
> >> *Owner of Thaste IT
>
> >> *Gasthuisvest 30
> >> 2500 Lier
>
> >> *Cell phone: **+32 472 103 204*
> >> *mailto: <stefaan.luckerm...@thaste.org>stefaan.luckerm...@thaste.org*
>  PastedGraphic-1.tiff
> 44KViewDownload
>
>  PastedGraphic-2.tiff
> 125KViewDownload

Ike

unread,
Sep 8, 2011, 11:57:32 AM9/8/11
to play-fr...@googlegroups.com
I think this is a great new direction for Play! All the big architecture and technology choices feel right to me. As with everything else, the devil will be in the details and how the implementation is handled.

First of all, congratulations Guillaume on an excellently written announcement and nice preview site. Very clear representation of the strategy behind it, with just enough technical depth to be serious and interesting.

I've purposely waited 24 hours to comment, just to see what consensus (if any) was building in the community and it seems to me that there are two major areas of concern or "themes" emerging:

  1. Concerns about Scala as a language choice for new development.
  2. Concerns about adding complexity and moving away from "Rails-like" simplicity for new users.
I am less worried about #1 because Play! was never a status quo push. In fact, it is precisely because it challenged standards (like the Servlet spec) that I was initially attracted to it. And I think that being liberated from big, heavy industry practices and specifications has been a great source of inspiration and creativity in the community, and has contributed to the success of the framework.

New technologies will always be a hard sell to conservative organizations like large banks and corporations. But that's OK, because you don't get to create something new and inspiring playing the the rules. Most radical innovations come from disrupting widely accepted widespread practices.

Besides, Scala is not a toy, flight-by-night programming language. It is increasingly making inroads in all kinds of industries, including banking and finance. So I would advice people to seriously consider making it part of their arsenal.

#2 is a different story and one which I think the Play developers should consider very carefully. Developer productivity and ease of use are crucial values that should not be sacrificed. It is natural for project members to grow more sophisticated as their engagements expose them to more large and complex projects (I'm looking at you Spring Framework). But, ultimately, it is the 5 or 10 minute video demo that sells the framework to the masses.

As long as developers are able to easily download the framework, create a new project with a single command and create a database-driven website with just a handful of files and easy-to-understand syntax, all with fast modify-deploy cycles then we should be OK.

If we start seeing things like handle(_, _, _, _, _) as common method signatures then I think we'll be in trouble :)

Sadache Aldrobi

unread,
Sep 8, 2011, 12:08:13 PM9/8/11
to play-fr...@googlegroups.com
On Thu, Sep 8, 2011 at 5:57 PM, Ike <ike...@gmail.com> wrote:

#2 is a different story and one which I think the Play developers should consider very carefully. Developer productivity and ease of use are crucial values that should not be sacrificed. It is natural for project members to grow more sophisticated as their engagements expose them to more large and complex projects (I'm looking at you Spring Framework). But, ultimately, it is the 5 or 10 minute video demo that sells the framework to the masses.

As long as developers are able to easily download the framework, create a new project with a single command and create a database-driven website with just a handful of files and easy-to-understand syntax, all with fast modify-deploy cycles then we should be OK.

If we start seeing things like handle(_, _, _, _, _) as common method signatures then I think we'll be in trouble :)

That's one of the reasons for which we wanted to announce with a preview: To reassure users regarding our intentions. Download the preview and simply use the plain old "play new"
 

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/mWn_1896EwsJ.

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.



--
www.sadekdrobi.com
ʎdoɹʇuǝ

Erwan Loisant

unread,
Sep 8, 2011, 12:33:32 PM9/8/11
to play-fr...@googlegroups.com
Hi,

On Thu, Sep 8, 2011 at 17:46, homerdoe <ozie...@gmail.com> wrote:
> What attracted me for Play was the folowing things:
>
> 1-Speed of reloading(Python scripts)
> 2-Java
> 3-JPA

1. The speed of reloading is not linked to the use of python. We used
Python because we didn't want to launch a JVM for each command; this
issue is fixed with the use of the sbt console: you can open a
console, run several commands and it will be in the same. Reloading of
Java code will NOT be slower. Compiling Scala code is slower than Java
code, but if you choose to code in Java it won't be a problem

2. Java will not be a second citizen. We understand nobody likes
Scala, and Java has its own advantages. Both languages will be equally
supported. What language is used to write the core doesn't matter,
it's just an implementation detail.

3. While Hibernate will not be included, we will include Ebean
(http://www.avaje.org/) which has an API very close to JPA: it uses a
lot of annotations from the javax.persistence.* namespace. It's
actually more in the spirit of Play because it natively support the
explicit save. In Play 1.0, we had to patch Hibernate to get this
behavior. Of course, if you really want to use Hibernate, nothing will
prevent you from importing it to your project.

> Although i like Scala, i just cannot understand how can someone make
> some big business apps without a proper IDE for it.

It's a matter of taste, but if you're an IDE guy you should check out
Typesafe's Scala plugin for Eclipse: http://www.scala-ide.org/
They're throwing a lot of ressources to the project, it's already
pretty good and we can expect it to get better in the future.

> Im sorry guys but play may be gone for me, just hope you reconsider
> those decisions.

You're free to use whatever framework you like, but I'm confident Play
2.0 will appeal to the same Java developers who liked Play 1, and not
just people interested in Scala.


--
Erwan Loisant

v6ak

unread,
Sep 8, 2011, 12:55:46 PM9/8/11
to play-framework
On Sep 8, 5:46 pm, homerdoe <ozielj...@gmail.com> wrote:
> Although i like Scala, i just cannot understand how can someone make
> some big business apps without a proper IDE for it.
IntelliJ IDEA is also a good IDE for Scala. Although it is not as good
as Java support, it is good.

BTW: I'll probably do also something in Java (a Java project
contribution, I can't do it in Scala) and I probably will not go back
to Eclipse...

Brian Nesbitt

unread,
Sep 8, 2011, 1:07:57 PM9/8/11
to play-fr...@googlegroups.com
Hey guys.  I have created the necessary .bat scripts for intital Windows support for the 2.0 preview.  I have blogged about it here.


I was thinking the other day play was a java framework that supported scala, but now its becoming a scala framework that supports java :-)

I don't know scala (yet) but I for one support the 2.0 direction.  With most of the core moving forward in scala I assume there will be less actual code which is always a good thing and improved concurrency.

Ike

unread,
Sep 8, 2011, 1:14:07 PM9/8/11
to play-fr...@googlegroups.com
On Thursday, September 8, 2011 12:33:32 PM UTC-4, Erwan wrote:

2. Java will not be a second citizen. We understand nobody likes
Scala, and Java has its own advantages. Both languages will be equally
supported. What language is used to write the core doesn't matter,
it's just an implementation detail.

I wouldn't say that "nobody likes Scala" :) I'm not surprised that not many are willing to learn a new language, but that's hardly and excuse for dismissing it. 

Ike

unread,
Sep 8, 2011, 1:20:58 PM9/8/11
to play-fr...@googlegroups.com
On Thursday, September 8, 2011 12:08:13 PM UTC-4, Sadache wrote:

That's one of the reasons for which we wanted to announce with a preview: To reassure users regarding our intentions. Download the preview and simply use the plain old "play new"
 

I appreciate that. I'm confident you guys will come up with an elegant abstraction and API. So far I haven't been disappointed by any new direction in Play!

Thanks for the excellent work!

Guillaume Bort

unread,
Sep 8, 2011, 1:29:25 PM9/8/11
to play-fr...@googlegroups.com
I think Erwan meant 'not everybody like Scala' :)

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/play-framework/-/kEQVD7D-uzYJ.

homerdoe

unread,
Sep 8, 2011, 2:37:52 PM9/8/11
to play-framework
Ok, i made some strong arguments, but its just because im scared that
play wont be as near as interesting as it is today for the average
java crowd(i dont consider myself one but hope to sell play to people
who are).

Regarding the python scripts, ive used grails and glassfish and think
that the reloading time could improve, so i have a natural fear of jvm
things that need to be fast.

I dont know scala that much, so i will be watching closely the
development of the new version, im sure the development team is aware
of those things and lets see what the future unfolds...

Pascal Voitot Dev

unread,
Sep 8, 2011, 3:09:16 PM9/8/11
to play-fr...@googlegroups.com
yes I read this sentence and it sounded:"yes we choose scala to write the core of our framework and we know nobody on earth likes scala but we don't care" :D

I prefer your version ;)

Steven Elliott Jr

unread,
Sep 8, 2011, 2:53:29 PM9/8/11
to play-fr...@googlegroups.com
I think overall this is good news and while I agree that it is important to support Java it's also just as important to support Scala; Scala is a the next big thing for the JVM and I have invested a lot of time learning it and have seen its value. Granted, in my company we just started using Play! with Java and have already seen the benefits; I'd love to do something with Scala but I can't get the old dinosaurs to pick it up.

Steven Elliott Jr

unread,
Sep 8, 2011, 1:21:41 PM9/8/11
to play-fr...@googlegroups.com

> I wouldn't say that "nobody likes Scala" :) I'm not surprised that not many are willing to learn a new language, but that's hardly and excuse for dismissing it.

I happen to love Scala but where I work it's hard to introduce a new language; I am waiting to make my pitch for a Scala app when 2.0 becomes an official release. In the meantime I have been diligently trying to port some Java apps over to Scala because I find it to be extremely powerful and showing people a working app is the best marketing tool. Despite the Scala resistance in my organization, the good news is that even though most engineers are not ready to switch to Scala, at least they are using the Play! Framework which is a pleasure to work in. So, it is definitely important to keep the Java support baked in for the old school peeps. Great job to all the devs that make Play! a reality!

Erem Boto

unread,
Sep 8, 2011, 2:50:50 PM9/8/11
to play-framework
As a new Play! developer, I commend not only the choices the team has
made but also the way they've chosen to present their choices to the
community. In fact, Play! is the best-run open source project I've
ever had the pleasure of working with.

I have two issues to bring up.

====
(1) How can we access the developer's mailing list, or an IRC channel
if it exists? I would like to contribute to the project by writing
scaladocs, but doing so will require asking the right people the right
questions and I don't want to flood the users' forum.

(2) I love Scala, but Scala library developers tend towards the
readability-destructive habit of creating punctuation-based DSLs for
each of their libraries. Not every library needs a DSL, and not every
DSL needs to use punctuation. If you ever consider putting operators
like '**', '<#', '<<?', '>>?', etc into the code base _please_
reconsider.

I wouldn't feel the need to bring it up, but Scala's semi-mindfuck
parser combinator syntax that unfortunately features prominently in
Anorm suffers from this syndrome and I would hate to see it spread
into other areas of the developer-facing APIs.

There's a pretty good conversation of it on Proggit. Odersky even
weighed in on the topic.

http://www.reddit.com/r/programming/comments/k5d4v/yes_virginia_scala_is_learnable/
====

Thanks for all the hard work, Playboys. You've made an amazing
product.

Erem

Ike

unread,
Sep 8, 2011, 3:41:15 PM9/8/11
to play-fr...@googlegroups.com
On Thursday, September 8, 2011 2:50:50 PM UTC-4, Erem Boto wrote:

Thanks for all the hard work, Playboys. You've made an amazing
product.
 

I like the ring of that: Playboys! 

Ivan Gallo

unread,
Sep 8, 2011, 3:55:26 PM9/8/11
to play-fr...@googlegroups.com
Dear Friends, I am just reading about this wonderful framework, but prienso that evolution must always be more simple, a Java programming language with asimple template engine would be sufficient and not learn a new language that is not native.

2011/9/8 Ike <ike...@gmail.com>
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/ZMaYCShefbsJ.

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.



--
Ivan Gallo P
SCJP
cel 3008165846

Ian Lawrence

unread,
Sep 8, 2011, 4:41:22 PM9/8/11
to play-fr...@googlegroups.com
Hi

> Play has
> become big, because it is essentially Django/Rails for the Java world.

+1

Exactly why we got into Play (along with the simplicity of the python
commands and the fact that we do not need to use an IDE to develop the
java projects we seem to inherit constantly).
My personal opinion is try to make 1.2.2/3 even simpler for non Java
developers to use and more Django/Rails like rather than move to
another programming language and build system. What advantages exactly
does this increased complexity bring to Play?

Regards


--
http://ianlawrence.info

Ivan Meredith

unread,
Sep 8, 2011, 5:14:04 PM9/8/11
to play-fr...@googlegroups.com
How is it increased complexity? Sure the core is in scala (which
doesn't automatically make it complex), but the apis for a framework
are the important thing. Play 1.x core is pretty complex too btw.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.

Ivan Meredith

unread,
Sep 8, 2011, 5:16:00 PM9/8/11
to play-fr...@googlegroups.com
Scala does not make it more complex, and also, there is no requirement
to learn scala. I'm sure Japid will be ported at the very least, so
you wont even have to learn how to do the scala templates (which are
very simple, much easier than learning scala)

Ivan Meredith

unread,
Sep 8, 2011, 5:29:54 PM9/8/11
to play-fr...@googlegroups.com
I would also like to say that this is Play!, the developers went so
far out of the standard to create a platform that is awesome for end
user developers to use. Do you really think they want this to change?
In play 1.1 -> 1.2 its got easier to manage, with evolutions and
dependancies.

Obviously I personally like where this is going, however even if you
have doubts, I suggest looking at the sample app (yes this is a java
controller https://github.com/playframework/Play20/blob/master/samples/kiki/app/controllers/JavaApplication.java
), and then just wait awhile and see where it goes.

Hristo Deshev

unread,
Sep 8, 2011, 5:30:56 PM9/8/11
to play-fr...@googlegroups.com
On Thu, Sep 8, 2011 at 9:50 PM, Erem Boto <ehb...@gmail.com> wrote:
...

(2) I love Scala, but Scala library developers tend towards the
readability-destructive habit of creating punctuation-based DSLs for
each of their libraries. Not every library needs a DSL, and not every
DSL needs to use punctuation. If you ever consider putting operators
like '**', '<#', '<<?', '>>?', etc into the code base _please_
reconsider.

I love Scala and I use it every day. But I hate the ASCII art (With scalaz we even got Unicode art!) DSL's people come up with. Casting another vote for "please don't go there."

Hristo

Turar

unread,
Sep 8, 2011, 7:08:48 PM9/8/11
to play-framework
I'm a new Play developer and was planning on starting a new project
using Play (just finished going through the tutorial and sample app).
Prior to that, I went through a process of choosing between Play,
other Java frameworks, Django, and Rails, and Play came out on top.

So now I'm a bit confused and would like some advice. Do I proceed
with Play 1.2.3 for this brand new project, and then hope to migrate
to 2.0 early next year, or just forget the whole idea, and go with,
say, Rails for this project, and re-evaluate Play once 2.0 release is
out and has traction? From what I understood so far, the current
recommendation is to not even bother with migrating from 1.x to 2.x,
and just keep developing in 1.x, as it still will be supported. Is
that right? While that makes sense, it's not the most exciting thing
if starting a new project today and knowing there's a whole new
direction already in the works.

Thanks!

Dirk

unread,
Sep 8, 2011, 9:07:08 PM9/8/11
to play-fr...@googlegroups.com
Congratulations on Play 2.0 guys! Thanks for giving us the world's best web framework for free :)
I'm excited to see what comes next..

felipeko

unread,
Sep 8, 2011, 11:10:33 PM9/8/11
to play-fr...@googlegroups.com
Maybe you could start using the Scala module, quoting Guillaume:
If you are using the Scala module currently, the migration path to
Play 2.0 will be easy. The most important change that will make
migration to Play 2.0 difficult is the new type safe template engine.
But if you are already using it it will be easy.


So i guess this would be the best option. 

Everson Alves da Silva

unread,
Sep 8, 2011, 11:14:34 PM9/8/11
to play-fr...@googlegroups.com
This type template is using Scalate or is something new?

Rakesh Waghela

unread,
Sep 9, 2011, 2:50:17 AM9/9/11
to play-fr...@googlegroups.com

grandfatha

unread,
Sep 9, 2011, 2:56:31 AM9/9/11
to play-framework
> I love Scala and I use it every day. But I hate the ASCII art (With scalaz
> we even got Unicode art!) DSL's people come up with. Casting another vote
> for "please don't go there."

+1

For me, even some of the Anorm code is not really aesthetically
pleasing:

def prevNext = {
SQL("""...some..sql...."""
).on("date" -> postedAt).as(
opt('pos.is("prev")~>Post.on("")) ~
opt('pos.is("next")~>Post.on("")) ^^ flatten
)
} (taken from scala-module/samples-and-tests/yabe/app/models.scala)


This is not the API of a Rails/Django inspired framework IMO and I
dont want that to happen to the rest of Play, that is all I am saying.

T.J. Crowder

unread,
Sep 9, 2011, 5:17:23 AM9/9/11
to play-framework
On Sep 9, 7:56 am, grandfatha <dkim...@googlemail.com> wrote:
> For me, even some of the Anorm code is not really aesthetically
> pleasing:
>
> def prevNext = {
>         SQL("""...some..sql...."""
>         ).on("date" -> postedAt).as(
>             opt('pos.is("prev")~>Post.on("")) ~
> opt('pos.is("next")~>Post.on("")) ^^ flatten
>         )
>
> } (taken from scala-module/samples-and-tests/yabe/app/models.scala)

That's....*awful*. Full link:
https://github.com/playframework/play-scala/blob/master/samples-and-tests/yabe/app/models.scala#L31-49

I realize I don't yet "speak" Scala, but PLEASE don't make Play's core
like that. Remotely. At. All. 20+ years of professional experience
_scream_ "maintenance nightmare" at me. (And I'm not just -- or even
primarily -- a Java-head, in my time I've done paid professional work
in 80x86 assembly, C, C++, VB/VB.Net/VBScript, Pascal, Java,
JavaScript, C#, and probably a dozen others.)

Again, I don't "speak" Scala yet -- but that's part of the point, and
that syntax is clearly a huge barrier to entry. There are hundreds of
thousands, if not millions, of people au fait with Java who can read
and understand and contribute to Play. There are currently very few au
fait with Scala, and if David Pollak is right[1][2] (even if he comes
off a bit elitist about it, particularly in [2]), there will continue
to be very few for many years to come.

Contrast the above with:

public Post previous() {
return Post.find("postedAt < ? order by postedAt desc",
postedAt).first();
}
public Post next() {
return Post.find("postedAt > ? order by postedAt asc",
postedAt).first();
}

From:
https://github.com/playframework/play/blob/master/samples-and-tests/yabe/app/models/Post.java#L50-56

[1] http://goodstuff.im/yes-virginia-scala-is-hard
[2] http://goodstuff.im/scala-use-is-less-good-than-java-use-for-at-l
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com

Jonas

unread,
Sep 9, 2011, 5:41:49 AM9/9/11
to play-framework
Wow! Play 2 sounds like a dream!

Thanks for this and Congratulations to a great framework.

I have used Play with both Java and mostly Scala for some months now.
I really like the framework.

The things that attracted me was:

+ Netty as server and the performance
+ Type safety of Java and Scala
+ Simplicity of MVC and Ruby on Rails like
+ Good tutorials and documentation
+ Support for WebSockets

After some experience with both Java and Scala:

+ I really liked the type safe and easy to use Scala templates
- I wanted to use WebSockets with the Scala module
- Anorm, I started to use it, it looked good, but it didn't have good
support for PostgreSQL
- Anorm, I need transactions for Order+multiple OrderItems, so I used
JDBC for this.
- This is minor problem, but it takes some time for a bigger Scala app
to compile.
- Not a play issue, but the Scala support in Eclipse wans't good. I
could change to IntelliJ, but it's a big step to switch many projects
to another IDE that I don't know yet.

Play 2:

+ It sounds like a dream with type safe routing
+ It sounds like a dream with Akka, I have used it in a Java project
and I have used Erlang before
+ Sounds like you are designing for WebSocket support for Scala,
great!
+ Better integration with Scala and keeping good support for Java

Thanks a lot for a great framework

Guillaume Bort

unread,
Sep 9, 2011, 5:44:21 AM9/9/11
to play-fr...@googlegroups.com
> Exactly why we got into Play (along with the simplicity of the python
> commands and the fact that we do not need to use an IDE to develop the
> java projects we seem to inherit constantly).

If will not change in Play 2.0. You will use the same
new,run,start,test commands to manage your application. The fact that
we use SBT under the hood instead of python scripts will not change
anything on the final UI.

And like in Play 1.x you will be able to work without IDE. Play will
just recompile and reload any change when you hit reload.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

Guillaume Bort

unread,
Sep 9, 2011, 5:46:20 AM9/9/11
to play-fr...@googlegroups.com
Here is a type safe template as seen by a Java developer:

https://gist.github.com/1203802

Really no one can say that a Java developer will be lost reading or
writing this stuff.

--
Guillaume Bort, http://guillaume.bort.fr

Pascal Voitot Dev

unread,
Sep 9, 2011, 5:56:14 AM9/9/11
to play-fr...@googlegroups.com
I think you can begin with 1.2.3 which is really complete and stable! (basically, 1.2.3 is already a complete and self-sufficient framework)
2.0 will arrive progressively and you will be able to prepare your migration in the same way...
The only doubt I would have is against the Groovy templating which won't be kept in 2.0.
So I would advise going directly to Scala template or Scalate or Japid or Cambridge.

Regards
Pascal

Rakesh Waghela

unread,
Sep 9, 2011, 6:13:10 AM9/9/11
to play-fr...@googlegroups.com
+1 for 

"Japid or Cambridge."

ogregras

unread,
Sep 9, 2011, 7:15:00 AM9/9/11
to play-fr...@googlegroups.com
I just want to add my voice to those who have concerns about not keeping Java as a first class citizen in Play! in future versions. I didn't even look at Lift because it uses Scala only.

T.J. Crowder

unread,
Sep 9, 2011, 7:22:18 AM9/9/11
to play-framework
On Sep 9, 10:46 am, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> Here is a type safe template as seen by a Java developer:
>
> https://gist.github.com/1203802
>
> Really no one can say that a Java developer will be lost reading or
> writing this stuff.

Not at all. I want to be clear that the concerns I expressed earlier
relate to the _framework code_ and whether people can readily
understand and contribute to it (and samples, etc.). I don't see any
issue with the _templates_ you're citing, regardless of one's
linguistic leanings. You have to learn any templating system, that one
looks just as comprehensible as any other. Not so much that code from
the Scala yabe sample quoted by grandfatha (yikes!), and the "ASCII
art DSL" concerns raised by Hristo Deshev. I would hate to see Play's
framework code look like that.

grandfatha

unread,
Sep 9, 2011, 8:04:27 AM9/9/11
to play-framework


Guillaume Bort wrote:
> Here is a type safe template as seen by a Java developer:
>
> https://gist.github.com/1203802
>
> Really no one can say that a Java developer will be lost reading or
> writing this stuff.

Thanks for clarifying this. I never wanted to sound 'unappreciative'
regarding your hard work and effort. It is just that some of the Scala
code out there (even part of anorm) can be a real threat to the
popularity of the framework. And I would hate to see such a
masterpiece go down in flames because of stupid things like e.g. the
overuse of symbolism within the scala world.

Sadache Aldrobi

unread,
Sep 9, 2011, 8:43:13 AM9/9/11
to play-fr...@googlegroups.com
Just to clarify here, Anorm did NOT invent a syntax, a DSL or operators. It implements standard Scala Parsers Combinators and it is targeted for Scala users. http://www.scala-lang.org/api/current/scala/util/parsing/combinator/Parsers$Parser.html


--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.




--
www.sadekdrobi.com
ʎdoɹʇuǝ

Pascal Voitot Dev

unread,
Sep 9, 2011, 8:54:34 AM9/9/11
to play-fr...@googlegroups.com
On Fri, Sep 9, 2011 at 2:04 PM, grandfatha <dki...@googlemail.com> wrote:

Scala has a powerful syntax... but as all the powerful things, if you aren't reasonable and self-disciplined, you can become incomprehensible... But I know coders who write weird Java also :)
 

Ike

unread,
Sep 9, 2011, 12:06:35 PM9/9/11
to play-fr...@googlegroups.com
I think what people are trying to say here is that using a particular Scala library syntax may be a challenge to the simplicity rule. Even if it wasn't invented by the Play developers. It may not be "good enough".

By using parser combinators we're assuming that people know Scala AND parser combinators AND and can tell what "~<", "spanM()" and "^^ flatten *" mean in context. But, if we take a step back, we can see how much harder this is to grok than a simple finder method, like the one shown by another poster.

So maybe there's an opportunity to create a higher level of abstraction for beginner or less scala-savvy coders. Maybe additional documentation and examples could help here. I think the community has always been open to new, bold approaches, as long as they are in the spirit of ease of use and developer productivity. Abstracting MagicParser even higher, by using some convention-over-configuration and maybe some clever JDBC meta-data manipulation may be useful to 80-85 % of the use cases for new users.

Or maybe the solution is to include a scala-friendly ORM as a standard module that can be easily configured for new projects.

Of course, this is only touching upon Anorm, which was mentioned here and addressed by Sadek. Similar concerns probably apply to other parts of the framework as it develops.

The dust is far from being settled on all this and truly appreciate the Play! development team's transparency and willingness to work with the community to move this project forward.

Thanks for the inspiring work and excellent framework.

Erem Boto

unread,
Sep 9, 2011, 12:50:49 PM9/9/11
to play-framework
> Just to clarify here, Anorm did NOT invent a syntax, a DSL or operators. It implements standard Scala Parsers Combinators

Granted, and I understand your rationale: "The Parser Combinator
library is a scala standard lib, therefore all Scala developers will/
should be familiar with its syntax." But I hope the continued
controversy around Anorm's syntax has communicated to you that this
assumption may not be sound or reasonable.

For example (and I think I'm typical here). Only in researching how to
use Anorm did I discover _what_ a Parser Combinator is, which took me
down a deep hole learning about parsers, parser-generators and context-
free grammars. When I was feeling more comfortable, I searched for the
Parser Combinator scaladoc and found a perfect example of an
inscrutable API. For example, look at the three adjacent methods ^?,
^^, and ^^^. Or the methods ~ and ~!, none of which at their face give
any contextual information about the method's purpose. That lack of
contextual information in the method name butchers readability and
makes any code that uses the library heavily look frustrating and
undecipherable. Which is why the Anorm code stands in jarring contrast
to the rest of the Play! APIs and docs which are dead-simple for
anybody familiar with the relevant domains (HTTP, HTML, SQL, etc).

At any rate, I'm not complaining about the learning process; it was
all useful knowledge. But should this level of research really be
necessary just to understand the options for extracting data from a
result set? I think most of us Play! developers would argue otherwise.

To reiterate and bring this back to the topic, I love the move to
Scala but would hate to see more Play! APIs seduced into employing
punctuation operators and thereby murdering readability.

Erem

On Sep 9, 5:43 am, Sadache Aldrobi <sadek.dr...@gmail.com> wrote:
> Just to clarify here, Anorm did NOT invent a syntax, a DSL or operators. It
> implements standard Scala Parsers Combinators and it is targeted for Scala
> users.http://www.scala-lang.org/api/current/scala/util/parsing/combinator/P...

Sadache Aldrobi

unread,
Sep 9, 2011, 2:50:48 PM9/9/11
to play-fr...@googlegroups.com
On Fri, Sep 9, 2011 at 6:50 PM, Erem Boto <ehb...@gmail.com> wrote:
> Just to clarify here, Anorm did NOT invent a syntax, a DSL or operators. It implements standard Scala Parsers Combinators

Granted, and I understand your rationale: "The Parser Combinator
library is a scala standard lib, therefore all Scala developers will/
should be familiar with its syntax." But I hope the continued
controversy around Anorm's syntax has communicated to you that this
assumption may not be sound or reasonable.

Just to be things into context, the example mentioned above is there to show how powerful the Anorm API is (parsing a very custom unusual query), and for simple queries you won't use ANY of the operators, and for more sophisticated you'll need to use some but without understanding what they exactly mean.
Anorm is not an example of Play api since it targets the need of being powerful using SQL database. But we made it clear since the beginning, if you need an ORM then pick up your favorite.
The Play user base varies from simple CRUD applications to complex data integration and manipulation.


To reiterate and bring this back to the topic, I love the move to
Scala but would hate to see more Play! APIs seduced into employing
punctuation operators and thereby murdering readability.


Of course I agree, a user of a profile you describe should not be forced into using "sophisticated" even if powerful APIs. That's why we work with the community  and we are happy to have some constructive feedback like yours.

punctuation operators and thereby murdering readability.


I wouldn't call it "murdering readability" anyway. 
Readability is subjective, would you state that chinese, for instance, kills readability? But yes, it takes a learning phase until you find chinese readable. And it should worth it, which is in case of chinese :)



--
www.sadekdrobi.com
ʎdoɹʇuǝ

Erem Boto

unread,
Sep 9, 2011, 3:16:52 PM9/9/11
to play-framework
> I wouldn't call it "murdering readability" anyway.

Apologies! Looking back on it, that wording was chosen out of
frustration and way too harsh.

I also do not wish to deride what you've done with Anorm, because
after doing the homework I described in my previous post I can
definitely appreciate the library's versatility.

Point is that change is both awesome and scary, and I'd love to see
Play! come out of this great change as the undisputed king of JVM web
frameworks, if it isn't there already =)

Erem

Sadache Aldrobi

unread,
Sep 9, 2011, 3:37:28 PM9/9/11
to play-fr...@googlegroups.com
On 9 sept. 2011, at 21:16, Erem Boto <ehb...@gmail.com> wrote:

>> I wouldn't call it "murdering readability" anyway.
>
> Apologies! Looking back on it, that wording was chosen out of
> frustration and way too harsh.
>
> I also do not wish to deride what you've done with Anorm, because
> after doing the homework I described in my previous post I can
> definitely appreciate the library's versatility.
>

No problem.

> Point is that change is both awesome and scary, and I'd love to see
> Play! come out of this great change as the undisputed king of JVM web
> frameworks, if it isn't there already =)

Perfect )

It is loading more messages.
0 new messages