@Nicolas : effectivement pour personnaliser le code généré, il faut d’abord copier les templates dans le projet à l’aide de la commande « grails install-templates ». On peut ainsi modifier les gsp et le template du controller. Voir http://www.grails.org/Artifact+and+Scaffolding+Templates mais c’est assez léger. J’espère en parler plus en détail prochainement dans un autre article.

@Piwai : excylis et moi sommes d’accord sur un point. « les commandes de génération » font référence au scaffolding statique, qui génère le code des gsp et du controller. Excylis parle du cas où il modifie manuellement le code généré, solution non viable puisque qu’à la prochaine exécution de la commande de génération, les modifications seront écrasées. On est donc d’accord, le scaffolding statique n’est (presque) jamais une bonne solution.
Le scaffolding dynamique est bien plus utile. Est-il puissant au point de mettre en place des cas d’utilisation très spécifiques (au projet ? à un objet métier ?) ? Je pense que non, ce n’est pas raisonnable de vouloir faire du « très spécifique » avec de la génération de code. Par contre le scaffolding dynamique permet d’avoir un CRUD sur tous les objets métier de l’application via une interface personnalisée au projet. Or là où je ne suis pas d’accord avec toi, c’est sur l’utilité du CRUD. Le CRUD est un besoin récurrent de tous les projets. Ne serait-ce que les écrans de création, ils sont indispensables au métier pour remplir la base. Et après le métier a besoin de consulter les données créées, les corriger, les modifier, les supprimer. Bref les données ne sont jamais figées et le CRUD permet au métier de les manipuler directement.
Nous avons mis ce CRUD d’admin en place sur un projet (qui tourne en production), et la maintenance se résume à la modification des objets domain, sans impact pour l’interface d’admin.

Cependant tu as raison, il y a toujours des besoins spécifiques. Par exemple nous voulions changer complètement l’affichage de la liste pour un objet domain particulier mais nous voulions garder l’édition/création/modification proposée par grails.
Nous avons donc surchargé la méthode list du controller (en gardant l’attribut scaffold = true) afin de ne ramener que certains éléments (par défaut tous les éléments de la table sont affichés). Ensuite nous avons généré la list.gsp (pour ne pas partir de zéro, « grails generate-views » puis suppression des 3 gsp qui ne nous intéressent pas), puis nous avons personnalisé son affichage (précision pour Nicolas, cette page list.gsp modifiée ne sera pas écrasée par le scaffolding dynamique. Au démarrage de l’application Grails ne génère que les méthodes de controller et vues manquantes).
La liste répond désormais au besoin spécifique tout en gardant l’avantage du scaffolding dynamique pour les autres vues de cet objet. C’est cette souplesse qui est très appréciable avec Grails.
Par contre la maintenance de cette liste est évidemment manuelle et donc alourdit un peu l’application. Mais ce genre de besoins spécifiques ne concernent que quelques objets (sur notre projet en tous cas), la grande majorité des écrans d’admin sont complètement générés dynamiquement, ce qui nous fait gagner un temps précieux !

Je trouve cet article très intéressant, mais je m’interroge.

Vous citez « la maintenance » comme un des avantages du scaffolding dynamique, puisque c’est une solution qui s’adapte aux modifications de l’objet métier.

Le scaffolding dynamique est-il donc puissant au point de permettre la mise en place d’une interface d’admin avec des cas d’utilisation souvent très spécifiques ? Ou bien ne peut t’on réaliser que de simples CRUD, qui n’ont un intérêt que pour les démos et les prototypes ?

Dans l’article suivant : http://blog.excilys.com/2009/12/21/grails-episode-3-branchement-des-controleursvuesservices/ , l’auteur estime que « les commandes de génération ne sont à utiliser qu’une seule fois au début du projet et sont à bannir par la suite ».

Ces différents points de vues m’intéressent. Quelqu’un a t’il des retours d’expérience sur le sujet ? Et qu’en est-il de la maintenance ?

@Nicolas: lors de la génération du code (contrôleurs et vues), Grails vérifie s’il y a déjà des fichiers générés, et il demande une confirmation avant d’écraser les modifications.
C’est bien l’un des inconvénients de ce type de framework de génération de code.