7 ms·

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

by latch 15y ago

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 call instance methods. Static members in static languages make testing a real pain. Second, JSON felt like a 2nd-class citizen. Dealing with JSON in either the request or the response felt barbaric. I don't see that they've improved things. Auto binding from a JSON request to an object should exist without having to write a bunch of custom JSON serializers...doubly so for outputting json. [1] http://www.playframework.org/documentation/2.0/JavaFunctionalTest http://www.playframework.org/documentation/2.0/JavaFunctiona...

dpratt99 15y ago
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. I've alleviated a bit of this by writing a generic serializer that uses Jackson under the hood, but that requires every class to use a java bean pattern, and not the more elegant scala case class (or frankly plain old scala object) patterns. There's a project called Jerkson that is attempting to fix this, but I'd like to see all the major scala frameworks just settle on something good and simple and go from there.
- domlebo70 15y ago
  Jerkson works really well. Can convert JSON into case-classes really nicely and handles snake-types.
- djb_hackernews 15y ago
  You might want to check out lift-json again. It can easily serialize and deserialize case classes. https://github.com/lift/lift/tree/master/framework/lift-base/lift-json/ https://github.com/lift/lift/tree/master/framework/lift-base... Also, Play 2.0 includes Jerkson, so whatever Jerkson can do, Play 2.0 can do. They just happened to add some helper utilities that made it very similar to lift-json. So I think the community is settling on something good and simple.
- johnx123-up 15y ago
  Probably Xitrum? https://github.com/ngocdaothanh/xitrum https://github.com/ngocdaothanh/xitrum
- eloisant 15y ago
  I disagree on the fact that JSON is a second-class citizen. A lot of effort went into good support of JSON. But obviously, Scala and Java being statically typed languages, you can't expect to use JSON in those languages like you use them in Javascript. The reason why everyone encourage you to do so is because typeclass serialization is much more robust that introspection. With introspection you may have runtime exceptions, but with typeclass serialization you know at compile time when something is wrong. Also, Jerkson is included in Play 2 (that's what we use as base for the Json lib) so you can use it directly if you want introspection. But if you choose typeclass serialization, you can still define serializers easily, in one line, without losing the type-safety: https://github.com/playframework/Play20/blob/master/framework/src/play/src/test/scala/play/api/JsonSpec.scala#L28 https://github.com/playframework/Play20/blob/master/framewor...
philipDS 15y ago
I agree about the testing. It is also really annoying that you can't run a test as a "single, isolated test". I read a few articles on Play 2.0 and Scala, but haven't come across any additions on testing. Without decent testing integrated, this framework has no real production use. I agree that it all looks nice and shiny though.
- ekoontz 15y ago
  Some interesting criticism of Play here - seems similar to what's been said about the lack of unit tests. http://whilefalse.blogspot.com/2012/03/why-im-moving-away-from-play-framework.html http://whilefalse.blogspot.com/2012/03/why-im-moving-away-fr...
  - pk11 15y ago
    Please note, this blog post is related to Play 1.2.X, not 2.0
- pk11 15y ago
  in play 2.0 (using computer-database java sample app): $ play [computer-database] $ test-only ModelTest or from the command line: $ play "test-only ModelTest"
mercurial 15y ago
I don't understand why you would want static methods everywhere in this age of dependency injection everywhere.
rufugee 15y ago
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.
- latch 15y ago
  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 control. In Ruby, or most dynamic languages, this wouldn't be a problem, since a class method can (and should) be mocked. Even if a static language allows for that sort of trickery (for example, there are a couple ways to test the above in C#), it's the wrong approach. Dependencies should be injected and thus controlled. I guess you could inject using static setters, but that's just a bad workaround to what, in my opinion, is a fundamental misunderstanding of how to write testable code. [1] https://github.com/playframework/play/blob/master/samples-and-tests/forum/app/controllers/Forums.java https://github.com/playframework/play/blob/master/samples-an...
  - TylerE 15y ago
    What, exactly, is the POINT of unit-testing that function, other than patting yourself on the back? You might as well unit test that 1+1 = 2.
    - latch 15y ago
      Unit testing isn't really about ensuring correctness. First and foremost, it's a design tool. Code that can't easily be unit tested is often poorly designed. The most common example in the MVC-world is a fat controller. It's hard to test any method that does too much because of all the setup that you'll have to do. If an action is doing too much, dependent on too many parts, and not very cohesive, you'll feel the pain when you try to test it. Of course, it's just an indicator...a warning symbol. Some times method need to do a lot...sometimes they do a lot while being cohesive and not having a lot of dependencies. Ultimately, your brain is the judge, a unit test is just a tool to help measure a method's entropy. Secondly, it's a refactoring tool. Or, put differently, it's about future correctness. Broadly speaking, in this sense, it's also documentation. At a unit test level, this is tricky...and I've struggled with it quite a bit...if you overly concern yourself with internals (using a strict mock), you'll have a brittle test which is largely focused on the current correctness. However, using loose stubs, it really can prevent the introduction of bugs without being overly brittle.
eweise 15y ago
Can't you mock out the calls with something like http://code.google.com/p/powermock/ 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.
- riffraff 15y ago
  "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".

by latch 15y ago

dpratt99 15y ago

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. I've alleviated a bit of this by writing a generic serializer that uses Jackson under the hood, but that requires every class to use a java bean pattern, and not the more elegant scala case class (or frankly plain old scala object) patterns. There's a project called Jerkson that is attempting to fix this, but I'd like to see all the major scala frameworks just settle on something good and simple and go from there.

domlebo70 15y ago
Jerkson works really well. Can convert JSON into case-classes really nicely and handles snake-types.
djb_hackernews 15y ago
You might want to check out lift-json again. It can easily serialize and deserialize case classes. https://github.com/lift/lift/tree/master/framework/lift-base/lift-json/ https://github.com/lift/lift/tree/master/framework/lift-base... Also, Play 2.0 includes Jerkson, so whatever Jerkson can do, Play 2.0 can do. They just happened to add some helper utilities that made it very similar to lift-json. So I think the community is settling on something good and simple.
johnx123-up 15y ago
Probably Xitrum? https://github.com/ngocdaothanh/xitrum https://github.com/ngocdaothanh/xitrum
eloisant 15y ago
I disagree on the fact that JSON is a second-class citizen. A lot of effort went into good support of JSON. But obviously, Scala and Java being statically typed languages, you can't expect to use JSON in those languages like you use them in Javascript. The reason why everyone encourage you to do so is because typeclass serialization is much more robust that introspection. With introspection you may have runtime exceptions, but with typeclass serialization you know at compile time when something is wrong. Also, Jerkson is included in Play 2 (that's what we use as base for the Json lib) so you can use it directly if you want introspection. But if you choose typeclass serialization, you can still define serializers easily, in one line, without losing the type-safety: https://github.com/playframework/Play20/blob/master/framework/src/play/src/test/scala/play/api/JsonSpec.scala#L28 https://github.com/playframework/Play20/blob/master/framewor...

philipDS 15y ago

I agree about the testing. It is also really annoying that you can't run a test as a "single, isolated test". I read a few articles on Play 2.0 and Scala, but haven't come across any additions on testing. Without decent testing integrated, this framework has no real production use. I agree that it all looks nice and shiny though.

ekoontz 15y ago
Some interesting criticism of Play here - seems similar to what's been said about the lack of unit tests. http://whilefalse.blogspot.com/2012/03/why-im-moving-away-from-play-framework.html http://whilefalse.blogspot.com/2012/03/why-im-moving-away-fr...
- pk11 15y ago
  Please note, this blog post is related to Play 1.2.X, not 2.0
pk11 15y ago
in play 2.0 (using computer-database java sample app): $ play [computer-database] $ test-only ModelTest or from the command line: $ play "test-only ModelTest"

mercurial 15y ago

I don't understand why you would want static methods everywhere in this age of dependency injection everywhere.

rufugee 15y ago

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.

latch 15y ago
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 control. In Ruby, or most dynamic languages, this wouldn't be a problem, since a class method can (and should) be mocked. Even if a static language allows for that sort of trickery (for example, there are a couple ways to test the above in C#), it's the wrong approach. Dependencies should be injected and thus controlled. I guess you could inject using static setters, but that's just a bad workaround to what, in my opinion, is a fundamental misunderstanding of how to write testable code. [1] https://github.com/playframework/play/blob/master/samples-and-tests/forum/app/controllers/Forums.java https://github.com/playframework/play/blob/master/samples-an...
- TylerE 15y ago
  What, exactly, is the POINT of unit-testing that function, other than patting yourself on the back? You might as well unit test that 1+1 = 2.
  - latch 15y ago
    Unit testing isn't really about ensuring correctness. First and foremost, it's a design tool. Code that can't easily be unit tested is often poorly designed. The most common example in the MVC-world is a fat controller. It's hard to test any method that does too much because of all the setup that you'll have to do. If an action is doing too much, dependent on too many parts, and not very cohesive, you'll feel the pain when you try to test it. Of course, it's just an indicator...a warning symbol. Some times method need to do a lot...sometimes they do a lot while being cohesive and not having a lot of dependencies. Ultimately, your brain is the judge, a unit test is just a tool to help measure a method's entropy. Secondly, it's a refactoring tool. Or, put differently, it's about future correctness. Broadly speaking, in this sense, it's also documentation. At a unit test level, this is tricky...and I've struggled with it quite a bit...if you overly concern yourself with internals (using a strict mock), you'll have a brittle test which is largely focused on the current correctness. However, using loose stubs, it really can prevent the introduction of bugs without being overly brittle.

eweise 15y ago

Can't you mock out the calls with something like http://code.google.com/p/powermock/ 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.

riffraff 15y ago
"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".