Published by

Il y a 10 ans -

Temps de lecture 8 minutes

NoThunes, naissance d’un projet Grails

Projet NoThunes

Les exemples de prise en main du framework Grails ne manquent pas sur la toile. Nous allons tenter de dépasser les Getting started en déroulant la réalisation d’une application web de bout en bout :

  • Conception
  • Réalisation
  • Mise en production
  • Evolutions et maintenance

Parce qu’il est toujours plus agréable de travailler sur du concret, nous allons réaliser pas à pas une plateforme de musique libre en ligne, que nous baptisons : Projet NoThunes, en clin d’oeil à une autre célèbre plateforme de musique payante. Tout le code du projet est disponible sur GitHub. Ce projet est donc Open Source mais aussi « Open méthode » puisque je vous ferai partager toutes les étapes de conception/réalisation au travers d’une série d’article. Chaque article sera associé à un tag du dépôt GitHub, pour que tout le monde puisse savoir à quelle version on se réfère.

Bien évidemment il y a plus d’une bonne façon de faire. Ce projet est mené dans une optique d’amélioration personnelle et de partage donc n’hésitez pas à discuter les choix techniques et à fournir des solutions alternatives en commentaire.

Dans ce premier billet, nous allons :

  • définir le product backlog du projet
  • présenter les classes du modèle
  • démarrer notre projet
  • mettre en place la sécurité et les classes du modèle
  • créer un menu dynamique, différencié par rôle utilisateur

Note technique

Le projet est réalisé avec Grails v1.3.3.

Product Backlog

On distingue 3 rôles utilisateurs :

  • les administrateurs : par définition omnipotents sur le site pour gérer les comptes utilisateurs, les règles de sécurité, etc.
  • les internautes : les visiteurs lambda de notre site.
  • les membres : des internautes qui se seront enregistrés pour accéder à plus de fonctionnalités.

En sachant qu’un membre, s’il est authentifié, doit conserver l’accès à toutes les fonctionnalités des internautes, et qu’un administrateur doit aussi avoir accès aux fonctionnalités des membres.

Le product backlog est trié par business value décroissante. Je vous épargne le chiffrage agile et les fioritures de Scrum. :)

En tant que … je dois pouvoir …
administrateur créer des comptes utilisateurs (administrateurs et membres)
internaute m’enregistrer pour obtenir un compte membre
membre voir et mettre à jour mon profil utilisateur
membre créer des groupes de musique
membre modifier/supprimer les groupes de musique que j’ai créé
membre créer/modifier/supprimer des albums liés à mes groupes
membre créer/modifier/supprimer des morceaux liés à mes albums, en uploadant un fichier mp3
internaute naviguer dans la hiérarchie de groupes/albums/morceaux
internaute télécharger un morceau
internaute écouter un morceau
internaute rechercher des morceaux par mots-clés

Présentation du modèle de données

Il s’agit d’un cas d’école donc nous simplifions à l’extrême le modèle de données à gérer. Le but n’est pas (encore ;) ) de concurrencer les plateformes en place. On considère donc les objets :

Entité représente …
Role les rôles utilisateurs
User les comptes utilisateurs administrateurs et membres
Band un groupe de musique, créé par un membre
Album un album enregistré par un groupe
Track un morceau, une piste d’un Album

Les attributs de chacun de ces objets sont volontairement simplistes. Cela nous donne le modèle suivant :

NoThunes

Démarrage du projet

Comme tous ceux qui ont déjà survolé Grails le savent, un nouveau projet démarre toujours par le lancement de la commande :

grails create-app nothunes

qui va générer l’arborescence initiale du projet. Comme c’est toujours plus confortable, l’étape suivante sera d’importer ce projet dans votre IDE favori. Pour travailler avec Grails le choix est limité et le support inégal : NetBeans, SpringSource Tool Suite ou IntelliJ IDEA. Au pire un bon vieux vim suffira.

Mise en place de la sécurité

Le plugin de sécurité officiel du projet Grails est depuis peu le Spring Security Core Plugin, couplé au plugin Spring Security UI pour la génération des écrans de CRUD concernant les rôles et utilisateurs. Malgré cela, je lui préfère encore pour quelques temps son prédécesseur : Acegi Plugin, dont le développement a été stoppé, mais qui est plus complet et plus simple à mettre en place. D’autre part, le côté stable du plugin Acegi, comparé au développement hyperactif des plugins Spring Security est assez confortable pour notre projet.

Je vous renvoie donc au précédent article que j’ai écrit sur le sujet. Le package de base à utiliser est : fr.xebia.nothunes.

Création des classes du modèle

Maintenant que nous avons les classes utiles pour la gestion des utilisateurs et de la sécurité, ajoutons un peu de métier dans tout ça. Pour cela on utilise la commande grails create-domain-class pour chacune des entités qu’on souhaite obtenir, puis on passe en édition dessus pour ajouter les attributs. Je trouve dommage de n’avoir pas plus poussé la ressemblance avec Ruby on Rails en autorisant l’ajout des attributs directement en paramètre de la ligne de commande.

Parmi les attributs que l’on donne à chaque classe, il y en a 2 qui sont partout et bien utiles : lastUpdated et dateCreated. Ces 2 attributs indiquent à GORM qu’il faut gérer le timestamping automatique des objets qui les possèdent.

Dynamisons le menu

La documentation du plugin Acegi n’en parle pas mais si vous téléchargez les sources du plugin et que vous allez voir le fichier grails-app/taglib/org/grails/plugins/springsecurity/taglib/AuthorizeTagLib.groovy vous tombez alors sur une taglib tout à fait disponible dès que vous faites usage de ce plugin dans votre projet, et qui offre les tags suivants :

  • ifAllGranted
  • ifNotGranted
  • ifAnyGranted
  • loggedInUserInfo
  • isLoggedIn
  • isNotLoggedIn
  • loggedInUsername

Nous allons baser la différenciation des menus sur ces tags qui permettent de tester, directement dans les GSP si l’utilisateur courant possède un rôle donné ou non.

La première étape est de séparer le contenu du menu dans un fichier GSP à part. Pour l’instant notre application est telle que générée par grails. Dans le fichier grails-app/views/index.gsp se trouve la page d’accueil par défaut. Elle contient une balise <div id="nav"/> qui encapsule le menu de gauche de la page d’accueil de l’application.

Pour ajouter plus de flexibilité, on sort cette div dans un nouveau fichier qu’on va placer dans grails-app/views/menu/_nav.gsp (après avoir créé le répertoire menu bien sûr), puis on remplace dans index.gsp la présence de cette div par un tag


Si vous lancez un grails run-app et que vous allez voir la page d’accueil vous remarquerez que rien n’a changé. Le paramètre passé au tag render indique d’inclure le code du fichier GSP situé dans le répertoire menu/ et nommé _nav.gsp (le caractère est indispensable en début de nom).

Ce découpage, allié aux tags du plugin Acegi, nous conduit à un joli découpage propre :

grails-app/views/menu/_nav.gsp


grails-app/views/menu/_admin.gsp

Admin manages ...

  • roles
  • users
  • requestMaps

grails-app/views/menu/_user.gsp

Member manages ...

  • ...

grails-app/views/menu/_all.gsp

Menu

Maintenant il suffira d’utiliser le tag <g:render template="menu/nav" /> directement dans le layout global pour appliquer le menu sur toute notre application, et on a maintenant un fichier GSP par section de menu avec juste ce qu’il faut de tag de sécurité pour gérer l’affichage contextuel.

Après ce découpage, j’ai travaillé un peu le layout et la css afin d’avoir toutes les pages aux couleurs du projet, c’est toujours plus agréable pour travailler. Pour éviter de surcharger cet article, si vous voulez voir le détail complet du travail de mise en forme, reportez vous au GitHub du projet.

Debriefing

Voilà un bon démarrage pour notre plateforme de musique. Le projet est lancé et nous pouvons travailler dans de bonnes conditions pour la suite. L’état du product backlog :

En tant que … je peux déjà …
administrateur créer des comptes utilisateurs (administrateurs et membres)
internaute m’enregistrer pour obtenir un compte membre

Notre projet est déjà livrable en production avec ces fonctionnalités.

A bientôt pour le prochain épisode :

En tant que … je pourrai …
membre voir et mettre à jour mon profil utilisateur
membre créer des groupes de musique
membre modifier/supprimer les groupes de musique que j’ai créé
membre créer/modifier/supprimer des albums liés à mes groupes

Ressources

Published by

Publié par Aurélien Maury

Aurélien est passionné par les frameworks web haute productivité comme Grails, JRuby on Rails ou Play! framework. Il est également intéressé par tous les aspects de performance et d'optimisation (mais aussi par la phytothérapie, la PNL, la basse électrique, la philosophie et pleins d'autres sujets). Il est également formateur au sein de Xebia Training .

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.