
Play framework 2.10 released - emdagon
http://www.playframework.com/
======
Garbage
Release announcement -
[https://groups.google.com/forum/?fromgroups=#!topic/play-
fra...](https://groups.google.com/forum/?fromgroups=#!topic/play-
framework/hZMXw1p6sjo)

Major highlights of this release include:

* Migration to Scala 2.10

* Migration to Scala concurrent Futures

* Modularisation of Play itself

* Modularisation of routes files

* Better thread management and HTTP context propagation in Java projects

* Managed controller instantiation

* New Scala JSON API

* New Filter API with built in CSRF protection

* RequireJS support

* Content negotiation

* Improved Iteratee API

~~~
iso-8859-1
and SSL: [https://groups.google.com/d/msg/play-
framework/FeTUDQwaEPg/q...](https://groups.google.com/d/msg/play-
framework/FeTUDQwaEPg/qjBEt6LsLr0J)

But not TLS (and client certificates, yet), that is for Play 2.2:
<https://github.com/playframework/Play20/pull/475>

~~~
wereHamster
Since when is 10 < 2? (2.10 < 2.2)?

Edit: the title is wrong, it's play 2.1.0, not 2.10!!

~~~
ithkuil
yep, it can be easy to confuse that with scala 2.10

------
nnq
Does anyone know a good Django/Play comparison or Rails/Play comparison? Or a
tutorial along the lines of "Play for Rails developers" or "Play for Django
developers"?

I'm learning Scala and I want to play with it for webdev, but I know how much
"hidden effort" is in learning any framework so i's really love something like
this...

~~~
kclay
I'm also an Django developer and did a play application some time back[0], so
maybe I can give some insight on development with Play!.

My background in functional program was non-existent at the time so going in I
was already going to have problems. I choose to create my project as Scala
project since I wanted to learn the tech. While Scala can be done with normal
OOP/procedure programming I wanted to have the full affect of using Scala .

(These are my findings over the 2.0.x branches of Play! but should still be
relevant to the current branch) Management:

Starting of a project is pretty simple, I have to say the Play! has done a
great in baking in a good cli right into their framework and making it easy to
plug in your own custom commands. I should mention that I was developing on a
Windows 7 machine, in normal cases this wouldn't have been a problem but at
the time with the 2.0.x version there were quite a few bugs with the project
builder. For one, I couldn't use google closure compiler support due to some
path finding issues "\" vs "/" and the stage, staged/start command didn't take
windows into mind when generating the script. But for the most part these were
small problems. It also has a less compiler ,which had a few problems causing
me to patch my local ivy install, but should be all addressed now.

* Routing :

The routing files is located in conf/routes, which has a pretty simple DSL for
defining your routes in a simple format :

<http_method> <path or regex> <method with option for defaults>

On thing that was lacking was the option to define multiple http methods for a
route, meaning I could have a GET and POST route handled by the same function.
While this may not be the best way to handle, but in some cases say with a
/login route [1] it would be nice to have it all handled in one function or
alteast defined once, but you have to declare both [2]

* Controllers:

Think of Play! controllers as Django class based views(cbv), the only
difference is that Play! uses controllers are static, in all intent and
purposes they still work the same and allow you to structure your code into
sections of your site.

* Data Modeling:

Play! doesn't have an ORM/mapper per-say but they have a small jdbc wrapper
that allows you to map your classes using Scala combinators syntax [3]. In a
simple app this is easy to do, but you are still writing SQL and prone to
errors. In my case I went with Squeryl [4], I tried to use ScalaQuery (which
is now named Slick) but didn't like the api, maybe on my next project I'll
revisit Slick since they have some nice features. By using Squerly I was able
to get back the ORM mapping you would get with Django by first defining my
Schema in code[5] (also provides sql create statements),Then I was able to
easily map to Scala case classes, a win win here.

* Schema Migrations:

The default play doesn't have an eloquent way of managing schema changes, with
Django you have South and it works fine most of the time. With play, you have
a simple <revision>.sql setup stored in conf/evolutions/. Simply you tag your
"up" and "down" schema changes and run a command in the cli to apply them.

* Templating:

The default Play! template system is pretty robust by its self, you can embed
some scala code in it if needed. On thing about the template lang is that you
must declare your templates with scala markup, so if you start a Play! project
with Java you will still have to learn a bit of scala. Following with the how
type safety of play and JVM technologies, the templates allow follow
suite.This is good but sometimes you will run in a few problems when you want
to pass a subset of data to templates, it took a while to realize that to
access session information inside a template(again this maybe wasn't the best
way to handle my problem) you had to declare an "implicit" value to gain an
handle to the Request object. There are some other templates like one forked
from Grovvy that are more advanced then the default system. But you can get
pretty far by using the default templating engine.

* Request Handling:

Now this part I really liked, each request in Play! is handled by an "Action",
and you are able to compose multiple actions together and come up with some
nice implementations for say validating permissions. For instance, I needed to
validate that a user had access to edit content for a giving dynamic domain
and came up with a easy way[6] to just do

    
    
      def updateProfile = Authorize {
        implicit artist => implicit request =>
    
      }
    

and have the associated artist and request all accessible without having to
fetch the artist in my controller for example. You can also defer requests
that may block so you can retain full non-blocking support throughout your
codebase.

* Forms:

Play! has a great form api, its simple and pretty expressive [7] and provides
validation, but I ran into the problem where I wanted to convert my posted
data set into a Scala case class for instance or wanted to convert to a Double
rather then an Integer. So I had to implement a "Binder" ,to implement this
was actually simple then I thought after looking at the source. With a custom
"Binder" I was able to say pass a string to the controller and its associated
values and have it marshal to a Scala case class and then simplely invoke my
method, its better to show by example then explain so check out the following
[8][9]

So take you have a request like GET stats/metric&range=30days, rather then
having to do the request parsing,database fetching in you controller you can
create a binder and have it all done for you, so when it reaches the
controller you are working with an data object rather then primitive values
(Interger,Strings etc):

    
    
      def plays(range: Range) = TransAction {
        Authorize {
          implicit artist => implicit request =>
            Ok(g(Play ~ range))
        }
      }
    
    

As you see you pass a string value for "range" but since you are asking for an
Range object, with the Binders Play! will convert in-between the two. The ~
syntax is just my sugar to quickly apply the range against the chosen metric
(in this case the total Plays for an artist for the last 30days) and have it
outputted back to the client all in json format (the "g" method is just a
helper to convert the Scala case classes to json string output, I got tired of
writing Json.forJson over and over). All the code that handles the actual
querying is done by the "Play" metric providing an interface to apply the
"Range" rules onto a predefined query, all type safety. I have to say I was
pretty amazed and proud of myself for this setup alone, it made it really easy
to build new metrics one I had the framework setup.

* Deploying :

Deploying on Django requires a few extra software to get everything going, you
need a webserver and some workers (uwsgi,gunicorn etc). With Play! you just
run "play start" into the cli and that’s it. There is a command to stage your
changes that will execute its own start script. But unlike other Java web
frameworks there is no need to have container (tomcat for example) in-front of
your application, let along any webserver. This allows for quick development
but in production you may want to add a web server or caching proxy in-front
of it for best practices but its really isn't needed.

I could probably go into more detail (and may if others see any value) but
Play! is a good framework for the Java/Scala community. Its not feature rich
as say Django or Rails but with every problem or "Man I wish this was baked
in" it wasn't that hard to do it my self, and this is from a guy that has
never developed in Scala and Play! was my first introduction the Scala and the
Play! framework as a whole.Ofcouse there were some "What were they thinking"
moments and odd default configurations but you get that with anyframework I
would guess. I did have lots of fun in the process and it made coding fun
again, so I would definitely use Play! again, it seems now its more polished
and some of the problems that I had have been addressed not the mention the
new Json api is just beautiful.

[0]<https://github.com/cideas/bulabowl>
[1][https://github.com/cideas/bulabowl/blob/master/app/controlle...](https://github.com/cideas/bulabowl/blob/master/app/controllers/Application.scala#L204)
[2][https://github.com/cideas/bulabowl/blob/master/conf/routes#L...](https://github.com/cideas/bulabowl/blob/master/conf/routes#L16)
[3][https://github.com/playframework/Play20/blob/master/samples/...](https://github.com/playframework/Play20/blob/master/samples/scala/zentasks/app/models/Project.scala#L42)
[4]<http://squeryl.org>
[5][https://github.com/cideas/bulabowl/blob/master/modules/commo...](https://github.com/cideas/bulabowl/blob/master/modules/common/app/models/SiteDB.scala#L104)
[6][https://github.com/cideas/bulabowl/blob/master/app/actions/A...](https://github.com/cideas/bulabowl/blob/master/app/actions/Actions.scala)
[7][https://github.com/cideas/bulabowl/blob/master/app/models/Fo...](https://github.com/cideas/bulabowl/blob/master/app/models/Forms.scala#L147)
[8][https://github.com/cideas/bulabowl/blob/master/app/binders/p...](https://github.com/cideas/bulabowl/blob/master/app/binders/package.scala)
[9][https://github.com/cideas/bulabowl/blob/master/modules/commo...](https://github.com/cideas/bulabowl/blob/master/modules/common/app/models/Stats.scala)
and
[https://github.com/cideas/bulabowl/blob/master/app/controlle...](https://github.com/cideas/bulabowl/blob/master/app/controllers/Stats.scala)

~~~
pepr
Great writeup, but I have a comment on deploy: do you mean that "play start"
can be used for production? Because otherwise, Django has runserver for
development. It just shouldn't be used for production.

~~~
Bogdanp
`play run` is sort of the equivalent of `runserver`. `play start` is one of
the recommended[0] ways of running Play applications in production.

[0] <http://www.playframework.com/documentation/2.1.0/Production>

~~~
kaeawc
There is also `play dist` and `play stage`. They both wrap up all necessary
assets / dependencies so that you don't even need play installed in order to
start a play server (as the play framework jar gets bundled too). We use this
for deploying rather than `play start`. The difference between dist and stage
is that dist creates a single zip file in the target directory, whereas stage
does not. Both create a file named 'start' in the target directory. The docs
are not completely clear on that point.

[http://www.playframework.com/documentation/2.1.0/ProductionD...](http://www.playframework.com/documentation/2.1.0/ProductionDist)

~~~
bad_user
You do not need "play" installed, as Play is using SBT as the package manager.

So without the framework installed and in your PATH, you can just go to an
app's directory and do "sbt start". It will download all dependencies needed,
compile your app and start the server.

------
bcarlson
Congrats Play team! You really have a winning framework on your hands! Coming
from a Java background, it was easy to learn; I was able to launch a dynamic
MVP in three days on heroku (shameful plug): carsparkapp.com

It keeps getting better with each release, and as more plugins are written.
The docs are really clear, and the community is thriving. Very good stuff!

------
davidw
When they say "predictable and minimal resource consumption (CPU, memory,
threads)", what kind of numbers are we talking about, roughly?

~~~
martinced
They say they're using Akka to provide actors. And Akka seems... _fast_ and
small:

<http://akka.io>

~~~
davidw
How fast and how small? How many K of memory?

------
dkhenry
This is an amazing effort by an amazing team. I have been using Play
exclusively for two years now and each version keeps getting better and better

------
Garbage
I have been using 2.10 RCs for couple of days (all non-blocking stuff), and I
must say it's amazing! I am impressed.

Way to go guys! :)

------
glazskunrukitis
IMO Play framework is the most important thing happening to Java right now.

I hope this brings Java back to everyday web development :)

------
timmillwood
It's all about the JVM these days, guess I should learn it.

------
BonoboBoner
Things are moving fast... I am still on 1.2.X for my applications as I fear
the migration models, controllers and especially of Groovy templates to Scala
templates.

Especially the increased compilation times when I hit reload are a turn of.

~~~
ap22213
Yeah - Play 1.2.5 is still pretty awesome, too. It's still my go to (Java)
platform for mocking up sites quickly, especially for APIs.

Play 2.1 seemed a bit slower to develop on. At least for me, it was definitely
not as quick to get something up and running ASAP. Will need to check out 2.10
soon.

------
satoimo
Love it. Exquisitely type safe. Just one thing: Weren't we supposed to get WAR
deployment support in 2.1?

~~~
eeperson
They haven't done this because the Servlet 3.1 spec has not been released yet.
Play 2 supports some features that cannot be supported with Servlet containers
<3.1 (probably stuff like web sockets). However, there is a 3rd party plugin
that provides this functionality (as long as you avoid the unsupported
features): <https://github.com/dlecan/play2-war-plugin>

------
kushti
I went through all RCs (from 1 to 4) with two applications. Happy to see
release now. Great framework.

------
ineedtosleep
I've been eyeing Play for a bit now, but I've been wondering what kind of
server it would require for a modest app with basic CMS functionality.

So, for example, will it run fine on a 128MB RAM VPS (assuming average IO
speeds), a remote db and nginx?

~~~
ssmoot
As the other comment said, no need for NGinx unless you're dealing with
external assets you don't want to add to your project structure.

That said, I will say I run my Blog on Play 2.1 (RC2 IIRC) and 512MB means I
have to set some tuneables to limit the max memory to 384MB. I haven't figured
out how to get those to work with 'play dist' either, so I got it running by
cloning the source and installing Play locally. Which isn't much fun.

I'm sure with a little more digging I could figure it out. That said, the
default limit of 1.5GB is probably there for a reason. It seems well suited to
EC2's m1.small instance (1.7GB).

Considering the in-memory caching, I'd just pony up the $44/month for such an
instance for anything more than my personal blog.

------
paullth
Play 2.1 = awesome, scala 2.10 = awesome, and loving the new website. This is
a good time to be a web developer...

------
LiveTheDream
Mods, can you fix the title please? It's "2.1.0", not "2.10" (it runs on Scala
2.10, but the version is 2.1.0).

------
speeder
Why all those fancy effects of things flipping in your webpage?

It confused me for a while, until I understood it, then I think it is fancy,
and useless.

But impressive maybe, if it was done using the tech they want you to use.

~~~
tonybaroneee
It's just a flashy thing to do nowadays in web dev, probably using jQuery
Waypoints. I personally think it's quite cool, despite it's apparent
uselessness.

------
MatthewPhillips
Why did they decide to use static methods for the controllers?

~~~
flaie
Stated by Guillaume Bort here[1]

 _Play uses static methods only when it makes sense: \- in the controller
layer, because controllers are not object oriented. Controllers act as mapper
between the HTTP world (that is stateless, and request/response based) and the
Model layer that is fully object oriented._

[1]: [http://stackoverflow.com/questions/5192904/play-framework-
us...](http://stackoverflow.com/questions/5192904/play-framework-uses-a-lot-
of-statics)

~~~
mbell
It only 'makes sense' on a theoretical basis. On a practical basis, unit
testing tons of static methods is a nightmare.

~~~
richdougherty
I find it pretty easy to test static methods. To me, testing a ton of static
methods would seem a bit easier than testing a ton of classes, since static
methods are usually stateless and so require less setup/cleanup work.

Could you explain a bit more about what makes static methods harder?

~~~
mbell
Static methods can be easy to test, if they are zero or near-zero dependency.
e.g. Math.log(x) is easy to test.

However, a static method that accesses other layers is often very hard to test
(at least in isolation). For example if you have a static controller method
that accesses some service layer you would normally want to mock that service
layer for testing so you can test the controller code in isolation.

If the method is non-static and that service layer object is a class member,
it is very easy to replace your production service layer with a mock (using
dependency injection or mockito, etc).

However if your controller is static, it can only access static members of its
class or instantiate the service object with a 'new' operator. Either way
there isn't a 'seam' in the code where something like dependency injection or
mockito can intercept your app's wiring to replace the service object with a
mocked version.

Worth noting I'm coming from the Java side of things here, perhaps Scala is
built in such a way that 'new' and 'static' type things are interceptable in a
way that allows mocking.

------
matteodepalo
This is awesome news. With this release Play has reached a level of maturity
and elegance that will definitely make me consider it for my future projects.

------
fernandezpablo
Speaking strictly about the website redesign, I think that (although nice) it
fails to communicate the framework biggest selling points. Some comments on
that:

* The code-save-refresh workflow: this is mentioned briefly as "hit refresh workflow" which is confusing to say the least.

* Some other weird or 'meh' bullet points like type-safety (you're using either scala or java so you take that for granted) or stateless-web-tier.

* The introduction video is long. It's fine as a tutorial, but being the first thing you can click on I expect you to sell me the framework in 2-3 minutes or so (it can be done, play is fantastic).

Disclaimer: I love play and used it a lot last year. In fact I was part of the
team that put the first play application into production on LinkedIn (featured
in the bottom of the play site).

~~~
martinp
> * Some other weird or 'meh' bullet points like type-safety (you're using
> either scala or java so you take that for granted) or stateless-web-tier.

I think type-safety is mentioned because unlike Play 1.x, almost everything is
type-safe in 2.x, such as templates and route definitions.

------
edofic
new json api is bloody awesome! and when you add reactive mongo in the mix...
oh my god

------
the1
2.0.4 had bad defaults and documentation.

Some highlights:

\- half baked config (no array. multiple values can be hacked as `foo.bar={a:
1, b: 1}`)

\- can only set logging level in the config. and, xml logger config doesn't
have application.conf values (logger.* in .conf are useless)

\- routes dsl (meh)

\- bad db connection pool. it kills all other connections if a connection
fails, and goes into error state instead of re-connecting (it does reconnect
for subsequent requests when pool is in error state)

~~~
hp
the config has arrays, it is a json superset. foo.bar = [1, 1]

~~~
the1
oh, i think i missed productIterator() in
[http://www.playframework.com/documentation/api/2.0.4/scala/i...](http://www.playframework.com/documentation/api/2.0.4/scala/index.html#play.api.Configuration)

It could have been better if document had some examples:
[http://www.playframework.com/documentation/2.0.4/Configurati...](http://www.playframework.com/documentation/2.0.4/Configuration)

I can't even grep for productIterator on these projects:
<https://github.com/typesafehub/config/>
<https://github.com/playframework/Play20/>

That probably means there's no test, example, poor documentation..

Actually, it's Product.productIterator, which is in scala api. I'm scala noob.

thanks.

------
seivan
I've been looking for a way out of Rails. I dislike not having a compiler &
analyser as I'm very comfortable with CLANG and LLVM.

Recently I've been looking at GoLang and Scala. Not sure which to go with, but
Play seems better than most web frameworks for Go.

But my concern is always ecosystem. Now before you say "You have access to
Java ecosystem" please take a look on how amazing the ruby eco system is.

------
bonsai
I am planning to evaluate play! on some small projects.

Does anyone knows what are pros/cons using play with java/scala?

------
franze
a question (not about the framework, but about the linked webpage) - this
awesome effect where i scroll down and the pictures (next to the "Developer
friendly" headline) "fold up", is there an animation-lib that does this? how
is it called? it's awesome, i want it.

~~~
shinolajla1234
Ask @iamwarry on Twitter - Maxime Dantec did the site design. Talented fellow.

------
borplk
Looks very interesting. Good job.

------
skipwalker
Anyone use the play framework inside of IntelliJ IDEA? What's that experience
like?

~~~
wiradikusuma
IntelliJ is the next best thing after sliced bread. You should definitely try
it. It has great official support for Play.

------
iso8859-1
Issues closed with version 2.1:
[https://play.lighthouseapp.com/projects/82401-play-20/milest...](https://play.lighthouseapp.com/projects/82401-play-20/milestones/137248-21)

------
kushti
BTW, error in title, Not '2.10' but '2.1.0'

~~~
gren
yup! Play 2.1.0 with Scala 2.10 :)

------
rfinley
nothing that awesome to make me switch from Grails.

~~~
jplmelanson
Is it easy to do non-blocking code in Grails? I have played with Groovy lately
and it is definitely a productive language.

~~~
koevet
Is not as easy as using the Scala Future API or Akka Actors.

In Groovy you have to use Gpars (<http://gpars.codehaus.org/>), a third party
library which is not as simple as Scala Futures, IMHO

