Formation Play! framework

Auteur : Benoît Simard – Licence : Creative Commons BY-NC-SA.

Play! Framework–

Formation

http://www.playframework.org/

http://www.bsimard.com/


Quelques mots sur Play!




Historique

2007 Créé par Guillaume Bort

2008 Framework Open Source

2009 Version 1.0 en octobre

2010 Version 1.0.1 en janvier

2011 Version 1.1 en octobre




Un tour d'horizon

Pas de compilation

Respecte le protocole HTTP

RESTFull

Stateless

Système de templating simple

Groovy

Framework MVC

Rapide (exécution & développement)

Extensible par des modules

Pure JAVA !!!




La communauté

Twitter

http://twitter.com/playframework

~ 1600 followers

~ 500 tweets

Google group

http://groups.google.com/group/play-framework

~ 15000 messages

~ 1300 membres

~ 40 messages / jour

Github

http://github.com/playframework/play

~ 120 watchers

http://twitter.com/playframework

http://groups.google.com/group/play-framework

http://github.com/playframework/play




Pourquoi un nouveau framework web en Java




Pourquoi un nouveau web framework java

Alors qu'il existe déjà JSF

Struts

Spring MVC

Wicket

...





« Java web frameworks are created by java developpers, not

Web developpers »

« Java developpers are building Java applications, not web

applications »





Web VS middleware

La complexité en Java est culturelle

InterfacesAbstractionRMIEJBSOAP





WEB=

REST





« Play ! Framework is the first reasonable Java web framework I

have personnaly seen»

Bret Taylor




Les avantages de Play!




Cycle de Vie

Framework J2EE Traditionnel




Cycle de Vie

Avec Play!




Les fonctionnalités

Module de sécurité

CRUD

Validation

Jobs asynchrones

I18n

Tests (unitaire & selenium)

L'envoie de mail

Webservices

RESTFull services





Et avec les modules :

OpenID, CAS

Export en PDF

Export Excel

Rendre les CSS dynamiques

Minifier

Recherche

…

http://www.playframework.org/modules





Play! est compatible avec toutes les librairies Java.

Play ! Intègre déjà :

Hibernate

Google Gson

Commons (fileupload, httpclient, email, logging …)

EhCache

...




A la découverte de play!




Architecture




La structure d'une appli

Créer une nouvelle application

Play new monApplication

Structure de l'application

./conf

./conf/routes

./conf/application.conf

./conf/messages

./test

./lib

./public

./app

./app/models

./app/controllers

./app/views




Les routes




Le fichier de configuration

Configuration

De la base de données

Du logger

Du cache

Du serveur SMTP

Des modules

System settings









Mais comment on fait pour tous travailler avec le même fichier de configuration,

alors que nos environnements ne sont pas identique ?

play id




A la découverte de play ! :Le Model




Le model

Définition en JPA

Beaucoup d'annotation ! Que ce soit pour le mapping avec la base de données ou pour la structure / validation des champs– @Entity– @OneToMany– @Column– … (pour la validation nous verrons plus loin)

Doit étendre de la classe « Model »




Le model




Le model

Tout est public ! Il n'y a pas de getter/setter

Play : génère les getters/setters au runtime

Vous pouvez surcharger les getters/setters




Le model

La classe « Model » est un Helper




Le model

Import / Export de la base en YML

Import natif dans play

Export avec le module YML(version 1.0)– http://github.com/sim51/logisima-play-yml




A la découverte de play! :Les controllers




Les controllers

Doit étendre la classe « Controller »

Possède que des méthodes public static void

Une méthode est appelée selon une route

Un controller donne accès à plusieurs méthode de rendu

Json

Xml

Pdf

…

On peut chainer les actions

Redirection

En appelant directement la méthode : Application.index()




Les controllers




Les controllers

Les paramètres d'entrées des Controlleurs

Ce sont les variables en GET / POST / DELETE / PUT

Les GET peuvent être défini dans le fichier de routes

Il n'y pas que des types simples, on peut y mettre des objets de notre model. Ces objets seront créée via les paramètres de la request. Exemple :– resto.name– resto.url– ...




Les controllers

Les paramètres de sorties des controlleurs

Il suffit d'ajouter les objets à la méthode render

exemple :– render("Public/resto/show.html", resto, randomID) ;

Ou d'appeler la méthode renderArgs– renderArgs.put(« resto », resto);

Sinon, il y a les différents scopes




Les scopes

Application

Session

Stocké dans un cookie sécurisé et accéssible durant toute la session de l'utilisateur (4Kb).

Flash

Stocké dans un cookie sécurisé et uniquement accessible par la prochaine requête (4Kb).

Request

Pour tout le reste, il y a le cache !




Les controllers

Les fichiers de rendu

Par défaut Play! cherche le fichier suivant :– app/views/[Classe Name]/[Methode Name].html– app/views/Application/index.html

Mais on peut spécifier un fichier– render("Public/resto/show.html", resto);




Les controllers

C'est bien beau de ne plus

avoir la « servlet-api »,

mais comment je fais pour faire un filtre ?




Les controllers

Il existe les intercepteurs !@Before

– Exécute la méthode annotée avant chaque action du Controller. On peut exclure certaine action (unless={« login », « logout »}), ou définir seulement quelques actions (only={« login », « logout »})

@After

– Exécute la méthode annotée s'exécute après chaque action du Controller.




Les controllers

@Finally

– Exécute la méthode annotée après chaque résultat d'action du Controller.

@With

– Permet de déléguer les intercepteur à une classe.

Les intercepteurs s'appliquent même aux sous-classes !




A la découverte de play! :Les templates




Les templates

La Syntax

Expressions : ${ … }

– Permet d'afficher une variable: ${resto.name}Messages : &{ … }

– I18N. Affiche la valeur correspondant à la clef (définie dans le fichier conf/messages)

Actions (reverse Route):

– @{ …} : génère l'URI de l'action : @{Application.index()}

– @@{ …} : génère une URL absolueCommentaires : *{ … }*

Scripts : %{ … }%




Les templates

Les décorateursFichier html de template parent

Un template hérite du décorateur

#{get /}, #{set /}, #{extend /} & #{doLayout /}




Les templates

Les Tags : #{tagName /}Un tag est un fragment de HTML qui peut être appelé avec des paramètres.

Un tag correspond à un fichier devant absolument se trouver dans le répertoire « app/views/tags », et le nom du tag correspond au nom du fichier.

Les paramètres passés au tag sont accessibles dans le tag via _[le nom de mon paramètre]




Les templates

Les Tags : #{tagName /}Exemple d'appel :

Le fichier article.html :




Les templates

Les extensions

Certaines méthodes sont ajoutés au objets dans les templates :

– Date|format() : pour formater une date : ${myDate.format('dd MMMM yyyy hh:mm:ss')}

– String|escapeHtlm() : pour échapper le code html

– String|nl2br() : remplace les sauts de ligne par des <br/>

– String|raw() : pour ne pas échapper le code html.

– …

Il est à noter que Play ! échappe automatiquement tous les textes.

http://www.playframework.org/documentation/1.1/javaextensions

http://www.playframework.org/documentation/1.1/javaextensions




Les templates

Les extensions personnaliséesIl est possible de créer ses propres extensions !

Il suffit de créer une classe

– qui étend de JavaExtensions– Contenant des méthodes public static




A la découverte de play! :Les jobs




Les Jobs

Doit étendre la classe « Job »

@Every(«1d»)

@On(«0 0 12 * * *)– CRON expression

@OnApplicationStart




Pour aller plus loin ...




La validation




La validation

3 façons de valider une requête :

Directement dans le controller en appelant la méthode « validation ».

En ajoutant les annotations dans la déclaration des paramètres de la méthode.

Dans le POJO en ajoutant les annotations, et en ajoutant @valid dans la déclaration du pojo comme paramètre de la méthode.




La validation

Méthode 1




La validation

Méthode 2




La validation

Méthode 3




La validation

Dans les templates




La validation

Les validateurs :

Email : vérifie que le champ est une adresse mail

– validation.email(mail)

– @Email String mail

Equals : vérifie que le champ est égale à un autre (ex : password confirmation)

– validation.equals(password, passwordConfirmation)

– @Equals(« passwordConfirmation ») String password

Future : vérifie que la date est dans le future (en fonction de la date du jour ou de la date de référence passée en paramètre)

– validation.future(maDate) | validation.future(maDate, « 1971-12-31 »)

– @InFuture String maDate / @InFuture(« 1971-12-31 ») String maDate




La validation

Les validateurs :

IsTrue : vérifie que le champs est à « true » (String ,Boolean ou Number)– validation.isTrue(agree)

– @IsTrue String agree

Match : Le champ valide la regex– validation.match(abbreviation, "[A-Z]{3}")

– @Match("[A-Z]{3}") String abbreviation

Max : Vérifie que le champ n'est pas plus grand que la valeur spécifiée (Number et String)– validation.max(wordCount, 7500)

– @Max(7500) String wordCount




La validation

Les validateurs :

MaxSize : taille maximum du String– validation.maxSize(url, 2083) ;

– @MaxSize(2083) String value

Min : Vérifie que le champ est plus grand que la valeur spécifiée (Number et String) – validation.min(age, 18) ;

– @Min(18) Long age

MinSize : taille minimum du String– validation.minSize(value, 42) ;

– @MinSize(42) String value




La validation

Les validateurs :

Past : vérifie que la date est dans le passé (en fonction de la date du jour ou de la date de référence passée en paramètre)

– validation.past(actualDepartureDate) ; / validation.past(expectedDepartureDate, expectedArrivalDate);

– @Past String actualDepartureDate / @Past("1980-01-01") String birthDate

Range : min & max

– validation.range(wordCount, 17500, 40000) ;

– @Range(min = 17500, max = 40000) String wordCount

Required : le champ est obligatorie

– validation.required(value) ;

– @Required String value

Url : vérifie que le champ est une url valide

– @URL String address



Entertainment & Humor

Formation Play! framework