Hello Hervé
Est-ce que tu peux nous filer un poil plus d'info sur ce que tu veux faire ? En particulier l'exemple vers lequel tu pointes est dans la doc de play 2.0 et l'exemple donné dans la 2.4 (
https://www.playframework.com/documentation/2.4.x/ScalaJsonHttp) est déjà bien plus proche de ce que je fais en temps normal : créér des case classes permettant de modéliser ma requête/réponse puis mapper mon JSON dedans. Du coup pour des grosses requêtes ça devient plus facile à gérer avec de la composition et si tu as des sous arbres communs a plusieurs services tu peux envisager de réutiliser les classes de DTO (je ne dis pas que c'est forcément une bonne idée c'est du cas par cas)
Je tiens à préciser que dans l'exemple de la 2.4 ils construisent le mapping Json /case class à la main mais qu'il y a des macros pour le faire plus vite.
Du coup une action de contrôleur typique dans mon appli ressemble à :
def myService = Action.async(parse.json) { implicit request =>
request.body.validate[MyServiceRequest].fold(
jsonErrors2FutureBadRequest(logger),
_ => Future.successful(Created)
)
}
Sa responsabilité est de gérer la désérialisation des requêtes dans la forme dont j'ai besoin, les erreurs associées et la sérialisation des résultats du traitement (que ce soit un succès ou une erreur) Si le traitement est vraiment trivial je le laisse dans l'action du controlleur mais sinon je le délègue a un service.
Grosso modo la définition de MyServiceRequest (souvent déclarée en privé dans la classe du controlleur ou en private[package] dans package.dtos mais là encore c'est du cas par cas) ressemble à :
case class MyServiceRequest(property1:String, property2:String,...)
object MyServiceRequest{
implicit val myServiceRequestFormat = Json.format[MyServiceRequest]
}
Comme perso je trouve que les macros du projet ont des limitations, j'utilise
http://play-json-extra.megl.io/index.html qui gère tout un tas de trucs comme la présence de valeur par défaut ou une sérialisation plus orienté énumération pour des objets héritants de traits scellés.
Si tel quel c'est trop verbeux il est possible d'enrichir
l'action pour réduire le boilerplate : https://www.playframework.com/documentation/2.4.x/ScalaActionsComposition de mettre @JsonFormat dans play-json-extensions ou de passer par du jackson pur comme d'habitude, éventuellement avec jerkson (pour avoir les serializers/deserializers vers les collections scala directement).Au passage il y a des versions de jerkson compilées pour scala 2.11 sur github (mais pas sur celui de coda hale). D'autre part, la lib n'est pas très utilisée par rapport à l'approche TypeClass mais le niveau de maintenance à faire dessus est assez faible (jackson et la lib standard scala sont des APIs stables) .Pour une boite un peu conséquente ça peut valoir le coup de maintenir et publier une version qui va vite devenir la référence quitte a demander a Hale si il est ok.
jean