
Unveiling Play 2.1 JSON API Bonus: JSON Inception with Scala 2.10 macros - mandubian
http://mandubian.com/2012/11/11/JSON-inception/
======
dpratt
I've been using Jerkson (a layer on top of the excellent Jackson JSON
processing library) to do case class marshalling/unmarshalling. It works quite
well - in fact, nearly perfectly, but it still uses runtime type inspection to
get things done. A nice, simplistic typesafe compiled parser would be ideal.

I'd love it if the play folks would break this out of the core library - it
seems like this would be applicable to the whole Scala ecosystem, and not just
Play.

~~~
codewright
Isn't Jerkson abandoned?

~~~
dpratt
There are a few github forks that have added a couple useful things. For my
use case (converting case classes to/from JSON in scala 2.9.2) it works
perfectly.

I've also written a Jackson plugin that knows how to marshal POSO classes -
it's just an introspector that uses the scala convention instead of the
JavaBeans convention. By and large it works well - perhaps I should put it up
on github.

------
alanreid
I love the idea! This makes a lot more sense than writing Formatters and
repeating code everywhere. I'll play with this later today. Thanks!

~~~
mandubian
You're welcome! The idea is to simplify writing basic Reads/Writes for simple
Scala structures. In this way, you can focus on writing more complex JSON
validation/transformation when you need it... For JSON coast-to-coast design
that I introduced in previous article, this is quite useful!

------
mandubian
If you have any question, don't hesitate to ask (or go to website and talk on
disqus)...

------
xwowsersx
This is awesome.

Something ironic about this though:

"As we are perfectionnist..."

~~~
mandubian
Just an expression for transition, nothing more... why ironic?

~~~
iso-8859-1
because typo

~~~
mandubian
oups :D Sorry: in French, there are 2 n in "perfectionniste" and in English, I
never know when I must remove one "n" :D

------
jeremyjh
Great work. This is a perfect application of Scala macros.

------
taligent
Nice work. Play 2 needs a LOT of work to get back to the simplicity and
elegance of Play 1. This sort of effort really helps that.

~~~
mrspeaker
To be fair, Play 2 is also vastly more powerful than Play 1 - the core
concepts powering it are complex, but they lend flexibility that allow
features like this to be added on top.

~~~
mandubian
And Play2 core is composed of very robust components without any runtime
enhancement, any magic. Using Scala power, we can build very clean tools, such
as this one, without perverting typesafe/fully-compiled basements.

~~~
taligent
See this is something I've never understood. What is this obsession with type
safety/everything compiled ?

Any possible benefits to the developer disappear in the face of a huge
increase in complexity.

~~~
gren
Making stronger apps?

Let's take the Play 1 vs Play 2 example:

How many times I got a 500 pages in the face due to a basic
NullPointerException in Play 1 groovy templates...

In new play 2 templates, because they are type-safe, they guarantee that you
will not have those basic errors.

Of-course, it doesn't guarantee everything, but it's way less error-prone. You
actually CANNOT make this kind of NPE errors with type-safe scala code.

where in java you do something like:

user.address.town // oops I forgot to test if user.address is not null

in scala:

// user.address.town wouldn't work, because address is represented as an
Option[Address]

user.address.map(_.town).getOrElse("")

~~~
taligent
I do understand your point as far as templates go. But they could have
replaced the template engine or even improved on Japid.

It just seems that for the rest of the system there isn't any real benefit
over Play1 if you are using Java as opposed to Scala.

