Jazoon, Présentation de Play! Framework 2.0

On nous annonce cette fois une session de live coding en Scala sur Play! 2.0. Mes yeux se mettent à briller. Le code, il n’y a que ça de vrai! C’est vrai qu’avec nos XKE (Xebia Knowledge Exchange), je suis plus habitué à voir du code et à mettre les mains dedans qu’à lire des slides.
La présentation sera axée sur la programmation asynchrone avec Play, en Java puis en Scala.
Notre maître de cérémonie sera cette fois Fredrik Ekholdt de la société Typesafe, la société derrière Scala, Play! et Akka.

Fonctionnalité de base

Play! framework, j’en ai beaucoup entendu parler (comme tout le monde), mais j’ai manqué de temps jusque là pour m’y plonger. J’attends beaucoup de cette présentation.
Passé la génération d’un template d’application et la structure du projet, on s’attaque rapidement aux choses sérieuses. Fredrik nous montre comment Play avec SBT gère les erreurs de compilations.
Elles apparaissent tout simplement dans votre navigateur, de façon très claire et concise. On comprend alors l’intérêt pour le développeur de ne pas avoir à basculer entre une fenêtre de log et le navigateur ! C’est un premier bon point.
Le plus intéressant, c’est que ce mécanisme fonctionne pour le code, les templates, le javascript, les CSS… Cette fonctionnalité devient vraiment très intéressante pour le développeur.

Pile d’exécution

Après avoir vu les templates et les contrôleurs, nous découvrons les routes. C’est un peu déroutant de penser à cartographier tous les points d’entrées HTTP de son application. Mais c’est après tout le rôle du contrôleur.

Nous découvrons ensuite les différentes combinaisons que nous pouvons faire :

• Template + routes
• Template + routes + JavaScript
  Cela devient intéressant. Play! vérifie un premier niveau d’erreurs du code JavaScript, et peut le ‘minifier’ à la volée. Il est aussi recompilé à chaque fois, pas besoin de packager le projet pour voir les changements dans le navigateur. On peut accéder au source, en version minifiée, directement via l’url des assets.
• Template + routes + JavaScript + Less
  De la même façon, on peut accéder aux fichiers Less, ils sont compilés et on profite là aussi de la gestion des erreurs de syntaxes.

Quelques librairies pour les WS

Nous découvrons ensuite les librairies json et ws pour créer un client de WebService en JSON.

Appel bloquant

Pour utiliser un web service, Fredrik créé un contrôleur et commence à coder en Scala. On commence par définir deux fonctions, onError et onSuccess.

def onError(t :Throwable)
def onSuccess(r:Response) = r.json \ "value" //DSL FOR JSON IN PLAY
var processJson = ws.WS.url(url).get().await.fold(onError,onSuccess)

Le problème avec cette ligne est l’utilisation de await. C’est un appel bloquant. Rien ne se fera tant que le WebService n’aura pas répondu.

Les promesses

La réponse apportée: play.libs.F.Promise
C’est une promesse de réponse, un callback qui sera exécuté quand la réponse sera arrivée.

En Java :

Promise<Response> promiseOfResponse = WS.url(url).get();
return async(promiseOfResponse.map(new Function<Response,Result>(){
 public Result apply(Response r){
  return ok(index.render(transform)));
 }
}));

ou en Scala :

def index = Action{
 Async{
  val promiseOfResponse = ws.WS.url(url).get()
  promiseOfResponse.map (r=> Ok(views.html.index(r)))
 }
}

Cela est rendu possible grâce à la fonction Async. Nous utilisons ensuite une fonction de type map pour transformer la promesse de réponse en réponse. Nous avons rapidement introduit de l’asynchrone dans l’application. Il reste à voir comment introduire la notion de timeout.

La fonction ok se charge ensuite du rendu de la réponse et pour qu’elle soit envoyée ensuite à l’utilisateur.

Gestion du timeout

Pour pouvoir fixer un timeout sur une action asynchrone, il faut utiliser la librairie libs.concurent de Scala. Le code devient alors celui-ci :

Async{
 def onError(t :Throwable)
 def onSuccess(r:Response) = r.json \ "value" //DSL JSON OF PLAY

 val  promiseOfJson = ws.WS.url(url).get().orTimeout("Oups",1000).map(_. fold(onSuccess,onError))
 promiseOfJson.map(j=>Ok(views.html.render(j))
}

La fonction orTimeout(« Oups »,1000) retournera la valeur par défaut « Oups » si le timeout d’une seconde est dépassé. Cette écriture évite élégamment les séries de if-else ou try-catch-finally. Il est alors possible de composer deux appels, asynchrones, avec un timeout, et de construire une réponse commune.

val promiseOfResponse1 = ws.WS.url(url).get()
val promiseOfResponse2 = ws.WS.url(url2).get()

val promiseOfResult = for{
 r1 <- promiseOfResponse1
 r2 <- promiseOfResponse2
} yield compose(r1,r2)

promiseOfResult.map(r=> Ok(views.html.index))

Ce sont les fonctions yield puis compose qui permettent de synchroniser et joindre les deux appels asynchrones. On applique de nouveau une fonction map pour transformer cette promesse en réponse, et le tour est joué.

Iteratee

Le temps commence à manquer pour ce talk mais le speaker le prend pour nous parler rapidement des éléments Iteratee et Enumerator. Ces patterns sont utilisés pour pouvoir travailler sur des collections d’éléments et de les composer avec des Promise. Il permet notamment de travailler par paquets d’éléments. Nous n’avons pas eu le temps de voir le code dans le détail.

Conclusion

Cette aperçu de Play! m’a vraiment mis l’eau à la bouche. Il adresse les grandes problématiques du moment pour les applications Web. Il y a cependant un ticket d’entrée pour connaître les grands patterns à utiliser. Mais il me semble que le jeu en vaut largement la chandelle.