Aujourd'hui plus que jamais, le Javascript a le vent en poupe. On le trouve même côté serveur - ce que je trouve personnellement d'une absurdité étourdissante, mais passons.

En ce moment, la mode est aux frameworks MVC côté client ; là, j'y crois déjà un peu plus. Mais il en sort environ un par semaine, et il est difficile de faire son choix, malgré la pléthore de comparatifs qui fleurissent sur le net (ici, là, ou encore là-bas).

Thoughtworks, de son côté, estime que la peinture n'est pas encore sèche et qu'il vaut mieux attendre un peu avant de se lancer dans ce genre d'aventure en production. En effet, on a encore très peu de retours d'expérience, et la pérennité des frameworks n'est pas encore démontrée.

Pourtant, dans le tas, il y en a un qui m'a fait de l'oeil : Angular.js. Je vous propose donc une petite démonstration de son intégration avec Spring MVC côté serveur, pour réaliser une application, totalement originale n'est-ce pas, de "todo-list".

La stack

Voyons un peu la stack qui compose l'application.

Angular.js

Pour commencer, donc, Angular.js.

Malgré un nom propice aux jeux de mots les plus graveleux, c'est un projet qui paraît fort bien né. Développé et maintenu par Google (bonus +1 en pérennité) et disponible sous licence MIT, il se base sur l'incontournable JQuery pour fonctionner (bonus +1 pour la non-réinvention de la roue).

Contrairement à la plupart de ses concurrents qui se limitent plus ou moins à du templating, Angular propose de nombreuses fonctionnalités alléchantes :

• Data-binding bi-directionnel entre un modèle et des composants, sans aucune ingérence du framework.
• Templates HTML purs ; le binding est simplement réalisé par l'ajout de propriétés ng-* dans les balises (à la Wicket).
• Possibilité de créer des composants personnalisés et entièrement réutilisables, en HTML ! (ex: un <colorpicker> qui encapsulerait tout le markup et le javascript nécessaires)
• Modèle MVC2 avec un Front-controller ("router"), des Contrôleurs (JS), et des Vues (HTML). Les URLs des pages est bookmarkable.
• Interaction immédiate avec des ressources REST exposées par le serveur.
• Et la cerise sur le Kloug : Angular fournit même un framework de tests complet : TDD, mocks, tests de bout en bout...

Bref, la stack Angular est vraiment très complète !

Spring MVC

Le didacticiel d'Angular, bien qu'assez fourni, passe un peu rapidement sur l'interaction avec la partie serveur, et notamment la consommation de ressources REST. J'espère y remédier avec cet article, en démontrant son intégration avec Spring MVC/REST.

Spring MVC fait partie de la stack Spring, et propose depuis sa version 3.0 un support extensif du paradigme REST. Il est ainsi très facile de spécifier à quel type de requête HTTP répond un contrôleur (GET, POST, PUT, DELETE...), ainsi que le type des données qu'il consomme et/ou produit - par exemple, du JSON. La négociation de contenu est automatiquement gérée par Spring.

Dans notre exemple, nous produirons du contenu au format JSON, directement consommable par les modèles d'Angular ; la librairie Jackson se chargera de réaliser automatiquement le mapping objet/JSON. La combinaison de ces frameworks est d'une efficacité redoutable !

Application de démo

L'application de démonstation permet de lister, ajouter, supprimer, et voir le détail de tâches à réaliser ("to-do").

Voici quelques captures d'écrans (hé non, pas de Twitter Bootstrap cette fois !).

Côté serveur

Commençons par l'analyse de l'application côté serveur.

Une simple classe Todo sert de modèle :

public class Todo {
    private Long id;
    private String title;
    private String description;
}

Pour une raison de simplicité, les Todo sont stockés dans une Map directement dans le contrôleur - l'implémentation des couches de service et de persistence est laissée comme exercice au lecteur.

Les Todo sont exposés sous la forme d'une ressource REST de la façon suivante :

• GET /todo : liste des Todo
• GET /todo/{id}: récupération d'un Todo par son Id
• PUT /todo : enregistrement d'une nouveau Todo
• DELETE /todo/{id} : suppression d'un Todo par son Id

Le Contrôleur Spring MVC exposant la ressource est implémenté comme suit (je passe volontairement sur la configuration de la servlet et du contexte Spring - ils sont tout à fait standards) :

@Controller
public class TodoController {
 
    private static final AtomicLong todoIdGenerator = new AtomicLong(0);
    private static final ConcurrentSkipListMap<Long, Todo> todoRepository = new ConcurrentSkipListMap<Long, Todo>();
 
    @RequestMapping(value = "/todo", method = RequestMethod.GET, produces = "application/json")
    public @ResponseBody List<Todo> list() {
        return new ArrayList<Todo>(todoRepository.values());
    }
 
    @RequestMapping(value = "/todo/{id}", method = RequestMethod.GET, produces = "application/json")
    public @ResponseBody Todo getById(@PathVariable long id) {
        return todoRepository.get(id);
    }
 
    @RequestMapping(value = "/todo", method = RequestMethod.PUT)
    @ResponseStatus(HttpStatus.NO_CONTENT)
    public void create(@RequestBody Todo todo) {
        long id = todoIdGenerator.incrementAndGet();
        todo.setId(id);
        todoRepository.put(id, todo);
    }
 
    @RequestMapping(value = "/todo/{id}", method = RequestMethod.DELETE)
    @ResponseStatus(HttpStatus.NO_CONTENT)
    public void delete(@PathVariable long id) {
        todoRepository.remove(id);
    }
 
}

Points intéressants :

• Les méthodes list() et getById() renvoient de simples objets Java : le mapping JSON est automatiquement réalisé par la librairie Jackson. Cela améliore considérablement la testabilité du code du contrôleur !
• Les méthodes ne produisant aucune donnée, comme create() et delete(), renvoient un code HTTP 204 "NO CONTENT"
• Les annotations PathVariable et RequestBody permettent d'extraire et de convertir les paramètres des requêtes HTTP ; l'annotation ResponseBody permet au contraire de convertir puis de placer l'objet renvoyé dans le corps de la réponse HTTP.

Simple et efficace.

Mais voyons maintenant comment cette ressource est consommée côté client.

Côté client

Angular respecte le bon vieux pattern MVC 2. C'est donc sans surprise qu'on retrouve les concepts de Front Controller, Contrôleur, Vue, et Modèle. La communication avec le serveur, quant à elle, est déléguée à un service Todo spécifique, que je vous présenterai plus loin.

Pour faciliter le développement et la maintenance de l'application, le Front Controller, les Contrôleurs et les Services sont isolés dans 3 fichiers distincts.
La page hôte est donc configurée comme suit :

<!doctype html>
<html>
<head>
    <title>Todo.ng</title>
    <meta charset="UTF-8">
    <link href="css/style.css" rel="stylesheet"/>
    <script src="js/libs/angular-1.0.1.js"></script>
    <script src="js/libs/angular-resource-1.0.1.js"></script>
    <script src="js/app/application.js"></script>
    <script src="js/app/services.js"></script>
    <script src="js/app/controllers.js"></script>
</head>
<body>
    ...
</body>
</html>

Le Front controller

Le rôle d'un Front Controller est celui d'un guichet d'accueil : il accepte toutes les requêtes, mais ne les traite pas lui-même ; il délègue au contraire chaque requête à un Contrôleur spécifique, sélectionné en fonction d'un certain critère - le plus souvent, l'URL de la ressource demandée.

Comme nous sommes ici dans une application de type single-page, il n'existe qu'une seule URL : celle de la page HTML embarquant l'application. Pour différencier les différents états de l'application, Angular utilise donc les "ancres" HTML, qui peuvent varier librement au sein de l'URL :

http://company.com/app/document.html          // URL du document hôte
http://company.com/app/document.html#etat1    // Avec ancre "etat1"
http://company.com/app/document.html#etat2    // Avec ancre "etat2"

Pour notre application, les mappings sont les suivants (les chemins doivent commencer par un slash pour qu'Angular les reconnaisse). Vous pouvez les reconnaître sur les captures d'écrans vues plus haut.

• http://<application>/#/todo/list : liste des Todo
• http://<application>/#/todo/new : saisie d'un nouveau Todo
• http://<application>/#/todo/{id} : détail du Todo d'identifiant {id}

Nous devons maintenant associer à chaque chemin un Contrôleur et une Vue. Angular utilise pour cela un routeProvider, configurable grâce à une API fluide :

angular.module('todoApp', ['todoService']).
    config(['$routeProvider', function ($routeProvider) {
        $routeProvider.
            when('/todo/list', {templateUrl:'views/todo-list.html',   controller:TodoListController}).
            when('/todo/new',  {templateUrl:'views/todo-new.html',    controller:TodoNewController}).
            when('/todo/:id',  {templateUrl:'views/todo-detail.html', controller:TodoDetailController}).
            otherwise({redirectTo:'/todo/list'});
}]);

Deux petits réglages restent à effectuer pour que l'application puisse prendre vie : l'associer à la page hôte à l'aide de la propriété ng-app, et indiquer l'emplacement où les vues seront affichées avec la propriété ng-view.

<!doctype html>
<html ng-app="todoApp">
<head>
    <title>Todo.ng</title>
    <meta charset="UTF-8">
    <link href="css/style.css" rel="stylesheet"/>
    <script src="js/libs/angular-1.0.1.js"></script>
    <script src="js/libs/angular-resource-1.0.1.js"></script>
    <script src="js/app/application.js"></script>
    <script src="js/app/services.js"></script>
    <script src="js/app/controllers.js"></script>
</head>
<body>
   <div ng-view></div>
</body>
</html>

Nous pouvons maintenant commencer le développement des contrôleurs et des vues.

Contrôleur et Vue pour l'écran de liste

Contrairement à d'autres frameworks MVC / JS, les contrôleurs Angular sont de simples fonctions Javascript, très facilement testables. S'ils dépendent de certains services tiers ($location, etc.), il leur suffit de les demander en paramètre ; le mécanisme d'injection de dépendances d'Angular se chargera de les leur fournir au runtime.

Un contrôleur possède un certain nombre de propriétés qui forment son modèle, ainsi que de méthodes permettant de les manipuler.
Pour éviter les interférences inter-contrôleurs et bénéficier du mécanisme de binding bidirectionnel avec la vue, ces propriétés et méthodes ne sont pas déclarées directement dans le contrôleur, mais sur l'objet $scope qui lui est passé en paramètre.

Prenons l'exemple (simplifié) du contrôleur TodoListController. Son contexte contient la liste des Todo à afficher à l'écran, ainsi qu'une méthode permettant de naviguer vers la page de saisie d'un nouveau Todo.

function TodoListController($scope, $location, Todo) {
 
    // List of Todos, loaded by the Todo service
    $scope.todos = Todo.query();
 
    // Navigation to the "New Todo" page
    $scope.gotoTodoNewPage = function () {
        $location.path("/todo/new")
    };
}

(Note : pour naviguer vers la page de saisie d'un Todo, un simple lien aurait suffi, comme pour naviguer vers le détail d'un Todo ; mais j'ai utilisé un bouton afin de présenter l'appel d'une méthode sur le contrôleur.)

La vue associée est un simple fichier HTML, dont certaines balises sont dotées de propriétés Angular (ng-*) permettant de lier leur contenu au modèle du contrôleur.

<div id="todoList">
 
    <h2>Liste des todos</h2>
 
    <ul>
        <li ng-repeat="todo in todos">
            <a href="#/todo/{{todo.id}}">{{todo.title}}</a> :
            {{todo.description}}
        </li>
    </ul>
 
    <button ng-click="gotoTodoNewPage()">Ajouter</button>
 
</div>

Notez l'itération sur la liste des Todo, ainsi que l'utilisation de double accolades pour parcourir le graphe du modèle.

Services REST

Le dernier point qu'il nous reste à voir est l'intégration avec les services REST exposés par le serveur.

Angular propose un modèle inspiré du pattern Active Record. Un objet de type $resource représente une ressource REST exposée à une certaine URI. Les opérations de création, suppression, requêtage sont exposées sous la forme de méthodes prédéfinies.

• query() : récupère tous les objets par une requête GET
• get() : récupère 1 objet à l'aide d'une requête HTTP GET, en passant l'identifiant de la ressource
• save() : crée une nouvelle ressource grâce à une requête HTTP POST
• remove() et delete() : deux méthodes équivalentes, qui suppriment une ressource via une requête HTTP DELETE contenant son identifiant.

Il est toutefois possible de modifier les réglages de ces méthodes, ou d'en fournir de nouvelles.

Voici la configuration de notre ressource Todo :

angular.module('todoService', ['ngResource']).
    factory('Todo', function ($resource) {
        return $resource('rest/todo/:id', {}, {
            'save': {method:'PUT'}
        });
    });

Les points importants sont :

• L'URI de la ressource, sous forme de template : rest/todo/:id. La partie "rest/" correspond au mapping de la servlet Spring, et la fin, "todo/:id", au pattern des mappings REST vus plus haut.
• La modification du paramétrage de de la méthode save, afin qu'elle produise une requête HTTP de type PUT au lieu de POST.

Grâce à cette simple déclaration, toute la communication client/serveur en REST est automatiquement prise en charge !

Voyons comment cette ressource est utilisée dans les contrôleurs :

//TodoListController
function TodoListController($scope, $location, Todo) {
    // Retrieve all Todo
    $scope.todos = Todo.query();
    ...
}
 
// TodoDetailController
function TodoDetailController($scope, $routeParams, Todo) {
    // Load a Todo by id (taken from the path)
    $scope.todo = Todo.get({id:$routeParams.id});
    ...
}
 
// TodoNewController
function TodoNewController($scope, $location, Todo) {
    // Save the new Todo
    $scope.submit = function () {
        Todo.save($scope.todo, function (todo) {
            $location.path('/');
        });
    };
    ...
}

Conclusion

Au milieu de la jungle des nouveaux frameworks Javascript, Angular.js se distingue par sa large palette de fonctionnalités, allant du binding automatique à la gestion des ressources REST, en passant par l'architecture MVC2 et le templating en pur HTML.
Son développement par Google est un gage (certes pas absolu) de pérénnité et de qualité, et le caractère non-intruif du framework limite le risque d'enfermement technologique.

Couplé à Spring MVC et Jackson côté serveur, il offre un modèle de développement léger et productif, adapté au développement d'applications de type single-page.

Si j'étais vous, je garderais un oeil sur ce framework !

Ressources

Je vous invite consulter le code source de l'application sur GitHub. Clonez-le, jouez avec !

Et pour apprendre...

• Angularjs.org, le site officiel
• Angular API, la documentation des fonctions
• La chaîne Youtube Angular

Et un article de mon camarade Adrien Lecharpentier sur les petites subtilités de Javascript sur lesquelles vous pourriez buter lors de l'utilisation d'Angular :

• Angular JS doesn't like numbers