Tutoriel sur une introduction au framework Web WebMotion

WebMotion est un framework Java Web. Il s'occupe des interactions entre le client (navigateur en général) et des services Java. Il repose sur JEE, en particulier sur l'API des servlets. WebMotion va vous permettre de simplifier la mise en place d'un serveur, c'est-à-dire : la conversion des paramètres, la gestion des URL… en proposant une approche KISS (Keep it Simple, Stupid).

D'autres frameworks Java Web existent comme Struts, Spring MVC, Play ! ils comportent des faiblesses comme :

• des fichiers de configuration volumineux, par exemple pour Struts avec les fichiers de configuration en XML qui deviennent vite verbeux ;
• une architecture contraignante fixée par le framework, par exemple pour Play ! il impose l'utilisation d'un serveur d'applications particulier ;
• une forte dépendance au niveau des vues, par exemple pour Struts un ensemble de tags est nécessaire pour décrire les vues ;
• des excès d'annotations qui polluent le code Java, par exemple pour Spring MVC vous pouvez vous retrouver avec 5-6 annotations sur les méthodes de vos classes.

WebMotion s'inpire des bons concepts des différents frameworks en utilisant une syntaxe proche de Play ! pour la configuration, en étant compatible sur différents serveurs d'applications (Tomcat, Jetty et Glassfish), en n'imposant pas de contraintes au niveau des vues et en utilisant à bon escient les annotations.

De plus, WebMotion s'inscrit dans une architecture orientée outils. Il n'impose pas de persistance, d'injection de dépendances… bien qu'il existe des intégrations sous forme d'extras vers Spring, Hibernate… Il est aussi compatible avec divers IDE (Eclipse, Netbeans…).

Ce tutoriel va vous permettre de lancer une première application basée sur WebMotion.

Le tutoriel se base en partie sur Maven et il est nécessaire d'avoir une version d'installée pour le réaliser complètement.

WebMotion utilise Maven pour vous permettre de générer un squelette de votre projet. Mais il est possible d'utiliser un autre système de build.

$ mvn archetype:generate \
    -DarchetypeGroupId=org.debux.webmotion \
    -DarchetypeArtifactId=webmotion-archetype \
    -DarchetypeVersion=2.4 \
    -DgroupId=org.example \
    -DartifactId=myapp \
    -Dpackage=org.example.myapp \
    -Dversion=1.0-SNAPSHOT \
    -DusesExtras=N

Vous pouvez dès à présent lancer le projet sur un serveur d'applications types Tomcat, Jetty ou Glassfish. Dans le cas du tutoriel, nous allons le lancer grâce à Maven et au plugin Jetty. Pour cela, rien de plus simple, il suffit de taper :

$ mvn jetty:run

Après le démarrage du serveur, vous pouvez ouvrir l'URL suivante http://localhost:8080/myapp/ dans votre navigateur préféré. Vous allez voir apparaître « Hello myapp! » à l'écran. Le nom de la webapp correspond au nom de l'artefact id.

Le schéma suivant vous présente comment fonctionne WebMotion.

1. Réception de la requête du client.
2. Recherche de l'action dans le fichier de route (fichier de mapping).
3. Exécution de l'action Java (contrôleur).
4. Retourne la réponse au client renvoyée par l'action Java (render).

Nous allons passer en revue les différents composants de WebMotion.

Le premier composant concerne la configuration pour le serveur d'applications. WebMotion repose sur les fragments des servlets 3, ce qui lui permet de n'avoir aucune configuration dans le fichier web.xml :

<web-app version="3.0"
  xmlns="http://java.sun.com/xml/ns/javaee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
  http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" />

Le point central du serveur avec WebMotion est le fichier de routes (nommé mapping). Il se trouve dans le répertoire des ressources de votre application. Ce fichier vous permet de centraliser l'ensemble des interactions sur le serveur. Remarque importante, la recherche se fait en fonction de l'ordre d'apparition des règles.

Le fichier de routes peut contenir les rubriques suivantes :

• config : contient la configuration (les chemins par défaut des fichiers…) ;
• actions : contient les actions liées à des URL ;
• errors : contient les actions liées en cas d'erreur ;
• filters : contient les filtres sur les actions ;
• extensions : inclut d'autres fichiers de routes.

Revenons sur notre fichier de routes actuel et regardons de plus près la règle suivante :

[actions]
*       /            Base.index

La syntaxe du fichier de routes est la suivante pour une ligne dans la rubrique d'actions :

1. La méthode HTTP de l'URL (GET, POST…) ici c'est « * » pour toutes les méthodes ;
2. Le path de l'URL ;
3. L'action Java à exécuter, ici la méthode « index » de la classe « Base ».

Un autre élément de syntaxe, les commentaires dans le fichier de routes se font par un croisillon au début :

# Mon commentaire

Les actions Java associées dans le fichier de routes sont appelées contrôleurs. La classe Java doit hériter de WebMotionController pour être considérée comme un contrôleur. À la fin de votre méthode, vous spécifiez la réponse pour le client, ici vers une page JSP.

public class Base extends WebMotionController {
    public Render index() {
        return renderView("index.jsp");
    }    
}

Le scope par défaut des contrôleurs est de type singleton, c'est-à-dire le même contrôleur est utilisé pour toutes les requêtes. Vous pouvez modifier le cycle de vie des contrôleurs dans la section « config » dans le fichier de routes, pour qu'un contrôleur soit créé pour chaque requête ou qu'une même instance soit utilisée pour toutes les requêtes d'un utilisateur.

En héritant de la classe WebMotionController, vous disposez de l'ensemble des « Renders » disponibles dans WebMotion. Un Render représente le retour à effectuer vers le client. Il existe plusieurs types de retours, redirections, JSON, XML, contenus, téléchargements…

Nous allons modifier le fichier de routes pour gérer le cas d'un paramètre dans l'URL. Il est possible de le faire passer directement dans l'URL :

[actions]
*       /{who}            Base.index

ou de le faire passer en tant que paramètre :

[actions]
*       /?who={}            Base.index

La conversion des types des paramètres est automatique et est gérée par WebMotion. Vous pouvez tout de même agir sur la conversion des paramètres en enregistrant vos propres convertisseurs. La conversion repose sur l'API BeanUtils d'Apache. Vous avez aussi la possibilité d'injecter des valeurs autres que celles de requêtes basées sur le type ou le nom du paramètre de la méthode.

La prochaine étape consiste à modifier l'action Java. Le paramètre est directement disponible dans la signature de la méthode ainsi :

public class Base extends WebMotionController {
    public Render index(String who) {
        return renderView("index.jsp", "name", who); // couple clé = valeur
    }    
}

Vous pouvez remarquer que le paramètre est passé à la page JSP sous la forme de clé-valeur. La page est disponible dans le répertoire « package.views » défini dans la section « config » du fichier de routes (ici WEB-INF/org/example/myapp). Modifiez votre page JSP pour afficher le « name » :

<html>
    <head>
        <title>myapp</title>
    </head>
    <body>
        <h1>Hello ${name}!</h1>
    </body>
</html>

Relancez votre serveur et tapez http://localhost:8080/myapp/you ou http://localhost:8080/myapp/?who=you. Vous devez maintenant voir s'afficher à l'écran « Hello you! ».

Finissons par ajouter un formulaire pour pouvoir saisir la valeur de notre « hello ». Pour cela, créez un fichier form.jsp dans le même répertoire que le fichier index.jsp ainsi :

<html>
    <head>
        <title>myapp</title>
    </head>
    <body>
        <form action="/myapp/hello" method="get">
            Name : <input type="text" name="who">
            <button type="submit">submit</button>
        </form>
    </body>
</html>

Ensuite, modifiez le fichier de mapping pour mettre le formulaire en première page et déplacer l'action Java sur l'URL /myapp/hello. Le mot clé « view » est un raccourci pour renvoyer l'utilisateur sur une page donnée sans passer par une action Java.

[actions]
*         /                     view:form.jsp
*         /hello?who={}         Base.index

Relancez le serveur et testez votre application. Vous pouvez saisir le nom qui vous plaît maintenant.

Pour ajouter une validation côté serveur, WebMotion s'appuie sur le standard de validation de Java (JSR 303). Vous pouvez modifier votre contrôleur pour interdire la saisie d'un nom vide :

public Render index(@NotEmpty String who) {
    return renderView("index.jsp", "name", who);
}

Si vous essayez de valider votre formulaire avec un champ vide maintenant, une page d'erreur s'affiche :

Pour prévenir l'utilisateur correctement en cas d'erreur, nous allons rajouter une règle dans le fichier de mapping. Il est possible, pour attraper l'erreur, avec une action associée, soit de préciser le code HTTP de l'erreur :

[errors]
code:500                                                 view:error.jsp

soit la classe de l'exception :

[errors]
javax.validation.ConstraintViolationException                                         view:error.jsp

Ici, une page est simplement affichée. Il serait possible de renvoyer l'ensemble des éléments au formulaire pour qu'il affiche l'erreur, mais il est conseillé d'utiliser une validation JavaScript avant d'envoyer le formulaire et de garder une validation côté serveur pour se prémunir des appels erronés avec une gestion d'erreurs globale.

<html>
    <head>
        <title>myapp</title>
    </head>
    <body>
        <h1 style="color: red">Le champ est vide.</h1>
    </body>
</html>

Nous avons vu l'approche classique de site de page en page. En ne s'occupant que de la partie serveur, WebMotion permet d'être polyvalent. Il est possible de s'intégrer dans une architecture REST en renvoyant les données sous le format JSON. Vous pouvez par exemple l'utiliser avec AngularJS pour ne citer que celui-là.

WebMotion propose un ensemble d'extras pour développer rapidement vos applications avec :

• SiteMesh pour la décoration de page ;
• Hibernate pour l'accès à la base de données ;
• Spring pour l'injection de dépendances ;
• Shiro pour la sécurité.

Vous pouvez retrouver de nombreuses informations sur le site Web http://www.webmotion-framework.org. Je vous invite à regarder la partie démonstration qui illustre l'ensemble des fonctionnalités.

Nous tenons à remercier Logan Mauzaize pour sa relecture technique, Malick SECK pour sa relecture orthographique et Mickael Baron pour la mise au gabarit.