Le Touilleur Express » grails

Grails étape 3 : Bootstrap, XML, JSON, Ajax et création d’un GTag

Nicolas Martignole — Wed, 30 Dec 2009 22:39:06 +0000

3ème et dernier article sur Grails après une prise en main et la réalisation d’un écran complet, nous allons voir comment créer un tag pour Grails et comment mettre en place Ajax. En bonus et pour débuter je vais vous montrer aussi quelques fonctionnalités de Grails : le Bootstraping et les fonctions orientées REST pour afficher la liste des Contacts au format XML ou JSON en quelques minutes.

Bootstrapping

Avant tout, vous pouvez télécharger le code source de la partie 2 si vous ne l’avez pas déjà fait. Avez-vous remarqué qu’à chaque démarrage de l’application, il n’y a aucuns contacts ? C’est un peu gênant car il faut créer quelques Contacts pour voir la liste s’afficher. Grails en mode développement utilise une base de données en mémoire qui n’est pas persistée. A chaque démarrage il est donc normal que la liste des Contacts soit vide.

Pour créer quelques enregistrements, ouvrez le fichier /grails-app/conf/BootStrap.groovy. Ce script est exécuté lors du démarrage. Nous allons créer quelques Contacts afin de tester. Rien de plus simple avec Grails, et vous verrez qu’il n’y a pas besoin de services, tout est livré sur l’entité Contact. Voici comment ajouter les contacts : dans la méthode init, créer un nouveau Contact :

class BootStrap {
     def init = { servletContext ->
          def nm = new Contact(prenom: "Nicolas", nom: "Martignole", dateNaissance: new Date()-120, email: "nicolas@test.fr")
          nm.save()

     }
     def destroy = {
     }
}

En Groovy il est possible d’utiliser ce que l’on appelle des arguments nommés. Franchement, vous ne trouvez pas cela plus clair que la version Java ? Là les paramètres sont clairement exprimés, sans ambiguïté. Notez aussi au passage qu’il est possible de retirer 120 jours à la date courante, car une Date en Groovy est facilement manipulable. C’est de la surcharge d’opérateur comme au bon vieux temps du C++.

Si vous arrêtez et vous relancez le serveur, vous devriez voir maintenant que votre liste d’utilisateur s’est remplie :

Je vous laisse ajouter quelques utilisateurs, vous avez compris le principe.

Sur votre version de production, il faudra ajouter un test afin de vérifier si l’application est en mode développement ou en mode production. Sans cela, ces entrées seront créées à chaque démarrage. Si vous voulez simplifier la saisie de la date de naissance, vous pouvez modifier la class Contact afin de rendre la date de naissance optionnel avec l’option nullable=true et retirer la contrainte max que j’avais placé dans la première version. Cela permettra de créer rapidement quelques enregistrements pour tester.

La class Contact modifiée :

package org.letouilleur.demo

class Contact {
	String nom
	String prenom
	Date dateNaissance
	String email

	static constraints={
		prenom(blank:false)
		nom(blank:false)
		dateNaissance(nullable:true)
		email(email:true,nullable:true,blank:true,unique:true)
	}
}

Voici mon fichier Bootstrap final :

import org.letouilleur.demo.Contact
import javax.servlet.ServletContext

/**
 * Script de demarrage
 */
class BootStrap {

  def init = {ServletContext ctx ->

    environments {
      production {

        ctx.setAttribute("env", "prod")
      }
      development {
        createTestEntries()
        ctx.setAttribute("env", "dev")
      }
    }

  }

  def destroy = {
  }

  // Cette methode est appele uniquement en mode developpement afin de creer des Contacts

  void createTestEntries() {
    def nm = new Contact(prenom: "Nicolas", nom: "Martignole", dateNaissance: new Date() - 120, email: "nicolas@test.fr")
    nm.save()

    // Permet de verifier que le Contact est bien stocke ou non
    def c = new Contact(prenom: "Paul", nom: "Gontran", dateNaissance: new Date(), email: "paul@toto.fr")
    c.save()
    if (c.hasErrors())
      println c.errors

    new Contact(prenom: "Georges", nom: "Lucas", dateNaissance: new Date() - 1, email: "lucas@star.fr").save(failOnError: true)
    new Contact(prenom: "Gregory", nom: "Madisson", dateNaissance: new Date() - 3, email: "mads@son.com").save()
    new Contact(prenom: "Jonathan", nom: "Lalou", dateNaissance: new Date() - 2, email: "john@lecowboy.fr").save()
    new Contact(prenom: "Katherine", nom: "Grah", dateNaissance: new Date() - 3, email: "kat@noop.fr").save()
    new Contact(prenom: "Amelie", nom: "Blou", dateNaissance: new Date() - 56, email: "amelie@noop.fr").save()
    new Contact(prenom: "Anatole", nom: "Ducib", dateNaissance: new Date() - 23, email: "am@noop.fr").save()
    new Contact(prenom: "Kim", nom: "ProdMan", dateNaissance: new Date() - 4, email: "kim@noop.fr").save()
    new Contact(prenom: "David", nom: "CeChau", dateNaissance: new Date() - 91, email: "david@noop.fr").save()
    new Contact(prenom: "Pierre", nom: "Henry", dateNaissance: new Date() - 3, email: "pierre@noop.fr").save()
    new Contact(prenom: "Andre", nom: "Magphone", email: "ant@noop.fr").save()
  }
}

Générer une liste au format XML ou JSON
Certaines fonctions de Grails sont vraiment sympas. Nous allons voir comment retourner la liste des contacts au format XML simple, au format avancé et enfin au format JSON. Pour cela, éditez ContactController. Vous savez maintenant que pour déclarer une nouvelle action, il suffit de créer une méthode. Grails rend accessible cette méthode sans même qu’il ne soit nécessaire de relancer le serveur. Essayez d’ajouter ces quelques lignes à la fin de votre fichier :

  def listAsXml = {
    def newList = Contact.listOrderByNom()
    render newList as grails.converters.XML
  }

Si vous regardez maintenant la page http://localhost:8080/zencontactdemo/contact/listAsXml vous verrez que Grails génère une liste triée par nom de famille des Contacts.

Grails propose les Converters. Il en existe 4 par défaut (voir la doc dans une autre fenêtre). Les converters « deep » gérent les associations, les relations alors que les 2 autres Converters ne rendent pas les feuilles. Ici Contact n’ayant aucunes relations, j’utilise le Converter par défaut.

Il est aussi possible de générer un fichier XML très facilement par exemple:


def converter = Contact.list() as XML
converter.render(new java.io.FileWriter("/path/to/my/file.xml"));

Générer la liste des Contacts au format JSON
Le converter JSON par défaut gére en plus très bien l’encoding au format UTF-8 des entités, ce qui nous permettra de gérer sans soucis les accents par exemple :

import grails.converters.JSON
class ContactController {
..
...

 def listAsJson = {
    def newList = Contact.listOrderByNom()
    render newList as JSON
  }

Ce qui donne

[{"class":"org.letouilleur.demo.Contact","id":7,"prenom":"Amelie","dateNaissance":"2009-11-04T18:12:31Z","email":"amelie@noop.fr","nom":"Blou"},{"class":"org.letouilleur.demo.Contact","id":6,"prenom":"Katherine","dateNaissance":"2009-12-27T18:12:31Z","email":"kat@noop.fr","nom":"Blou"},
...
etc.

Un seul enregistrement au format XML
Enfin si vous ne voulez retourner qu'un seul enregistrement, cela ne poste pas plus de problèmes. Voici une méthode showAsXml qui affichera un seul des enregistrements. Il suffit de passer l'id en argument.


  def showAsXml = {
    def contactInstance = Contact.get(params.id)
    if (!contactInstance) {
      flash.message = "${message(code: 'default.not.found.message', args: [message(code: 'contact.label', default: 'Contact'), params.id])}"
      redirect(action: "list")
    }
    else {
       render contactInstance as XML
    }
  }

Et pour tester cette méthode (toujours sans relancer Grails) ouvrez par exemple cette URL :
http://localhost:8080/zencontactdemo/contact/showAsXml?id=7

Voilà, vous savez maintenant que Grails peut exposer facilement au format XML ou JSON des entités.

Le tag editInLine

Là nous attaquons une partie un peu plus compliquée. Dans le cahier des charges de Zenika, il faut mettre en place une fonction d’édition du nom de famille en Ajax, en utilisant la fonction Ajax.InPlaceEditor de la librairie Javascript Scriptaculous. J’ai un peu cherché mais il ne semble pas qu’il existe de tag Grails pour faire cela. Pas de plugins non plus. Enfin cela tombe bien, l’objectif est de vous montrer comment écrire ce tag.
Mais avant cela, voici une petite vidéo du résultat final, de ce que vous allez coder dans un instant (désolé si vous n’avez pas Quicktime) :

Pour réaliser cela voici ce que nous allons faire:
- créer un tag personnalisé dans la class ToolsTagLib
- modifier le fichier list.gsp pour utiliser ce tag
- ajouter une méthode dans ContactController pour sauver le changement de nom
- ajouter une page gsp pour afficher en gras le nom édité

Le tout sans relancer le serveur.

Avant tout, vérifiez bien que le fichier grails-app/views/layout/main.gsp contient bien la déclaration de la librairie Prototype et de la librairie Scriptaculous.



  <g:layoutTitle default="Zencontact"/>

Création d’un tag personnalisé
Lors du premier atelier nous avons créé une class ToolsTagLib.groovy dans le répertoire grails-app/taglib. Nous allons ajouter une nouvelle méthode dans cette classe afin de créer un tag editInPlace pour Grails. J’ai décidé que ce tag prendrait quelques arguments. Dans la page list.gsp, remplacez la ligne suivante utilisée lors de l’affichage du nom du contact par le code suivant :

Dans grails-app/views/contact/list.gsp 

effacez la ligne
 ${fieldValue(bean: contactInstance, field: "nom")}

et remplacez par :

Notre tag prend plusieurs arguments. L’id du contact édité, l’action à appeler sur le controlleur, le nom de celui-ci, le nom du parametre initial et enfin la valeur à afficher lors du chargement de la page.

Je vous donne le code du tag, avant de l’expliquer. C’est pas très simple, j’y ai passé une bonne demie heure le temps de le tester et de trouver comment récupérer les paramètres facilement :

def editInPlace = {attrs, body ->
    def id = attrs.remove('id')
    def initialVal = attrs.remove('initialValue')

    out << ""
    out << initialVal
    out << ""

    out << ""
  }

Ligne 2 et 3 : je retire les parametres passés en argument du tag dans la page GSP et je les stocke dans des variables
Ligne 13: j’utilise la fonction createLink de Grails qui est présente par défaut pour créer un lien
Ligne 17: je précise aussi le nom du parametre

Le tout repose sur la fonction Ajax.InPlaceEditor qui permet facilement de gérer l’édition. C’est cette même librairie qui est utilisée dans la version de Zenika. Exactement la même. La différence étant que là, au lieu d’avoir un composant, je dois coder un tag.

Modification de la page list.gsp
Editez et vérifiez que la page list.gsp utilise maintenant votre tag. Nous avons maintenant la version finale de cette page. Regardez attentivement le code, c’est relativement simple.



  
  
  
  <g:message code="default.list.label" args="[entityName]"/>





  
    ${flash.message}
  

  Sur cette page vous pouvez éditer une fiche, ajouter rapidement un nouvel utilisateur avec un formulaire Ajax. Nous
  montrons aussi comment il est possible d'inclure une autre vue dans la vue active sans ajouter une ligne de code
  au controleur.
  Vous pouvez éditer directement le nom de famille d'un utilisateur en cliquant sur son nom grâce à la librairie Scriptaculous.

  
    
      ' alt="icon"/>
      ${contactInstance.prenom}

Nous retrouvons bien notre tag à la ligne 27, et aussi ce que nous avions préparé dans l’article précedent. Il ne manque plus que l’édition avec le formulaire Ajax et nous aurons terminé.

Ajout d’une méthode pour sauver le nouveau nom
Si vous testez le code à cet instant, vous verrez que cela marche pas. Le nom de famille n’est pas persisté. Il manque encore 2 choses : une méthode dans ContactController et une vue GSP. Le nom de la méthode appelée par le code Ajax.EditInPlace a été passé en argument : inlineEdit. Il faut donc créer cette méthode et ensuite une vue inlineEdit.gsp pour terminer cette partie. Voici la nouvelle méthode à ajouter à la fin de ContactController :

def inlineEdit = {
    def contactInstance = Contact.get(params.id)
    if (!contactInstance) {
      flash.message = "${message(code: 'default.not.found.message', args: [message(code: 'contact.label', default: 'Contact'), params.id])}"
      redirect(action: "list")
    }
    else {
      contactInstance.nom=params.nom
      contactInstance.save()
      return [contactInstance: contactInstance]
    }
  }

Retenez que seul la ligne 8 est intéressante : nous modifions le nom de l’entité chargée et nous la sauvons ensuite.

Il ne reste plus qu’à ajouter un fichier inlineEdit.gsp dans le répertoire grails-app/views/contact avec cette seule et unique ligne:

// Une seule ligne
${contactInstance.nom}

Une seule ligne car cette page est rendue… via Ajax. Il n’y a rien d’autres à ajouter.

Voilà c’est terminé pour l’édition. Regardez la vidéo complète à la fin de cet article si vous souhaitez faire une pause avant la dernière partie.

Dernière modification : le formulaire de saisie rapide Ajax
Tout d’abord nous allons modifier la vue contact.gsp car nous n’avons pas encore activé de datePicker. Et comme la vue create est utilisée aussi dans la vue list, autant faire d’une pierre, deux coups. Pour le datePicker nous avons l’embarras du choix car il existe plusieurs plugins Grails. J’ai pris le plugin « Calendar« . Allons-y, il y en a pour 3 minutes. Tout d’abord installons le plugin

grails install-plugin calendar

Voici la version finale de la page create.gsp avec la mise en page de la version Wicket de Zenika :

<%@ page import="org.letouilleur.demo.Contact" %>


  
  
  
  <g:message code="default.create.label" args="[entityName]"/>
  




  
    ${flash.message}

Ligne 8 : cette déclaration permet de charger les ressources javascript nécessaires au plugin calendar.
Ligne 48: utilisation du datePicker

Si vous rechargez maintenant la page de création nous avons un datePicker en bonne et due forme. De même pour la page qui liste les contacts car celle-ci importe la page create.gsp.

Passons maintenant à l’ajout du formulaire de saisie rapide à proprement parler.

Grails fournit un support d’AJAX très puissant et simple à utiliser. La librairie des tags de base permet de réaliser rapidement des fonctions puissantes en Javascript, tout en assurant l’envers du décor avec les actions dans le Controller. En fait c’est tellement simple que vous n’aurez pas le temps de terminer votre café en lisant ce qui suit :

Dans list.gsp, ajoutez un nouveau formulaire basé sur le tag formRemote:


    
      ' alt="icon"/>
      ${contactInstance.prenom}

      
      

      
        
      
      

    
    
      
    



    
      Prénom : 
      Nom :

Ligne 1 : vous notez que j’ai nommé le DIV principal « updateMe » qui comme vous l’avez deviné… doit se rafraîchir dès qu’un contact est ajouté.
Ligne 21 : nom de l’action à appeler sur ContactController
Ligne 23 : nom du DIV à rappeler en cas de succès

Le reste du formulaire est tout à fait normal, il n’y a rien d’exceptionnel. Il ne reste plus qu’à ajouter une nouvelle action dans ContactController. Je vous laisse faire maintenant, vous savez comment faire :

 def saveQuickInput = {
    params.max = Math.min(params.max ? params.max.toInteger() : 10, 100)

    def contactInstance = new Contact(params)

    def existingUser = Contact.findByNomAndPrenom(params.nom, params.prenom)
    if (!existingUser) {

      contactInstance.save(flush: true)
      [contactInstanceList: Contact.listOrderByNom(params), user: contactInstance, contactInstanceTotal: Contact.count()]
    } else {
      [contactInstanceList: Contact.list(params), user: contactInstance, erreur: "Cet utilisateur existe déjà"]
    }
  }

Et enfin comme toute action, il nous faut une vue. Je dis cela, ce n’est pas tout à fait vrai. Il est possible d’appeler une autre vue et vous n’êtes pas obligé de créer un fichier GSP par action dans votre Controller. Pour terminer voici le contenu de la page qui sera affichée lorsque l’utilisateur aura saisi un nouveau Contact :


  ${erreur}  




  ${flash.message}



  ' alt="icon"/>

  
    
  
  ${contactInstance.prenom}

  
  

  
    
  

  
    
  
  



  



  ${erreur}

La pagination sur la page de résultat pose un souci : si vous créez un utilisateur appelé Bob Zorro par exemple, celui-ci sera affiché sur la 2ème page et vous ne le verrez pas tout de suite… Je pense que c’est un souci d’ergonomie plus que technique, donc nous n’en tiendrons pas compte ici.

Voilà c’est terminé. Nous avons maintenant aussi le formulaire de création rapide. Si vous avez tout suivi jusqu’ici… chapeau. Cet article est énorme à lire, et il doit tenir sur 12 pages. Je vous remercie si vous êtes encore là, car tout ceci peut vous sembler un peu indigeste.

Conclusion

Pour terminer voici une vidéo de l’application complète, avec une feuille de style adaptée, quelques améliorations sur la mise en page, mais le tout sans trucages, sans fil en nylon qui font bouger les tags sur la page et en essayant de coller à l’esprit du projet de Zenika au plus juste. Pour les observateurs attentifs il y a un bug à un moment donné… je vous laisse regarder :

Alors Grails c’est mieux que Wicket ?
Il est temps de poser un peu le clavier et de porter une autocritique sur le projet. Là où j’ai clairement gagné du temps : sur tout ce qui est test, construction des actions et de la partie Controller. Là où j’ai bien passé 1 heure, c’est sur la création du tag personnalisé et sur la gestion de la partie Ajax. Pas compliqué, mais ne connaissant pas… j’ai un peu navigué dans la documentation de Grails pour boucler le tout. Je me demande combien de temps il me faudrait pour refaire le projet en partant de zéro, en connaissant ce qu’il y a à faire… Je dirai 1h00 je pense, en imaginant que je conserve le code du tag editInPlace quelque part. Le reste est faisable rapidement.

Dans vos commentaires vous me demandez si Grails est mieux que GWT. Ils ne sont pas comparables sur le plan de la création d’application. GWT est fait pour la création d’application riche du côté du navigateur. Je préfère comparer GWT à Flex. GWT vous laisse écrire la partie serveur avec la persistence gérée par un ORM comme Hibernate, et l’injection de dépendance gérée par Spring par exemple. Grails ne vous laisse pas mettre le nez dans cette partie, ce qui je pense doit avoir ses limites. Vous êtes tributaire des mises à jour des versions de Spring et d’Hibernate puisque celles-ci font parties intégrantes de Grails… D’un autre côté, je vois cela comme un avantage : Grails vous prépare une version qui marche des différentes librairies, et tant que vous n’avez pas un bug dans celle-ci, vous êtes tranquille.

Peut-on utiliser Grails en production ?
Oui. Souvenez-vous qu’à la fin, vous faîtes « grails war » et votre archive est prête à être déployée comme vous l’auriez construit à la main. SpringSource fournit aussi du support il me semble sur Grails d’après cette page mais difficile à dire.

Est-ce que Grails est réservé à des petites applications ou des maquettes ?
Je ne pense pas. Si je suis votre raisonement, dès que votre application devient « sérieuse » il vous faut Java EE 6 ? C’est pas un peu bête comme raisonnement ? Je suis certain que vous pensez que PHP c’est « pour des petits sites » et Python « c’est pour des gars qui n’aiment pas Java« .
Excusez-moi de vous parler franchement : va falloir sortir un peu mon garçon. La majorité des projets Webs aujourd’hui tournent sur du PHP. Python a des Closures depuis 2004 je crois là où nous, dans le monde Java, nous n’aurons rien avant fin 2010… Coluche disait : « JE ME MARRE ! »

Est-ce que Grails c’est vraiment de la balle et tu es prêt à mettre ton projet dessus ?
Un autre Nicolas m’a posé cette question. Est-ce que je suis prêt à risquer un projet, une entreprise en l’occurrence, sur ce framework ? Ma réponse est oui. Je limite le risque en prenant un outil qui me donne un feedback plus rapidement qu’avec Java. Cela me permet de valider rapidement ou non des idées. Et dans le cadre d’une start-up où vous devez trouver des idées, je suis vraiment content de ce choix. Je commence à voir les limites de Grails, mais aussi à voir les parties où il ne faut pas hésiter à se servir deux fois.

Et Groovy ? Et la suite ?
Depuis mi-2009 j’ai changé. Je dirai presque que j’ai muri : je sens de moins en moins l’option « Java seul contre le reste du monde« . Je pense qu’il est intéressant pour vous de commencer à apprendre Scala ou Groovy en ce moment, bref n’importe quel langage qui tourne sur la JVM.
La force de Java ce n’est plus le langage. C’est la communauté, c’est les projets open-sources de qualité et c’est la machine virtuelle.

Play! ou Grails ?
Ben j’en sais trop rien… Je dirai que je préfère Grails à cause de Groovy. Play! m’a semblé proche de Grails, et rejoint la famille des frameworks Webs Hyper-productifs qui écrasent gentiment les frameworks orientés composants comme JSF pour n’en citer qu’un. C’est mon avis très personnel, et souvenez-vous que je portais aux louanges JSF 1.2 il y a 2 ou 3 ans. A mon avis, le ticket d’entrée avec Play! doit être moins élevé.
Souvenez-vous de la différence entre apprendre à faire du Ski Alpin et apprendre à faire du Snowboard. Grails c’est plutôt du Ski : tu vas bien galérer au début, là où Play! c’est ton pote Java avec donc le bénéfice de toutes les librairies qui existent déjà… Peut-être que tu risques de te faire moins mal ?

Il faudrait confronter les deux frameworks. Alors je vais lancer un appel solennel :
Si quelqu’un de l’équipe Play! lit cet article, ça ne vous dit pas de faire votre version du projet de Zenika ?

Là on aura une idée plus précise je pense.

Voilà j’espère que cette série d’articles vous aura donné une idée de ce que l’on peut faire avec Grails 1.2.

Je vous proposerai d’autres articles sur les sujets que j’ai découvert ces derniers mois, il y a de quoi se chauffer cet hiver.

Code du projet

Vous pouvez télécharger le code source de la version finale :
grails_final_touilleurexpress.tar.gz

Grails étape 2: itérer une collection et afficher le résultat

Nicolas Martignole — Tue, 29 Dec 2009 20:54:28 +0000

Les fêtes sont passées, voici la deuxième partie de mon article sur Grails consacrée à l’écriture de l’application Zencontact. Dans le premier article j’ai expliqué comment installer Grails et débuter son projet. Figurez-vous que depuis ce dernier article, j’ai trouvé comment utiliser les 2 librairies Prototype et Scriptaculous. Parfois il faut juste chercher un peu… Bref la version 2 est plus proche du cahier des charges de Zenika. Il ne manque presque rien je pense pour remplir le cahier des charges.

Aujourd’hui au programme :
- comment mettre à jour sa version de Grails ?
- Itérer une collection et afficher les résultats

Mettre à jour son application vers une nouvelle version de Grails
Pendant le break de la semaine de Noël, l’équipe de Grails a annoncé la sortie de la version 1.2 du framework Grails. C’est parfait, cela va me permettre de vous montrer comment mettre à jour votre version de Grails, ainsi que notre projet zencontact.
- Renommez votre ancien répertoire C:\grails en C:\grails-old par exemple
- Téléchargez et décompressez Grails 1.2 dans le répertoire C:\grails
- Téléchargez le projet de démarrage pour cet article, qui a été allégé depuis la version 1 via ce lien : grails_zencontactdemo_debut_article2.tar.gz
- Placez-vous à la racine du projet zencontactdemo après avoir décompressé l’archive
- Tapez simplement grails upgrade
- Faites aussi le ménage avec grails clean avant de relancer le serveur avec grails run-app afin de tester la mise à jour

Le script de mise à jour de Grails démarre. Nous pouvons constater que la version utilisée est bien la 1.2. Suivez les instructions, en principe cela ne devrait pas poser de problèmes.

macbook-pro-de-nicolas-martignole:zencontactdemo nicolas$ grails upgrade
Welcome to Grails 1.2.0 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: /Users/nicolas/Dev/grails/grails

Base Directory: /Users/nicolas/Dev/Zenika/zencontactdemo/zencontactdemo
Resolving dependencies...
Dependencies resolved in 1502ms.
Running script /Users/nicolas/Dev/grails/grails/scripts/Upgrade.groovy
Environment set to development
NOTE: Your application currently expects grails version [1.2-M4], this target will upgrade it to Grails 1.2.0 ...

		WARNING: This target will upgrade an older Grails application to 1.2.0.
		However, tag libraries provided by earlier versions of Grails found in grails-app/taglib will be removed.
		The target will not, however, delete tag libraries developed by yourself.
		Are you sure you want to continue?
				    (y, n)

Lors du premier redémarrage, vous verrez que Grails met aussi à jour les Plugins, ce qui peut parfois poser des soucis avec les versions « beta ». Mais ici, s’agissant de la version 1.2 il n’y aura aucuns soucis.

Les améliorations de la version 1.2 de Grails
La release notes de la version 1.2 est longue comme un guide d’installation de Windows. Cette version a été optimisée pour les performances. Spring 3.0 est utilisé par Grails et devient aussi utilisable pour votre code. N’importe quelle classe (java ou groovy) peut donc être annotée avec @Component afin d’être injectée dans une autre classe. Concernant la gestion des transactions, il est possible de définir un niveau de granularité plus bas pour les transactions, là où auparavant, l’ensemble d’un service Grails était transactionnel ou non. GORM est aussi configurable avec un ensemble de règle par défaut. J’aime beaucoup les nouveaux finders dynamiques qui traitent les Booleans. Enfin le support des requêtes nommées (named queries) la possibilité de faire des mappins « hasOne », la liste est longue.
Attention dans la version 1.2, WebFlow est maintenant un plugin à part qu’il faut installer. Il n’est plus livré par défaut. Basé sur Spring WebFlow, ce plugin est très pratique pour faire des questionnaires, des wizards, des formulaires multi-écrans.
Je pourrai écrire un article complet sur cette nouvelle version, mais croyez-moi, c’est une version très mature et très complète. Je dis cela pour les chagrineurs qui attendent que « Grails soit stable« .

Scriptaculous et Prototype sur la même page
Avec la version 1.2 il est possible d’utiliser les 2 librairies Javascript Prototype et Scriptaculous sans soucis. Il suffit de les déclarer à la suite dans notre fichier main.gsp qui sert de template pour Sitemesh:



  <g:layoutTitle default="Zencontact"/>
  
  
  

  
  




  Accueil |
  Liste des contacts |
  Ajouter un contact



  
    
      
    
  


  Le Touilleur Express Copyright© 2009-2010

La version de l’article 1
A la fin de l’article 1 il était possible de créer un contact, de le lister, et d’afficher l’heure sur la page d’accueil. Pour vous montrer maintenant une nouvelle version, j’ai préparé une archive du code source du début de l’étape 2.
- Téléchargez le fichier grails_zencontactdemo_debut_article2.tar.gz
- Décompressez-le dans un nouveau répertoire et lancez l’application.

Comme je vous sens un peu fatigué après les fêtes je vous ai fait une vidéo avec ma belle voix que vous pouvez regarder en buvant une tisane (par exemple)

Itérer une collection
Comment itérer une collection et afficher le résultat ? Plus clairement, nous devons lister les contacts et les afficher sur une page. Voyons comment cela fonctionne. Tout d’abord, souvenez-vous, nous utilisons une class Controller avec Grails. Tout se passe dans l’unique class ContactController.groovy.
Pour récupérer la liste des contacts, nous utilisons un « finder ». C’est une méthode statique qui est déclaré sur la classe Contact et qui permet à Grails de vous câbler tout cela sans aucuns efforts. Voici quelques exemples pour expliquer ce principe. Sachez qu’avec IDEA IntelliJ, celui-ci est capable de vous proposer via l’auto-complétion des méthodes, ce qui aide pas mal lorsque vous codez.

// Pour obtenir la liste des Contact
def myList = Contact.list()

// Pour obtenir la liste des utilisateurs dont le nom de famille est Martin
def myList = Contact.findAllByNom("Martin")

// Qui ressemble à Mar
def myList = Contact.findAllByNomLike("Ma%")

// Seulement le premier trouvé
def c1 = Contact.findByNomLike("Ma%")

// Trouve toutes les personnes dont la date de naissance
// est inférieur à la date d'aujourd'hui
def myList=Contact.findAllByDateNaissanceLessThan(new Date())

// Combine 2 attributs pr la recherche
def nicolas=Contact.findByNomAndPrenom("nicolas","martignole")

Que pensez-vous de tout cela ? Pas mal non ? Imaginez que le tout devient des requêtes avec Spring et Hibernate. Il est possible de combiner 2 attributs de la classe Contact au maximum comme sur le dernier exemple. J’adore Grails car c’est précisément ce genre d’astuces qui font gagner du temps.

Pour vous expliquer comment construire la liste des contacts, nous allons casser un peu de code. Reprenez le fichier ContactController. Effacez pour l’instant tout ce qui se trouve dans la méthode list() et utilisez ce que vous venez de voir pour créer un objet myList. Comme vous pouvez le constater, on se fiche pas mal du type ici, à savoir un List. Pour retourner un objet à la vue, il suffit de le placer dans une Map, ce que je fais avec ces crochets à la fin de la méthode. Il n’y a pas de return car la dernière expression évaluée avec Grails est automatiquement retournée. La clé sera « contactInstanceList » et la valeur sera « myList ».

package org.letouilleur.demo

class ContactController {

  static allowedMethods = [save: "POST", update: "POST", delete: "POST"]

  def index = {
    redirect(uri: '/')
  }

  def list = {
    // Recupere la liste des contacts
    def myList=Contact.list()

    // place dans une Map cette liste avec la cle contactInstanceList
    [contactInstanceList: myList]
  }
...

Convention au lieu de configuration : pour afficher le résultat il suffit de créer un fichier list.gsp dans le répertoire views/contact. Ce fichier sera automatiquement appelé par Grails à la fin de l’exécution de la méthode list. Nous allons donc récupérer une liste de Contacts. Pour itérer cette collection du côté de la vue, nous utiliserons le tag . Ce tag prend en argument une collection, et vous retourne une variable qu’il suffit d’utiliser. L’attribut status est un compteur très pratique lorsque vous souhaitez afficher une ligne sur deux dans un tableau avec une autre couleur. Il est possible d’utiliser le tag fieldValue ou directement le nom du curseur (ici contactInstanceList) et d’appeler l’attribut qui vous intéresse.


    // version 1
    ${fieldValue(bean: contactInstance, field: "prenom")}
    // version 2 (voir explication)
   ${contactInstance?.nom}

Vous voyez ce point d’interrogation à la ligne 7 ?
C’est un pattern de Groovy appelé Safe Dereferencing qui dit en quelque sorte : « …si tu as une valeur pour contactInstance alors appelle getNom() sinon ne fait rien« . C’est un moyen de gérer les valeurs nulles sans if/then/else supplémentaire.

Voilà comment afficher une collection : appeler l’un des finders, retourner la liste vers la vue et itérer la collection avec un curseur. Pour terminer nous allons afficher les noms des utilisateurs par ordre alphabétique. C’est très simple, il suffit d’utiliser le finder adéquat :

 def list = {
    // Recupere la liste des contacts triee par Nom
    def myList=Contact.listOrderByNom()

    // place dans une Map cette liste avec la cle contactInstanceList
    [contactInstanceList: myList]
  }

Voilà je vous laisse souffler et imaginez ce qu’il faudrait faire en Java avec du Spring et un peu d’Hibernate… Ce que j’aime dans Grails c’est que si vous voulez tester quelque chose rapidement, c’est faisable.

Paginer nos 102020 enregistrements sans pleurer
Tant qu’à faire, nous allons aussi préparer de quoi gérer la pagination. Imaginez que la base de données contienne beaucoup d’enregistrements. Il serait souhaitable de limiter le nombre d’enregistrement retournés et de paginer les résultats non ? Tout d’abord nous ajoutons le tag paginate dans le fichier list.gsp après le tag g:each. Ce tag va générer automatiquement les liens de navigation, le nombre de pages, bref toute l’artillerie nécessaire pour naviguer dans la liste des résultats. Si ce tag ne vous plaît pas, n’oubliez pas que vous pouvez créer le vôtre.
Pour l’instant on note l’apparition d’un nouveau paramètre appelé contactInstanceTotal dans la vue :


    // version 1
    ${fieldValue(bean: contactInstance, field: "prenom")}
    // version 2 (voir explication)
   ${contactInstance?.nom}

Je modifie maintenant le code du Controller afin de gérer la pagination. Il est intéressant de vous expliquer en détail ce qui se passe dans ces 2 lignes car nous avons là plusieurs notions qui n’existent pas en Java, et qui viennent du monde de Groovy.

  def list = {
    params.max = Math.min(params.max ? params.max.toInteger() : 10, 100)
    [contactInstanceList: Contact.listOrderByNom(params), contactInstanceTotal: Contact.count()]
  }

Tout d’abord les paramètres de la requête HTTP (GET ou POST) sont automatiquement placés dans une Map appelé params.
Vous pouvez écrire params.get(« max ») ou directement params.max afin de récupérer la valeur d’un paramètre HTTP.

params.max

Ensuite vous reconnaissez l’opérateur ternaire du monde java qui dit « si le parametre max est spécifié alors prendre sa valeur en le transformant en un Interger, sinon prend 10 »

params.max ? params.max.toInteger() : 10

Cela me permet de vous donner un petit cours de Groovy et de vous parler de l’opérateur Elvis. L’opérateur Elvis comme en Java est un opérateur ternaire (If… then… else…) qui se lit de cette façon :

 ?  :

Si la condition est vraie alors l’opérateur 1 est évalué, sinon ce sera l’opérateur 2. Nous pourrions par exemple écrire en Java ce bout de code qui affecte le nom de la personne :


String name = (person.getName() != null) ? person.getName() : "unknown"

Groovy étant capable de simplifier cela, un nouvel opérateur noté ?: permet de raccourcir cette expression simplement :


// groovy
def name = person.getName() ?: "unknown"

L’opérateur Elvis en Groovy retourne le contenu de ce qu’il a sur la tête (à gauche) si cette expression est vraie, sinon ce qu’il a en dessous (à droite).

Reprenons les quelques lignes de la méthode list de ContactController :


  def list = {
    params.max = Math.min(params.max ? params.max.toInteger() : 10, 100)
    [contactInstanceList: Contact.listOrderByNom(params), contactInstanceTotal: Contact.count()]
  }

La première ligne s’assure que le paramètre max existe et qu’il est dans une plage de valeur authorisée. La seconde ligne passe directement la map « params » à la méthode listOrderByNom. Grails utilise à mort ce principe de convention au lieu de la configuration. Il se trouve que cette méthode listXXX recherche automatiquement une clé « max » pour toute Map que vous lui passez en argument… Là je reconnais qu’il faut lire la documentation pour le savoir. Nous perdons en expressivité ce que l’on gagne en raccourci. Bref ce paramètre max va permettre de limiter le nombre d’enregistrements retournés. Enfin pour initialiser le nombre de contacts, nous utilisons la méthode count qui se charge de vous donner le nombre de contacts en base. C’est simple non ?

Faire un lien vers une autre page (méga super dur)
Bon quoi d’autre ? Il faut afficher une image devant chaque contact et créer un lien sur une image afin d’aller vers la page édition lorsque la personne clique dessus. Voici tout d’abord le code partiel de la page list.gsp :

// Iteration sur la liste des contacts tries par nom

     ' alt="icon"/>
     ${contactInstance.prenom}
     ${contactInstance.nom}

Ligne 5 : chargement d’une image
Ligne 9 : utilisation du tag g:link. Nous allons appeler la méthode show du controleur ContactController. A noter que vous pouvez spécifier un autre controleur, que vous pouvez passer des paramètres, etc. Ce tag est assez puissant, la documentation vous donnera un aperçu de ce qu’il est possible de faire facilement.
Ligne 14/15 et 16 nous retrouvons notre pagination avec une feuille de style pour l’affichage.

Dans le cahier des charges de Zenika il est demandé aussi d’utiliser une autre page et de l’inclure dans la page qui liste les contacts. Le tag g:include permet de spécifier le nom d’un controller et d’une action précise afin de charger la vue. Ligne 19 nous appelons l’action create de ContactController, et voilà c’est tout pour l’instant.

Reste à faire
Il reste maintenant 2 étapes compliquées :
- mettre en place l’édition « in-place » du nom de famille
- mettre en place un formulaire Ajax afin d’ajouter rapidement un nouvel utilisateur

Nous verrons dans le troisième article comment écrire un tag personnalisé et ensuite comment mettre en place un formulaire Ajax en 3mn top chrono.

A demain pour la suite !

Grails : l’application Zencontact de Zenika

Nicolas Martignole — Sun, 20 Dec 2009 22:36:56 +0000

Le 10 mars 2009, Zenika a présenté Apache Wicket au Paris JUG. Carl Azoury et Nicolas André ont construit en une heure une application de gestion simple, avec des fonctionnalités avancées en Ajax. L’objet de l’article c’est de vous montrer, vidéo à l’appui, comment construire la même application avec Grails. Le gros plus : je vais réellement persister mes Contacts en base, sans efforts supplémentaires, là où la version Wicket s’arrête à la partie Web, sans la partie persistance de l’application.

Le cahier des charges proposé par Zenika est très clair, vous pouvez retrouver à cette adresse la liste détaillée des fonctions à coder.

Le résultat final
Voici la liste du cahier des charges. Pour chaque élément j’ai mis en italique les points inutiles pour Grails et en rouge les fonctions que je n’ai pas développé.
* La navigation entre pages
* L’organisation d’une structure commune des pages (Type Tiles / Sitemesh)
* La désactivation du lien correspondant à la page courante
* L’édition d’un contact
* La création d’un contact
* Lister les contacts
* L’ajout rapide d’un contact dans une liste
* Le refresh de la date courante via appels Ajax
* L’édition « in place » d’un libellé sans passer par un écran d’édition
* L’ajout de la validation (Nom et prénom obligatoires, contrôle du format date, contrôle du type email)
* Utilisation d’un date picker
* Synchronisation du format du DatePicker avec le format utilisé par le convertisseur
* Ajout des mêmes contrôles de validation côté client, en Javascript
* Gestion de la problématique du refresh afin d’éviter la double soumission
* Non duplication du code du formulaire… le même composant doit être utilisé pour la page d’édition de contacts et de liste des contacts
* Le drag & drop depuis la liste vers le formulaire d’édition (en fait même sur ma version Wicket cela ne marchait pas)
* L’affichage de message d’erreurs
* La réutilisation des mêmes messages d’erreurs en validation serveur et javascript
* Le tri de la liste des contacts par nom et par prénom

Le résultat final

Avant tout, voici une vidéo du résultat final.

Les fonctions non réalisées
Je n’ai pas codé la fonction qui désactive dans le menu du haut la page courante. Cela serait possible en codant un taglib dans Grails, mais ce n’est pas disponible par défaut.
Pour des raisons de problèmes Javascript, dans cette version j’ai créé 2 pages distinctes pour implémenter d’une part la saisie rapide et d’autre part l’édition inPlace. Une page utilise Scriptaculous, une autre page utilise Prototype. Il faut voir pourquoi lorsque j’ai les deux sur la même page cela ne fonctionne pas.
Enfin concernant la non-duplication du code, par défaut la pratique de Grails propose de créer une page gsp par action, ce que j’ai fait pour simplifier le code. Il est possible sinon de rappeler une vue. Sur ce point je n’ai pas bataillé.

Ce que fait cette application en plus
Tout d’abord, c’est une vraie application avec une base de données, Hibernate, Spring, bref tout ce que vous avez l’habitude d’utiliser. En version développeur, j’utilise une base en mémoire HSQLDB qui est effacé à chaque redémarrage. En mode production nous pouvons utiliser n’importe quelle base supportée par Hibernate.

L’application est constituée d’une entité Contact associé à un contrôleur en charge de tout ce qui est opération CRUD (Create, Research, Update et Delete).

Au total, voici le nombre de fichiers et de lignes de code de l’application :


    +----------------------+-------+-------+
    | Name                 | Files |  LOC  |
    +----------------------+-------+-------+
    | Controllers          |     2 |   121 |
    | Domain Classes       |     1 |    12 |
    | Tag Libraries        |     1 |    26 |
    +----------------------+-------+-------+
    | Totals               |     4 |   159 |
    +----------------------+-------+-------+

Grails n’a besoin que de 4 classes : une classe Contact pour le domaine, un controlleur et une Taglib Grails pour me simplifier la vie. Si je dresse un tableau de comparaison des 2 versions :

	Code	Pages	Fichiers de conf	JS	Lignes de code
Wicket	7 fichiers java	5 pages HTML	1 seul ds web.xml	Aucuns	237 lignes
Grails	4 fichiers groovy	13 fichiers GSP	6 fichiers	Aucuns	158 lignes

Grails est moins verbeux que la version Java. J’ai utilisé l’utilitaire CLOC en renommant les fichiers groovy en java, afin de regarder la quantité de code. Attention cependant : Grails génère des fichiers groovy de travail dans un répertoire caché et le nombre total de lignes de code est de 787 lignes. Mais si l’on regarde le nombre de lignes que l’on manipule, c’est bien 158 lignes. N’oubliez pas que l’application persiste réellement dans une base de données les Contacts.

Comment créer son application en 8 minutes ?
Assez parlé, il est temps peut-être de voir comment créer cette application. Tout compris, j’ai passé presque 2h30 pour réaliser l’ensemble de l’application. J’ai perdu beaucoup de temps sur la partie Ajax, ne connaissant pas encore les plugins de Grails par coeur. Par contre, et c’est ce que je veux vous montrer, j’ai écris le coeur de l’application en 8 minutes.

Pré-requis:
- Téléchargez Grails 1.2-RC2 et décompressez l’archive dans un répertoire C:\grails par exemple
- Ajoutez une variable d’environnement sous Windows appelé GRAILS_HOME qui pointe vers C:\grails.
- Ajouter ensuite %GRAILS_HOME%\bin dans votre variable PATH sous windows afin que Grails se trouve dans le path. Ouvrez un terminal et vérifiez que tout fonctionne avec « grails -version »
- Sous Unix, éditez votre fichier .bash_profile et ajouter la variable GRAILS_HOME. Ajoutez aussi GRAILS_HOME/bin à votre PATH. Validez l’installation avec « grails -version »

Ok c’était facile. On continue ?

Dans un répertoire, nous allons créer une application zencontact :


grails create-app zencontactdemo
...
...

Ensuite déplacez vous dans le répertoire zencontact. Nous allons commencer par créer notre entité « Contact » avec la commande create-domain-class :


cd zencontactdemo
grails create-domain-class  org.letouilleur.demo.Contact
...

Maintenant, nous avons besoin d’un Controller et de pages par défaut pour la partie CRUD. La commande generate-all va créer un Controller pour afficher, éditer, supprimer et modifier les entités de type Contact. Il va aussi créer un ensemble de pages GSP pour chacune de ces actions. Le modèle est donc la class Contact, le contrôleur sera le fichier ContactController et enfin les vues seront l’ensemble des pages GSP (edit.gsp, index.gsp, create.gsp…) correspondant à chacune des actions du contrôleur Grails.


grails generate-all  org.letouilleur.demo.Contact

Je ne sais pas pour vous… mais comme cela fait déjà 6 minutes il faudrait peut-être tester non ? Alors nous allons lancer un serveur Jetty préconfiguré et déjà intégré à notre application. C’est le mode « développement » qui permet de travailler très rapidement sans devoir installer un serveur. La base de données est vraiment là, c’est une base en mémoire HSQLDB. Par défaut, en mode développement Grails efface et recrée la base et les tables à chaque redémarrage. Vous pouvez changer ce comportement bien sûr… En fait vous pouvez tout faire.

Bref nous allons démarrer notre serveur et ensuite regarder la tête de notre application pour l’instant :


grails run-app
...
Environment set to development
  [groovyc] Compiling 1 source file to /Users/nicolas/.grails/1.2-M4/projects/zencontactdemo/target/classes
Running Grails application..
Server running. Browse to http://localhost:8080/zencontactdemo

Si vous ouvrez maintenant votre navigateur favori vous devriez voir ceci :

Par contre si vous cliquez sur notre premier contrôler, le moins que l’on puisse dire c’est que pour l’instant il ne se passe rien non ?

Etape 2 : le domaine
Pour l’instant il ne se passe rien car Grails ne sait pas trop quoi faire. Pour l’aider, arrêtez le serveur pour l’instant et éditez le fichier ./grails-app/domain/org/letouilleur/demo/Contact.groovy avec un éditeur de texte autre qu’Eclipse :

En suivant le cahier des charges, nous allons déclarer les attributs nom, prenom comme obligatoire. Remarquez aussi que le champ email est typé comme étant une adresse email. Groovy est expressig et Grails s’en sert simplement pour construire tout ce dont il a besoin. La validation, l’affichage des messages d’erreurs, les contraintes en base : la validation est déclarée ici une fois pour toute. Comme Beans Validator, Grails pense que le meilleur endroit pour déclarer les contraintes d’un modèle sont dans le modèle lui-même. Pas dans le GUI, pas dans la base. Cependant, la base de données qui est créé automatiquement par Grails reprendra ces contraintes afin de typer correctement les colonnes.

class Contact {
	String nom
	String prenom
	Date dateNaissance
	String email

	static constraints={
		prenom(blank:false)
		nom(blank:false)
		dateNaissance(max:new Date(),nullable:true)
		email(email:true,nullable:true,blank:true,unique:true)
	}
}

Après avoir changé autant notre domaine, nous allons simplement recréer toutes les vues et le contrôleur, avant de relancer le serveur. En ligne de commande, relancez la génération de cet ensemble et répondez « a » pour ALL lorsque Grails vous demande si vous voulez écraser vos anciens fichiers :


grails generate-all org.letouilleur.demo.Contact
...
File [...]/zencontactdemo/grails-app/views/contact/create.gsp already exists. Overwrite? [y,n,a] a

Puis relancez le serveur (grails run-app) et revenons à notre page « contact ». Vous pouvez maintenant créer un contact avec les champs que nous avons simplement déclaré dans notre POGO (Plain Old Groovy Object). Si vous cliquez sur « New Contact » vous pouvez maintenant vraiment créer des contacts et les stocker en base. Pas mal non au bout de 8 minutes ?

Etape 3 : mettre en place le template
A cette étape nous avons une class ContactController.groovy qui nous donne toutes les fonctions du cahier des charges. Il suffit maintenant de travailler sur la vue, d’adapter un peu certaines parties, mais vous verrez que c’est plutôt simple. Tout d’abord, recopiez les images et la feuille CSS de Zenika dans le répertoire web-app de votre application. Nous allons débuter par modifier la page d’accueil. Il faut s’occuper du menu de navigation et de l’affichage de l’heure en temps réel.

Dans le répertoire « grails-app/views/layouts/ » nous allons d’abord nous attaquer au template. Grails utilise SiteMesh, et nous devons montrer qu’il est possible de définir le look and feel à un seul endroit. Pour cela je vais d’abord éditer le fichier main.gsp. Notez à la ligne 6 que ce tag permettra aux pages qui utiliseront ce template d’ajouter dans le HEADER du contenu. A la ligne 7 j’importe la librairie prototype. Un souci avec scriptaculous m’a obligé à déclarer un deuxième template « main2.gsp » pour certaines pages. A la ligne 12 j’ai déclaré les différentes URLs de mon application. Ici, en principe en Grails la bonne pratique veut que l’on crée une taglibs. Je l’ai fait un peu plus bas pour vous expliquer le principe. Pour nous, s’agissant d’un bout de code qui n’est pas dupliqué autre part, je peux très bien déclarer mes URLs en dur (principe DRY).
La ligne 21 permet de déclarer la zone où Grails ajoutera le contenu des pages filles, que nous allons modifier dans 2 minutes.



  <g:layoutTitle default="Zencontact"/>
  
  
  
  



  Accueil |
  Liste des contacts |
  Liste v2 |
  Ajouter un contact



  

    
      
    
  


  Le Touilleur Express Copyright© 2009-2010

Créer un deuxième fichier appelé main2.gsp dans le même répertoire, et changez simplement la ligne 7 en spécifiant . Voilà vous avez créé 2 templates pour le site

Etape 4 : mettre en place la page d’accueil
La page d’accueil est simple. Elle affiche la navigation, et fait appel à une taglib pour afficher l’heure en temps réel. Cela va me permettre de vous expliquer comment créer une taglib et ensuite comment ajouter un contrôleur supplémentaire. Vous allez même faire de l’Ajax dès maintenant !

Voyons le code de cette page tout d’abord :

Zencontact avec Grails 1.2-M4

Voici la version Grails 1.2 de la démonstration Wicket de Zenika réalisée début mars 2009 au Paris Java User Group. Nous retrouvons les fonctions du cahier des charges avec surtout un Controller complet capable de réellement créer, modifier et effacer un objet Contact.

Explications :
- la ligne 4 spécifie que nous utiliserons le template « main2″ pour cette page. En effet, notre taglib pour afficher l’heure utilise Scriptaculous.
- la ligne 16 devrait vous intriguer… C’est une taglib, et pour l’instant elle n’existe pas

Pour créer la taglib vous devez exécutez la commande suivante, relancez le serveur à la fin de la commande et laissez-le tourner.

grails create-tag-lib Tools
...
WARNING: You have not specified a package. It is good practise to place classes in packages (eg. mycompany.Book). Do you want to continue? (y, n)
y
...

grails run-app
...

Editez ensuite le fichier grails-app/taglib/ToolsTagLib.groovy et copiez-y ce bout de code:

class ToolsTagLib {
  def showDateAndTime = {attrs ->
   out << ""
   out << ""
  }
}

Une taglib est automatiquement importée et devient disponible dès lors que vous la déclarez dans votre page. La ligne 16 de notre fichier index.gsp de tout à l’heure est presque prête à fonctionner. Si vous regardez le code groovy de ce tag, vous verrez que j’utilise Scriptaculous et sa fonction Ajax.PeriodicalUpdater afin d’appeler l’url /zencontactdemo/timer/getTime. Cependant pour l’instant, il n’y a pas de contrôleur associé. Nous allons donc créer un contrôleur et y ajouter la méthode getTime.

grails create-controller org.letouilleur.demo.Timer
...

Editez le fichier grails-app/controllers/org/letouilleur/demo/TimerController.groovy, voici comment celui-ci se présente par défaut :

package org.letouilleur.demo

class TimerController {

    def index = { }
}

En Grails, un Controller c’est une URL, et une méthode, c’est une sous-url de ce Controller. Ajoutez maintenant un fichier index.gsp dans le répertoire grails-app/views/timer. Vous l’aurez compris : chaque Controller a son répertoire, et une action correspond à un fichier de vue. Dans le fichier index.gsp, mettez « Coucou » et ensuite lancez le serveur si celui-ci est éteint. Vous verrez que l’url http://localhost:8080/zencontactdemo/timer fonctionne et affiche « Coucou ».
Par ailleurs, si vous éditez le fichier index.gsp et que vous rechargez la page, votre modification est prise en compte sans relancer le serveur comme avec Tapestry.
Mais pas comme Wicket.
Je vais faire mal là où cela fait mal. Avec Wicket il faut relancer le serveur dès lors que vous touchez à la partie Java. Avec Grails, vous êtes tranquille tant que vous n’ajoutez pas de nouveaux Controller ou que vous ne modifiez pas une classe de la partie Domain. A l’usage, on relance moins Grails que Wicket. J’ai travaillé avec les deux, croyez-moi.

Pour terminer notre première page, il nous faut une méthode qui retourne la date et l’heure actuelle.

class TimerController {

  def index = { }

  def getTime = {
    def theTime = new java.text.SimpleDateFormat("HH:mm:ss dd MMMM yyyy").format(new Date())
    [currentTime: theTime]
  }
}

Ajoutez aussi un fichier getTime.gsp dans le répertoire /grails-app/views/timer avec ce contenu:

  Il est ${currentTime}

Pour tester le tout, ouvrez l’url http://localhost:8080/zencontactdemo/timer/getTime et vous devriez voir votre message s’afficher.

Cette partie nous permet de voir comment Grails passe des paramètres du Modèle vers la Vue. La ligne 7 de la méthode getTime construit une Map avec pour clé « currentTime » et pour valeur le contenu de ma chaîne « theTime ». Si je vous dis que derrière tout cela, c’est du Spring MVC, vous vous rendez compte de la simplicité de ce bout de code ? Notre vue utilise la syntaxe ${currentTime$} pour afficher la valeur de l’objet passé en paramètre. C’est simple non ?

Il est temps maintenant de charger notre page de démarrage et de vérifier que l’heure change toutes les secondes.

Voilà pour la première page !

Je vous ai préparé un fichier zip avec l’ensemble du code de cette étape afin de vous aider si vous n’avez pas pu suivre toutes les explications. Cliquez-ici pour télécharger le fichier grails_touilleur_etape1.tar.gz

Conclusion etape 1
Je m’arrête là pour ce premier article. Si vous testez de votre côté vous verrez que la liste des contacts et l’ajout d’un nouveau contact fonctionne. A propos de validation, je ne sais pas si vous avez remarqué, mais l’email est vérifié. Si vous ne spécifiez pas de prénom ou de nom lors de la création, Grails vous affichera une erreur. Bref il ne reste plus qu’à implémenter les fonctions avancées de la liste de résultat, mais vous verrez que ce n’est pas beaucoup d’effort.

Grails est un framework Web qui va de la couche présentation à la partie service et métier. Il vous suprendra par la rapidité à laquelle vous produisez un résultat parfait. Si lors de la lecture vous avez pensé parfois que je donnais trop de détails, c’est aussi pour vous montrer un vrai projet et pas un simple HelloWorld. C’est aussi pour cette raison que je trouve l’idée de Zenika intéressante : puisque l’on dit que c’est simple, autant montrer un exemple qui marche en une heure ! Wicket est certainement plus intégré et plus fort pour une application orientée vue. Et c’est un très bon framework. Je pense que Grails vous séduira plus par la partie Hibernate/CRUD que par la partie vue, qui reste simple. Du côté Ajax et Javascrpit j’ai un peu galéré, et là où Wicket propose des composants prêts à l’emploi, j’ai dû bidouiller pour couvrir le cahier des charges. J’exagère un peu car d’un autre côté, certaines fonctions sont très simples avec Grails. Vous souhaitez la liste de tous les contacts triés par nom ? En Grails c’est Contact.listAllByNom() que vous placez dans une list, et que vous itérez du côté de la vue…

Nous verrons la prochaine fois que j’ai fait appel à des plugins pour compléter mon application. La vidéo vous montre le résultat terminé en moins de 5 minutes. La suite de cet article sera en ligne dans une semaine.

A bientôt !

Grails en quelques mots

Nicolas Martignole — Fri, 18 Dec 2009 23:31:00 +0000

Je travaille depuis quelques mois avec le framework Web Grails. Cela fait quelques semaines que je m’en sers presque 8 heures par jour. Je vous propose un petit tour du propriétaire.

Grails est un framework Web basé sur le langage Groovy clairement orienté productivité. J’ai ramené 4 livres de Devoxx sur Groovy et Grails, et le meilleur ouvrage pour rentrer dedans reste « Grails in Action » de Glen Smith et Peter Ledbrook. 470 pages plus tard vous serez en mesure de construire une application industrielle, et il vous manquera un peu de détails sur Groovy, facilement couvert par exemple avec « Groovy Recipes » de Scott Davis.

Grails s’installe en 5 minutes, se découvre en 30 minutes et se maîtrise en une semaine. Je me dis que si mon aventure de Startup ne marche pas, je pourrai toujours écrire un livre sur le sujet en Français. C’est vous dire si j’ai envie de vous en parler.

Introduction à Grails
Grails m’est tombé dessus car j’avais besoin d’une solution pour démarrer rapidement, valider rapidement (et éventuellement me planter rapidement). Je me surprends à tester des bouts de code, à écrire des choses comme « Books.findByAuthor(‘Guillaume Laforge’) » et à voir que Grails génère le code de ce finder pour moi… Envie d’Ajax ? je transforme mes tags form en remoteForm et ça marche. Envie de faire un formulaire avec 4 écrans ? Spring Webflow est intégré, le flow est écrit en Groovy, rien de plus simple… Et c’est comme cela depuis 3 semaines… Je n’arrête pas de m’étonner de la maturité et de la puissance de ce framework Web.

Avec ou sans état ?
Grails comme Play! se classe dans la catégorie des frameworks Webs sans état. Il y a bien entendu une session, des scopes pour vous aider à travailler. Mais là où Wicket et JSF sont orientés composants, Grails est clairement orienté Web / HTTP. Il n’y a pas la notion d’Application et il n’y a pas la notion de composants comme en Wicket ou JSF2 par exemple. Nous pouvons donc dire que Grails est adapté pour la réalisation de projets plutôt Web, et il n’est pas forcément le plus adapté pour réaliser une application riche. Il y a pourtant des applications basées sur du Flex pour la couche de présentation qui travaillent avec une partie serveur en Grails pour les services. Cette alchimie fonctionne donc aussi.

Fan des conventions au lieu de la configuration
Grails tire ses origines du framework Rails du monde Ruby. Mais il utilise le langage Groovy qui tourne sur la JVM. Ses cousins ? JRuby on Rails, Clojure, le framework Lift du monde Scala, et Play! du monde Java. C’est un framework Web clairement orienté productivité et simplicité. Pour moi, il fait parti des frameworks webs de 4ème génération. Il y a d’abord eu les JSPs, les Servlets et les Applets. Puis ensuite Struts avec les premiers frameworks MVC de type 2. Ensuite l’apparition des RIAs (Rich Internet Applications) avec GWT, JSF, Wicket. Et donc maintenant je crois dur comme fer à ces nouveaux frameworks Webs, qui reviennent sur les bases du protocole HTTP pour offrir des performances et de la simplicité.

Grails est sorti en 2006. Il y a des sites en production comme Businessworld, Sky.com ou encore Escapeer. La page Testimonials donne une idée de quelques projets réalisés avec Grails et Groovy.

Groovy est le point fort de Grails. Je vous parlais de trouver des livres quelques lignes plus hauts. Vous pouvez aussi écrire des bouts de code comme par exemple:
Book.findAllByDatePublishedGreaterThanAndTitleLike(myDate,"Grails par le Touilleur Express")

Grails sera capable de générer le code Hibernate, Spring et Groovy afin de trouver tous les livres dont la date de publication est postérieure à une date, et dont le titre ressemble à ce que je précise… Lorsque je vous dis que vous allez gagner du temps, vous commencez à me croire ?

Grails utilise des standards
Grails utilise Groovy, et ensuite le couple Hibernate/Spring de base. Il est assez facile d’ajouter de nouvelles librairies grâce à des plugins. Dans mon projet par exemple j’utilise Drools. Je n’ai eu besoin que de 10 minutes pour créer un controleur simple et une règle Drools pour tester une idée.

Les idées de Grails
Ce qui suit est tiré du livre « Grails in Action ». Il y a 7 idées clés à comprendre pour adopter Grails:
- Convention au lieu de la Configuration
- Philosophie Agile
- Des fondations solides
- Scaffolding et moteur de template
- Intégration avec Java
- Une communauté et des plugins
- La Productivité améliore la qualité et réduit le risque d’erreur

Concernant l’aspect convention au lieu de configuration, cela revient à vous dire que pour gagner du temps, il faut suivre ce que dis le framework. J’ai juste un mot à dire aux gens qui font du Maven2, mais qui ne veulent pas ranger leurs fichiers dans src/main/java, qui désactivent les tests, qui veulent lancer des scripts Ant avec Maven : arrêtez Maven.
Vous n’avez rien compris à sa philosophie, vous pleurez car « Maveneu il rameuu » alors que si vous aviez pris le soin de lire l’excellent livre « Apache Maven », vous ne seriez pas comme un gosse avec le pantalon mouillé. Si vous commencez à bidouiller l’outil, c’est que vous n’avez pas lu la documentation, que vous n’avez pas écouté ce que vous disent les développeurs. A ce titre, je trouve que les livres que j’ai lu m’ont énormément aidés par rapport à la doc de Grails, qui ne distille pas assez la philosophie, à mon sens. Donc si vous voulez me suivre : achetez des livres sur Grails.

Grails est simple : une entité Survey est toujours stockée dans le répertoire domain. Cela permet à Grails de gérer l’object via Hibernate pour vous. Un controlleur est nommé SurveyController, et il est placé lui-aussi dans un endroit attendu par Grails. Si vous ajouter une méthode « completeSurvey », celle-ci est alors accessible automatiquement via une url comme « /survey/completeSurvey ». Si vous créez une nouvelle entité « Answer », Grails se charge de créer la table en base de données. Vous n’avez pas généré de fichiers pour tout ce qui est CRUD ? Grails le fait tout seul. Pour l’affichage des pages, il suffit de créez un fichier « /views/survey/completeSurvey.gsp » et il sera alors automatiquement chargé…

C’est bien de la Convention par dessus la Configuration et surtout pas de la Convention « au lieu de » la Configuration. Si vous voulez utiliser vos fichiers de mapping Hibernate : oui c’est possible. Mais par défaut : vous n’en n’avez pas besoin. Tout ce qu’il est possible de faire de manière répétitive et générique, c’est offert. Et comme vous aurez besoin de mettre le nez dedans, vous pouvez aussi le faire.

J’en suis à 16 classes pour mon domaine, à 2700 lignes de codes, 19 contrôleurs, et en 3 semaines j’ai déjà une application qui tourne… Je vous assure que je vous montrerai tout cela dans une vidéo très bientôt.

Grails est adapté au développement Agile. En fait je pense même que l’on peut dire que c’est un framework Web Agile. Les tests unitaires comme les tests fonctionnels sont faciles à écrire. Le fait de pouvoir créer un War, c’est aussi très pratique. Je vous explique cela : j’ai installé un Tomcat sur une machine, avec une base MySQL. Sur mon Mac, en ligne de commande il suffit que je tappe « grails war production » pour que cela me construise un fichier WAR, qu’il me suffit de déployer ensuite sur Tomcat pour la version en production. A aucuns moments je n’ai eu besoin de mettre le nez dans un quelconque fichier web.xml…
Au quotidien je ne construis pas de WAR. Je tappe simplement « grails run-app » et un serveur Jetty démarre, intégré à Grails. Lorsque je code, je n’arrête presque pas le serveur. En fait, lorsque vous changez un bout de page GSP, celle-ci se rafraîchit tout en gardant votre session. Si vous ajoutez une nouvelle méthode dans votre contrôleur, l’url est disponible et vous pouvez continuer à coder. Il n’y a qu’en cas de plantages que je relance parfois le serveur, lorsque ma session est pourrie. Je trouve que la remontée d’erreur pourrait encore faire des progrès par rapport à Play! mais c’est déjà pas mal.

Grails est basé sur des fondations solides. Spring et Hibernate. Spring 3 depuis la toute dernière version 1.2.RC2 que je teste en ce moment. En fait vous ne voyez pas Hibernate et Spring, mais vous savez que vous pouvez aller voir si nécessaire. Le moteur de scheduling ? C’est Quartz. Le moteur de recherche ? Lucene et Compass pour les entités. Le moteur de construction ? SiteMesh… Bref il n’y a pas d’innovations. Nous parlons bien de techniques que vous connaissez déjà. Imaginez simplement ceci : écrire moins de code, travailler plus vite.

Le moteur de scaffolding et de templating. J’adore Spring MVC. Je m’en suis servi l’été dernier pour mon projet sur Google App Engine (http://touilleur.appspot.com), projet que je ne finirai pas faute de temps. Grails est assez radical par rapport à Spring MVC. Là où vous auriez quelques beans annotés, des fichiers de configuration, un peu d’Hibernate et une configuration avec la base, Grails fait la même chose en quelques minutes.
grails create-app myapp ... ... grails run-app
Ouvrez votre navigateur : http://localhost:8080/myapp, c’est prêt. Ensuite si vous voulez ajouter un nouveau contrôler :
grails create-controller MonControleur
C’est tout !

Lorsque vous créez une nouvelle entité, un nouvel objet du domaine, il est facile aussi pour Grails de vous générez automatiquement tout ce qui est CRUD. C’est ce que l’on appelle le scaffolding. Ce n’est pas destiné à remplacer votre application. En fait voici comment je travaille : je génère d’abord mes entités avec des idées à tester. Ensuite je crée un controleur pour cette entité en mode « scaffold ». Cela me permet de tester mon objet, de valider les relations one-to-one, one-to-many, many-to-many et de m’assurer que tout marche. Enfin, je refais un vrai contrôleur pour mon application finale, et je ne touche pas à ce que Grails m’a généré. Je recopie quelques petits bouts de code pour gagner du temps, mais c’est là que je code vraiment mon application. Cela me fait gagner un temps fou.

L’intégration avec Java est là pour rassurer les bons pères de famille. Il y a un répertoire Java. Vous pouvez y placer ce que vous voulez. Pour peu qu’une librairie de votre ERP soit en Java, et qu’il soit nécessaire d’écrire un peu de code orienté Service, Grails vous aménage un espace dédié pour le faire, et se débrouille pour injecter vos services Java dans les contrôleurs Grails… C’est très pratique. Je m’en suis servi pour une partie avec du Drools, que j’ai migré vers du Groovy car finalement, c’est plus simple.

Grails a une communauté. C’est bête, mais lorsque le lundi matin vous êtes seul dans votre bureau de 7m2, croyez-moi vous êtes super content de voir qu’il y a pleins de gens qui se servent de Grails sur Internet. Google est ton ami. La documentation est bonne. Le produit vit, et la liste de diffusion users est très active. J’ai appris beaucoup en lisant les échanges ces dernières semaines. Enfin côté livre je vous le disais tout à l’heure, il y a de très bons livres en Anglais. Si j’avais le temps et le courage, je me lancerai bien dans l’écriture d’un livre en Français. Mais je suis trop bavard… Pas possible pour moi.

Enfin pour terminer, le 7e point noté par les auteurs de Grails in Action, c’est l’aspect de productivité et la possibilité de valider ou non ses idées très rapidement. Pour notre projet qui sera en ligne l’été prochain, je me remercie chaque jour d’avoir pris Grails pour gagner du temps, faire des démonstrations qui marchent chaque semaine, jeter sans souci du code écrit en 3 jours au lieu de 2 semaines, bref je peux dormir tranquillement la nuit. Est-ce que tu comprends que je peux virer des idées foireuses car elles ne m’ont coutés que 2 jours au lieu de 2 semaines ? Un vrai projet de Startup c’est beaucoup d’essais. Personne ne vous dira si ce que vous faîtes c’est bien ou pas. Il faut avoir cette possibilité de changer de cap très rapidement, encore une fois dans le cadre d’une Startup pour moi.

Conclusion
Pour terminer, je vous laisse ici ce soir. Je vous montrerai un peu de Grails, du vrai code, pas un « Hello World », plutôt une application écrite en quelques heures, afin de vous faire comprendre ce qui a retenu mon attention.

Je pense aussi que nous, développeurs Javas, devons nous remettre en question d’urgence. En voyant des projets sur PHP ou Ruby on Rails, j’ai un peu la gueule de bois avec mon Java. Je pense que pour le développement d’applications Webs, il faut revoir notre manière de penser, notre manière de travailler. J’ai même du mal à croire au succès de Struts hier, de Wicket/Tapestry/JSF en ce moment… Comment pouvons-nous rouler des mécaniques alors que d’autres langages sont bien meilleurs pour faire du développement webs ? Que d’autres frameworks sont bien mieux pensés et bien moins prétentieux que ce que nous vendons depuis 3-4 ans à nos clients ? Comment avons-nous pu vendre des développements avec du Struts, des JSPs à des clients finaux ? Comment ?

Imaginez-vous entrain d’expliquer aux clients que les développeurs sur certains projets doivent construire un WAR, arrêter et relancer leur serveur d’application avant de voir leur résultat… alors que c’est inutile avec Grails (et d’autres)…

Et encore, je ne vous ai même pas encore dit que j’étais aussi tombé amoureux de Groovy…

J’en garde pour la prochaine fois.

Premiers pas avec Grails 1.1.1 et Google AppEngine

Nicolas Martignole — Tue, 09 Jun 2009 12:05:24 +0000

Ah là là… dire qu’à la fin de la lecture de ce billet j’aurai complètement changé votre vision du Web… Je comprends mieux maintenant Didier Girard de SFEIR, il y a un avant et un après Google AppEngine… Mais bon, soyons patient et voyons ce que nous pouvons faire aujourd’hui. Ce qui suit est inspiré, pour ne pas dire affreusement copié sur ce que Guillaume Laforge a présenté le 28 mai dernier lors de la conférence Google I/O à San Francisco. J’ai simplement adapté la présentation en français, je l’ai fait fonctionner, pour le reste tout le crédit va à Guillaume.

Guillaume Laforge Google IO 2009

A la fin de cet article vous serez en mesure de déployer sur Google AppEngine une petite application simple.

Installer Grails
Téléchargez et installer Grails 1.1.1. Pour ma part, sur Mac OS j’ai ensuite édité mon fichier .bash_profile afin de déclarer le chemin d’installation de Grails, et fixer la version de Java à la version 5 pour éviter quelques soucis plus tard avec Google AppEngine et DataNucleus.
Voici le contenu du fichier $HOME/.bash_profile

export M2_HOME=/usr/share/maven
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
export GRAILS_HOME=/Users/nicolas/Dev/grails/grails-1.1.1
export APPENGINE_HOME=/Users/nicolas/Dev/appengine-java-sdk-1.2.1
export PATH=$PATH:$GRAILS_HOME/bin

Vérifiez que Grails est correctement installé avant d’aller plus loin:

macbook-pro-de-nicolas-martignole:~ nicolas$ export GRAILS_HOME=/Users/nicolas/Dev/grails/grails-1.1.1
macbook-pro-de-nicolas-martignole:~ nicolas$ export PATH=$PATH:$GRAILS_HOME/bin
macbook-pro-de-nicolas-martignole:~ nicolas$ grails -version
Welcome to Grails 1.1.1 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: /Users/nicolas/Dev/grails/grails-1.1.1

Base Directory: /Users/nicolas
Running pre-compiled script
Script not found: Version
macbook-pro-de-nicolas-martignole:~ nicolas$

Les observateurs ont remarqué certainement la variable APPENGINE_HOME. Il est temps de télécharger Google AppEngine, après avoir demandé un compte. Suivez attentivement les explications de la page principale de Google AppEngine. Une fois le téléchargement effectué, j’ai simplement décompressé l’archive tar.gz dans un répertoire, puis ensuite j’ai configuré la variable APPENGINE_HOME afin qu’elle pointe vers le répertoire de GAE (Google AppEngine).

Créer sa première application Grails
Grails vous permet de créer rapidement une application et de la tester. Allons-y, placez-vous dans un nouveau répertoire vide et créez votre première application grails, appelée ici gaetex:

grails create-app gaetex

Lorsque nous utilisons Google AppEngine, nous devons désinstaller le plugin JPA et désinstaller le plugin Hibernate. Le plugin JPA génère un fichier persistence.xml qui vient en conflit avec celui utilisé par le mode JPA du plugin Google AppEngine. Concernant Hibernate, nous n’en avons pas besoin ici.
Pour cela il suffit d’exécuter les 2 commandes Grails suivantes en vous mettant d’abord dans le répertoire gaetex que nous venons de créer :

cd gaetex
grails uninstall-plugin hibernate
grails uninstall-plugin jpa

Notez qu’en principe, le plugin jpa n’est pas installé, j’ai ajouté cette commande au cas où vous l’auriez installé aussi.

Installer Google AppEngine
L’installation de Google AppEngine est simple. Assurez-vous simplement que la variable APPENGINE_HOME pointe vers votre répertoire d’installation de GAE puis lancer la commande d’installation du plugin App-Engine :

grails install-plugin app-engine

Ce qui donne sur ma machine:

macbook-pro-de-nicolas-martignole:gaetex nicolas$ echo $APPENGINE_HOME
/Users/nicolas/Dev/appengine-java-sdk-1.2.1
macbook-pro-de-nicolas-martignole:gaetex nicolas$ grails install-plugin app-engine
...
...

Tester le tout
Vérifions que tout fonctionne en démarrant le serveur Jetty intégré à Grails. Dans le répertoire gaetex, lancez grails:

grails app-engine

Connectez-vous à votre machine (http://localhost:8080/) et vous devriez voir votre première page Grails s’afficher.

Créer une première entité
Nous allons maintenant créer une entité Book, et générer ensuite la partie vue et contrôleur. Avec Google AppEngine, il n’est pas possible de placer ses Entités directement dans le répertoire « grails-app/domain ». Il est nécessaire d’utiliser un package. J’ai donc fait comme Guillaume durant sa démonstration, j’ai créé une entité Book dans le package « demo » avec la commande suivante :

grails create-domain-class demo.Book

Il serait intéressant maintenant d’ajouter deux attributs « title » et « author » à notre Book.

Editez le fichier gaetex/grails-app/domain/demo/Book.groovy avec un éditeur de texte, et ajoutez simplement 2 attributs pour le titre et l’auteur du livre :

package demo

import javax.persistence.*;
// import com.google.appengine.api.datastore.Key;

@Entity
class Book {

    @Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	Long id

	// Added by Nicolas Martignole
	String title
	String author

    static constraints = {
    	id visible:false
	}
}

Avec ces deux attributs en place, nous allons maintenant générer un controlleur et tester à nouveau notre application.
Lancez la commande de génération du controleur et des vues:

grails generate-all demo.Book

Puis relancez ensuite le serveur Grails :

grails app-engine

Voici ce que cela donne après avoir créé quelques livres (au logo prêt) :

Vous pouvez retrouver la même chose avec la voix de Guillaume à partir de la minute 50 sur la vidéo YouTube de la présentation.

Déployer son application Grails sur Google AppEngine
Voici la liste des étapes:
1) créer une application sur Google AppEngine
2) modifier le fichier grails-app/conf/Config.groovy et ajouter une ligne avec le nom de votre application
3) packager et préparer l’application
4) effacer un fichier parasite (probleme à résoudre)
5) utiliser le script appCfg.sh pour fournir votre email et votre mot-de-passe Google
6) ensuite simplement mettre à jour avec le plugin google-app-engine de Grails

Voyons en détail chaque étape:

1) Rendez-vous sur « Google AppEngine » afin de faire une demande, puis ensuite de créer votre application. L’application id doit être unique, ce pourra être par exemple testgrails1234
2) Ouvrir le fichier Config.groovy se trouvant dans votre application et définissez l’application id que vous venez de mettre

google.appengine.application="touilleur"

3) Lancer la création du package avec les commandes suivantes:
Il faut fixer la version à un nombre entier car GAE n’accepte pas les numéros de version type x.y.z

grails set-version 1
grails app-engine package

4) Effacer le fichier « datastore-indexes.xml » sans quoi voici l’erreur que vous rencontrerez:

macbook-pro-de-nicolas-martignole:gaetex nicolas$ /Users/nicolas/Dev/appengine-java-sdk-1.2.1/bin/appcfg.sh update target/war
Reading application configuration data...
Bad configuration: XML error validating target/war/WEB-INF/datastore-indexes.xml against /Users/nicolas/Dev/appengine-java-sdk-1.2.1/docs/datastore-indexes.xsd
  Caused by: cvc-elt.1: Cannot find the declaration of element 'datastore-indexes'.
Please see the logs [/tmp/appcfg16875.log] for further information.

Pour résoudre ce problème, effacez le fichier datastore-indexes.xml avant de relancer la commande appcfg.sh (voir étape suivante)

rm target/war/WEB-INF/datastore-indexes.xml

5) Lancer la première fois seulement la mise à jour avec l’utilitaire appcfg.sh de Google AppEngine comme suit:

$APPENGINE_HOME/bin/appcfg.sh update target/war

Renseigner votre adresse mail Google ainsi que votre mot de passe. Il suffit de mettre son login en fait (mdupont et pas mdupont@gmail.com).

6) Ensuite à chaque fois que vous souhaitez mettre à jour votre application vous pourrez utiliser le plugin de Gae dans Grails, plugin qui ne marche pas la première fois avec l’authentification en se plantant. C’est pour cette raison qu’il faut utiliser l’utilitaire appcfg.sh la première fois.

grails app-engine deploy

Si tout se déroule sans problèmes vous devriez alors mettre en ligne votre première application !!!

L’url de votre application sera http://.appspot.com

Si vous voulez tester un exemple d’application : PetClinic with Grails

Conclusion
Comptez 1h la première fois, puis ensuite 10 minutes pour refaire cet exercice. J’ai été vraiment séduit par la simplicité de Grails, et cette intégration avec Google App Engine. Celui-ci est gratuit jusqu’à un certain nombre de requêtes par jour, et croyez-moi vous avez largement de quoi tester votre code sans devoir payer, toujours dans l’esprit Google.
Je crois vraiment à un nouveau type de développement rapide d’applications, à la monétisation de compétences en Groovy et en Grails. Pour ma part je travaille en ce moment sur une application pour le Touilleur Express, un mix de LinkedIn avec une touche de Google Calendar, un esprit de Geek et bien entendu, toujours la pâte Touilleur Express.

Guillaume Laforge travaille aussi sur Gaelyk, un framework léger qui facilite l’intégration de Google App Engine si vous souhaitez n’écrire qu’en Groovy votre application Web, sans utiliser Grails. Il cite aussi le framework iUI qui est un framework Javascript destiné à faciliter l’écriture d’application pour l’iphone, hébergé sur Internet. Cela revient à ne pas passer par l’AppleStore, à simplement offrir un service type iPhone mais hébergé sur Internet directement.

Références
- Page d’accueil Google App Engine
- Page pour créer sa première application GAE
- Plugin GAE Grails le site à surveiller
- Groovy Web Console permet de taper du Groovy, application Google App Engine
- My Own Groovy par Guillaume Laforge avec quelques applications pour tester
- Portail des applications Google App Engine

Problèmes connus
Il y a un certain nombre de soucis pour l’instant sur le plugin Google App Engine pour Grails au moment où j’écris ces lignes (juin 2009). Ne vous lancez pas dans ce test si vous ne maîtrisez pas un minimum Grails. Je n’ai testé que la version JPA, je ne sais pas si la version JDO est plus ou moins stable.

Pour terminer je vous recommande de regarder la présentation de Guillaume Laforge sur YouTube: