Voici la suite de mon article au sujet de Grails.
Me revoilà donc devant la présentation de Grails par Jason Rudolph mais cette fois je suis armé et je sais de quoi on parle.
Nous sommes au QCon de San Francisco en 2007 et Jason présente Grails. La présentation contient quelques minutes de slides et le reste de l’heure est uniquement du code en live.
Heureusement que j’ai regardé les screencasts du site officiel de Grails car malheureusement la vidéo d’InfoQ n’est pas de très bonne qualité. L’intérêt de la présentation réside donc dans le fait que Jason construit petit à petit une application web et explique ce qu’il appelle “Convention over Configuration“. Ce paradigme est à la base de Grails et explique pourquoi le développement est simplifié au maximum.
Le principe est simple, Grails assume que vous allez construire votre application de manière conventionnelle. C’est à dire que vous aurez des objets métiers (Domain Class), des DAO (Controllers pour ajouter/supprimer/modifier les objets métiers), des Services pour ajouter des … services (!) particuliers (envoi de mails par exemple). Vous remarquerez que pour l’instant nous sommes dans une approche classique de développement d’une application web et c’est pour cela que Grails va vous simplifier la vie. C’est comme si Grails savait à l’avance ce que vous vouliez faire, et vous n’avez qu’à construire votre application sans vous soucier de la configuration et de l’emboitement des composants
L’exemple de base : Vous souhaitez créer une application de saisie de fiches DVD pour gérer votre vidéothèque.
Réfléchissez-y deux secondes et pensez à ce qu’il va falloir faire (une base de données, un IDE, des frameworks, un serveur d’application). Disons qu’on va faire des JSP, du Spring et de la persistance avec Hibernate. Après avoir configuré le tout, il va falloir coder les JSP, les objets métiers, mapper les classes pour la persistance, coder les DAO, coder les services métiers … Mais tout ceci est conventionnel et a déjà été fait maintes et maintes fois d’une manière plus ou moins équivalente à chaque fois.
Et bien dans ce cas, Grails peut vous simplifier la vie. Tout d’abord lors de la création d’un projet Grails, une hiérarchie de dossiers va être générée ainsi que la configuration de base (Serveur Bdd, Serveur JEE, Spring, …). Ensuite vous allez générer votre classe FicheDVD puis générer son controller (DAO). Cela va créer automatiquement les formulaires Web CRUD complètement fonctionnels. On peut retoucher la CSS, ajouter des taglibs, télécharger des plugins, générer les tests unitaires …
Il suffit de regarder les vidéos pour s’en convaincre, il ne suffit que quelques minutes (<10mn) pour arriver à ce résultat. Pourquoi? Parce Grails est fait pour ça!
Pour finir, deux liens : le site de Jason Rudolph, son blog et son livre “Getting Started With Grails” qui est gratuit (après enregistrement sur InfoQ.com).
Hé bien, après avoir lu le premier article, je me suis dis que c’était encore un truc tape à l’œil qui générait pleins de codes sans que l’on aie à comprendre quoi que ce soit.
Après cet article et un visionnage rapide de la vidéo, ça m’a toujours l’air d’être un truc qui génère pleins de code sans que l’on aie à comprendre.
Mais ça m’a l’air puissant est très pratique. Sans même avoir téléchargé ou lu quoi que ce soit de plus que tes articles j’ai deux remarques/questions à te faire :
1° Grails me semble être un peu comme un ORM; c’est un outil génial qui nous fais gagner du temps et de l’abstraction sur certains points répétitifs mais qui n’est pas à mettre dans les mains de tout le monde, pour bine l’utiliser il faut surement comprendre et maitriser ce qui est fait derrière.
2° Comme dans beaucoup de Frameworks, on gagne beaucoup de temps pour faire des choses communes mais lorsque l’on dois développer certains choses plus évoluées on passe bien plus de temps que si l’on était resté sans Frameworks. Est-ce le cas pour Grails, peut-on aisément reprendre la main sur ce qu’il à généré pour coder des choses bien trop complexes (patch sur un hack pour tenter de supporter plus ou moins l’ancien système de gestion de stocks écris par le fils de la secrétaire qui s’y connais un peu dans les ordinateurs) ?
Je suis entièrement d’accord avec toi sur les 2 points que tu soulèves.
En fait, je pense qu’il faut considérer Grails comme un outil utile dans un cas de prototypage rapide d’applications ou pour de petites applications perso ou à faible fréquentation.
Sincèrement, pour se faire une appli J2EE perso, je me vois mal ressortir les gros outils et me palucher le tout à la main.