Playing with Play Framework for Java

hi stephan,

1) there are a few templating solutions available at the moment:
- the standard groovy one
-scalate (ssp,scaml)
-japid

that means four options to choose from (if I add scala xml literals that means 5)

2) it provides support for siena and GAE. Both CRUD and Fixtures under refactoring in order to suppor new, NOSQL model types

3) the reason why you do not need a build system, because you just do not need to build/compile the project in the traditional java sense. Play compiles the classes for you, on the fly (unless you want to precompile for production in order to avoid the compilation warm-up hit at the first request).

Even though you can package applications as war files, the majority of the sites in production are not using a standard servlet container *at all*. They are just using play as the platform.

4) it’s a new framework, so yeah the community is not as big as for older frameworks but it is growing rapidly. not sure what you mean by limited modules. Considering other framework, play’s module repository is huge.

5) bazaar is only used for the core lib. Anything else is on github. This topic is coming up time to time. So hopefully it will be changed in the future.

HTH

(also, a git mirror can be found here
http://github.com/pk11/play-1.1-mirror )

hi stephan,

1) the templating thing is a matter of taste i guess. That said, somebody mentioned on the list that a “pure” templating solution is in the making.

3) When you launch a play app as a war, you are actually running the apache mina backend with a front servlet in front of it. That said, play is fast: a GAE app is starting up in 3 sec.

as for packaging/building: because play is using its own compiler+classloader, it is not so simple to integrate it into an existing build system. Also, because play is the platform (and most features are available as modules), you get most of the dependencies via modules or play itself (It actually rarely happens that you need to drop in a lib into your app).

The actual war packaging is simple though: play war

4) I guess it depends how you look at it: compared to rails plugins, 21 is a joke, however, compared to most java frameworks 21 is pretty impressive:)

thanks for your review

Hi Stephan,

I wonder why you didn’t mention Grails in this article. In my opinion it’s the most promising and already widely accepted RAD framework there is for Java today. Plus, it’s based on Spring/Hibernate (even acquired by SpringSource recently) which makes it a serious solution for even enterprise requirements.

Cheers,
Daniel

P.S.: Although this is my first comment, I enjoy reading your blog for a while now :-)

Not sure why you’re religious about total separation of logic from presentation.

The whole web programming is about mixing data with presentation. Total separation is artificial. New constructs and extra logic (binding) are required to maintain the separation, just for the purpose of separation, not exactly agile and pragmatic.

Of course the extra binding and runtime resolution won’t help with the performance either.

IMHO.

Japid author

1) I agree, templates should not be allowed to invoke methods. In my mind, templates should only be allowed to access predefined values out of some “Context”/HashMap/whatever. But I guess the current solution is the pragmatic one.

3) I guess that is just because Play uses python to run things. The upside is: a lot faster startup times compared to using a JVM-based build-solution.

Lets face it, the JVM is not made for repeatedly running a simple command very often very quickly . I mean who needs Swing/Corba/etc when simply running a unit-test? I dont wanna wait 30 seconds for e.g. “grails run-app” to finish its work.

4) Not enough, thats true, but if Play core is successful, the plugin-flood will start sooner than later.

Hi Stephen,

I’m not in Ruby. Can you tell me what the RO is?

Now back to your arguments. Japid is a strongly typed template pre-processor that compiles templates to Java code.

1) Test: since the result is a plain Java class for each template, and it returns a string, one can even use jUnit to test it.

2) limit reuse: I don’t consider some simple ifs and loops in the presentation layer as business logic. They’re part of presentation logic. Business logic of course should go to the controller.

3) development speed. Not sure how total separation helps. As long as it’s DRY and straight forward, development is smooth. Usually it’s the extra binding stuff and indirection that costs development time.

4) Framework lock-in. Japid can be used standalone, just like Velocity, Freemarker, both allowing flow control in the templates. Locked in Java? Yes.

Leaking, if it means the templates can do too much, yes. This is an issue in a very strict environment. But usually the templates will go to the hands of the controller coder thus almost in the same security domain.

Hi Stephan,

I put together a new module that lets you manage your dependencies:

http://www.playframework.org/modules/ivy-1.0/home

(ivy uses maven repos underneath, so now you can use any maven repos with play)

sure. let me know if you run into issues.

Plus, bazaar is slow! We’re looking at Play and Lift at work, but will most likely go with Lift for the reasons you outline above.

Tempted to play with Play (ha!) and Compojure/Ring for my personal projects though.

Hi! It’s been a long time

In a couple of months, play! 1.2 should be released… It solves many of the things you didn’t like so much

There are now more than 50 modules, some of them gives you templates alternatives an other allows you to connect to nosql db

Among the new features you’ll find:

- A dependency manager, based on ivy

- Evolutions (something like rails migrations)

- New asynchronous features

It would be marvellous if you could have a look at it and make a review…

Oh, and play is now hosted on github

saludos

sas