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

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

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)

Perhaps it would be possible to configre Japid and disable features during runtime?

Things like

Scripts : %{…}%


Will take a deeper look at Japid.

Just about 4) If you put GUI logic and business logic into your web framework layer, your’re locked in. All logic should be in Java classes with no dependencies on a framework. That’s what a clear seperation enables, and weak seperation makes hard.

” But usually the templates will go to the hands of the controller coder thus almost in the same security domain.”

From my experience, if there is no speration, code and logic will leak into templates, they get hard to maintain and you’re locked in. At least this is what I have seen in every application as soon as the framework allows leaks.

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.

For example: http://codemonkeyism.com/graeme-the-grails-bug-buster/

There should be some mention of some of my code (Radeox) in the Grails book even, and I’ve heard Radeox is still part of the Grails dist today (though I’m not sure why or if this is true).

Ruby.RO author ;-)

1) You might be right, though I assume a “pure” approach is safer, indepent of taste, but I might be wrong. Good to here someone works on one

3.) I didn’t wan’t to imply that Play is slow, but it is unknown. And – risk averse as I am ;-) I prefer slower but known solutions, to unknown unknown solutions

“(It actually rarely happens that you need to drop in a lib into your app).”

Again, YMMV, but from my – limited to some years – experience, you need usually lots of libs for a decent web site. Perhaps not twitter, but for a decent eCommerce site.

Packaging war: I’m used to packagings that drop several artifacts (several WARs) to deploy them as best as possible (thread insulation, swim lanes, etc. see Nygard)

4.) Compared to a Java framework which uses Maven, not so impressive ;-) (not to compare integrated modules in Play with libraries in Maven)

No need for thanks, my pleasure. Nice work, keep going.

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.

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

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 :-)

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

1) I know, but all the options seem to adhere to the same model, and none is to seperate markup and code as RIFE, SprintTemplate or Lift does, all are leaking as far as I can see

3) From my – limited – experience from running high traffic sites with several million users, I’d prefer to run apps in Tomcat or Jetty, as they are proven, can easily be monitored and their runtime behavior is well known, of course YMMV

4) We differ here, I wouldn’t call 21 huge ;-)

Thx about Git

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