Live data from Hacker News

Play Framework 2.0 Final released

playframework.org

21–30 of 61 posts

Re: Play Framework 2.0 Final released

#21
post #7
post #4

When I did a bit of Play 1.2 dev, I ran into two serious annoyances. First, static actions make for untestable code. The only way to test this in 1.2 was to do full integration tests. You can't unit test controllers/actions, which to me is a horrible "opinion" to have. Looking at the docs, 2.0 [appears] to make an attempt via the callAction helper [1], but you still can't inject dependencies via a constructor and cal…

I can't agree more - I've been doing a non-trivial bit of scala work in the past six months, and the part that seems the most lacking to me is JSON support. Every scala JSON library I've used (spray-json, sbjson, lift-json and the like) requires you to define a concrete serializer class for every single type you would like to move across the wire. I really miss the ease of use of reflection-based parsers like Jackson…

Probably Xitrum? https://github.com/ngocdaothanh/xitrum

Re: Play Framework 2.0 Final released

#22
I find that testing has improved quite a bit since actions now return a Result object that you can inspect in your tests. It is true that you cannot inject a mock data repository, for example, but Controllers are meant to be simple HTTP response generators and you might want to make them call some domain object to perform anything complicated. You can then unit test you domain object to your heart’s content.

Re: Play Framework 2.0 Final released

#23
post #16
post #15

Earlier quoted context omitted.

Can you elaborate more on the untestable code point, for those of us who've been spending more time on ruby lately? I find play very interesting, but it's great to hear about its warts as well.

This is the first controller I opened from their samples[1] : public class Forums extends Application { public static void index() { List forums = Forum.findAll(); long topicsCount = Topic.count(); long postsCount = Post.count(); render(forums, topicsCount, postsCount); } ... } You can't mock out Forum, Topic or Post. You can't inject some type of "FormRepository" or whatever pattern you want to gain some type of con…

So would the appropriate approach in this case be to create IForum, ITopic and IPost interfaces and, instead of calling findAll() or count() directly on the class, call it on the interface so a class can be injected? Sorry...this is all a bit hazy to me. It's been years since I've had to deal with these sorts of concerns.

Re: Play Framework 2.0 Final released

#24
For anyone interested in its claim of being reactive, as I was, the Play framework does not appear to support reactive programming [1].

From their samples and documentation, it looks like an event-driven server without any reactive aspects. I'm fairly sure they're mistakenly calling typical event-driven programming "reactive". This is backed up by the statements of Typesafe's CEO on the subject in an interview [2].

[1] http://en.wikipedia.org/wiki/Reactive_programming [2] http://www.infoq.com/news/2011/12/playframework-typesafestac...

Re: Play Framework 2.0 Final released

#25
post #8

give Play 2.0 a try guys, it's a fresh new framework, more robust than ever, and with awesome concept for handling Input/Output.

That way of handling io is indeed snazzy, and a port of ideas from some Haskell libs, but it's worth pointing out that on the Haskell side there's been a bit of innovation in allowing more direct style Apis for iteratee libraries

Re: Play Framework 2.0 Final released

#26
post #13

I am really excited about this but also a bit worried that Java will become a second class citizen for Play development. The typesafe deal, use of SBT and other scala tools, and the overhead of maintaining docs and bindings for 2 languages all seems to point to an inevitable deprecation of Java at some point. Hopefully not?

I think that's the direction that they're already heading. While Java will be supported by nature, I think Scala is a better fit for the growth the framework itself.

Re: Play Framework 2.0 Final released

#27
post #4

When I did a bit of Play 1.2 dev, I ran into two serious annoyances. First, static actions make for untestable code. The only way to test this in 1.2 was to do full integration tests. You can't unit test controllers/actions, which to me is a horrible "opinion" to have. Looking at the docs, 2.0 [appears] to make an attempt via the callAction helper [1], but you still can't inject dependencies via a constructor and cal…

Can't you mock out the calls with something like http://code.google.com/p/powermock/? Or introduce an intermediate object? Or use Spring? Or test using groovy which i think you can redefine methods.

Re: Play Framework 2.0 Final released

#28
post #16
post #15

Earlier quoted context omitted.

Can you elaborate more on the untestable code point, for those of us who've been spending more time on ruby lately? I find play very interesting, but it's great to hear about its warts as well.

This is the first controller I opened from their samples[1] : public class Forums extends Application { public static void index() { List forums = Forum.findAll(); long topicsCount = Topic.count(); long postsCount = Post.count(); render(forums, topicsCount, postsCount); } ... } You can't mock out Forum, Topic or Post. You can't inject some type of "FormRepository" or whatever pattern you want to gain some type of con…

If you wanted to unit test this I'm confident you could do it using JMockit [1] without changing the code. JMockit allows you to mock just about anything (static methods, final methods, constructor invocations). The unit test might look something like:

  @Test
  public void checkIndexRenders()
  {
    final List expectedforums= new ArrayList(asList(TEST_FORUM)); 
    new NonStrictExpections()
    {
      @Mocked Forum forum;
      @Mocked Topic topic;
      @Mocked Post post;
      {
        Forum.findAll(); result = expectedforums;
        Topic.count(); result = 5;
        Post.count(); result = 10;
      }
    };

    Forums.index()
    // your assertions ...
  }
I come from a DI background, but the JMockit framework has changed my view of what untestable code is.

[1] http://code.google.com/p/jmockit/

Re: Play Framework 2.0 Final released

#29
post #27
post #4

When I did a bit of Play 1.2 dev, I ran into two serious annoyances. First, static actions make for untestable code. The only way to test this in 1.2 was to do full integration tests. You can't unit test controllers/actions, which to me is a horrible "opinion" to have. Looking at the docs, 2.0 [appears] to make an attempt via the callAction helper [1], but you still can't inject dependencies via a constructor and cal…

Can't you mock out the calls with something like http://code.google.com/p/powermock/ ? Or introduce an intermediate object? Or use Spring? Or test using groovy which i think you can redefine methods.

"resort to another framework to reach a goal that I expect to be easy"

is a perfectly good reason to state something is a "serious annoyance".

Re: Play Framework 2.0 Final released

#30
post #13

I am really excited about this but also a bit worried that Java will become a second class citizen for Play development. The typesafe deal, use of SBT and other scala tools, and the overhead of maintaining docs and bindings for 2 languages all seems to point to an inevitable deprecation of Java at some point. Hopefully not?

I partially disagree, especially with backing from Typesafe.

The "engine" benefits from Scala, as a highly concurrent and transactional heavy system. The choice of language for building MVC applications & services on that engine is left up to the developer. The 2.0 mindset, and you see this in everything is very much a best tool for the job balanced with flexibility and choice.

It's going to take a little while for a language like Scala (or any JVM based language) to fully penetrate the market. A lot of Java developers are not there yet, and by a lot, I mean most, who are we kidding. I see more shops embracing the JVM as their "stack" and the right language for the job mindset on top of that foundation. It's flexible, conservative, and forward thinking at the same time.

Play fits nicely into that space and is something that the core team appears to be mindful of. In fact, if they're smart about it, Play could end up being a bridge for Java developers interested in making the transition to Scala, at a pace that makes sense for them.

Post reply on HN