Générer XML, des beans, des procédures stockées, et des vues pour Grails avec Groovy

je l’expliquais dans l’article, Grails pose quelques problèmes.

Premièrement, Grails fonctionne mieux en présence d’un champ de clé unique, alors que beaucoup de bases de données héritées usent de clés composites.

Deuxièmement, la personnalisation exige la création de documents de mapping Hibernate XML. Dans l’article « Faites hiberner votre JDBC », je proposais, comme solution à ces problèmes, de créer une vue SQL (qui ajoute le numéro d’enregistrement relatif à la liste des champs) et une procédure stockée qui traite les opérations d’insertion.

Mais l’écriture du code pour la vue, la procédure stockée, le XML de mapping Hibernate et le JavaBean ou GroovyBeans est une opération longue et sujette à erreurs. J’ai donc décidé de faire avec les moyens du bord et d’utiliser Groovy pour générer les objets. Je suis surpris de voir à quel point il est facile de travailler avec XML, SQL et des fichiers de texte avec Groovy.

J’ai écrit mon utilitaire Build400 GrailsDomain Groovy en environ trois fois moins de temps qu’il n’en aurait fallu pour l’écrire en Java – et avec un quart du code. Groovy valorise aussi beaucoup mon utilitaire parce qu’il ajoute des contraintes Grails au GroovyBean généré. Les contraintes de GroovyBean activent la validation automatique de Grails. La figure 1 montre le script Groovy qui utilise la classe Build400GrailsDomain de la figure 2 pour construire le domaine Grails pour le fichier ALLTYPES de la figure 3.

Closures
Voyons comment mettre en oeuvre le Build400GrailsDomain et détachons quelques-unes des fonctions les plus intéressantes de Groovy. La fonction la plus marquante d’un langage déclaratif est peut-être Closures. Les Closures sont essentiellement des blocs de code qui sont encapsulés comme des objets et, par conséquent, peuvent être transférés librement.

Dans mon utilitaire, Build400GrailsDomain crée des GroovyBeans avec des noms d’attributs construits à partir des en-têtes de colonnes de champs (ou, si les entêtes de colonnes de champ sont indisponibles, comme dans le cas de ALLTYPES, Build400GrailsDomain utilise le nom de champ comme le nom d’attribut). Pour cela, Build400GrailsDomain doit supprimer les soulignements, adopter la typographie « camel case » (par exemple, COUNT_OF_RECORDS devient countOfRecords) et remplacer les caractères non alphabétiques. Je ne peux pas deviner comment vous pourriez utiliser l’outil pour remplacer les caractères présents dans l’en-tête de colonne de votre fichier. J’aurais juste pu vous suggérer de « bricoler » Build400GrailsDomain pour chaque fichier sur lequel vous générez des domaines Grails, mais cela serait fastidieux. Voyons les Closures.

L’exemple de script RunBuild400 GrailsDomain (figure 1) montre une variable appelée nameManipulation, à laquelle est assignée une valeur qui est un bloc de code. Celui-ci utilise des expressions régulières pour remplacer divers caractères. En fait, vous pourriez désirer différentes options de remplacement pour divers fichiers. Par exemple, le fichier QIWS/QCUSTCDT a le mot « field » dans chaque en-tête de colonne, ce qui est redondant. J’ai remplacé « field » par une chaîne vide :

attr.name = attr.name.replaceAll(/Field/, '')

La Closure appelée nameManipulation est passée à la méthode run de RunBuild400Grails Domain. La Closure passe ensuite à la méthode retrieveTableAttributes, où elle est invoquée avec

nameManipulation?.call(attr)

Le point d’interrogation de cette ligne mérite une explication. C’est ce qu’on appelle un opérateur dereference (déréférencement). Groovy n’invoque pas la méthode call si la variable nameManipulation est nulle. J’aurais aussi pu utiliser la syntaxe Java plus explicite :

if (nameManipulation != null) {

nameManipulation.call(attr);

} 

L’intérêt d’utiliser une Closure dans mon exemple est de pouvoir en utiliser une différente pour chaque table. Vous pouvez ainsi modifier le comportement de la classe Build400 GrailsDomain sans toucher son code.

Paramètres nommés
named parameters est une autre fonction Groovy dont je me sers dans l’utilitaire. Le Build400GrailsDomain n’a pas de constructeur, mais Groovy vous permet de passer des paires nom/valeur à un constructeur pour identifier clairement les attributs de classe que vous voulez avoir définis sur l’instanciation d’un objet (figure 1).

Ecrire XML
retrieveTableAttributes de Build400 GrailsDomain construit une liste d’objets TableAttribute (figure 4). La liste est nommée attrs et est utilisée dans les autres méthodes de Build 400GrailsDomain pour créer la vue, la procédure stockée, la classe domaine, et XML.

L’implémentation de la méthode write HibernateXML utilise Markup Builder de Groovy (un exemple d’un DSL – domain specific language). Voyons les instructions suivantes dans le source Groovy, puis examinons le XML généré dans la figure 5). builder.'hibernate-mapping'() builder.'class'(name:domainName, … id(name:'id', type:'int') { } property(name:attr.name, … Les noms de méthodes et les paramètres du code Groovy ont une relation de un à un avec les tags et les attributs XML.

Et laissez-moi vous dire ceci : les méthodes n’existent réellement pas ! Groovy utilise ses possibilités de langage dynamique pour sortir XML avec les noms de tags et d’attributs. Friandise syntaxique Avant de finir, je veux mettre en avant quelques friandises syntaxiques : instructions switch, structures en boucle, et la Groovy String. J’utilise beaucoup les instructions switch de Groovy.

La plupart des méthodes font une itération sur la matrice de TableAttributes et utilisent un switch sur le type d’attribut pour créer des lignes pour le XML, la classe domaine, ou la procédure stockée. Pour faire cela en Java, j’aurais dû utiliser des if imbriqués, parce que le switch de Java ne peut traiter que des primitives comme integer, short, byte ou single character. Mes classes Java sont polluées par des for loops, alors que Build400GrailsDomain n’en a pas le moindre. Au lieu de cela, j’ai utilisé la méthode each de Groovy.

Le each fait une itération au travers d’une liste et passe chaque élément à la Closure (les instructions passées entre l’accolade suivant la construction each). La méthode each (ainsi que d’autres méthodes similaires, comme collect) simplifie le code nécessaire pour traiter des ensembles. Enfin, je veux mettre en lumière mon utilisation des chaînes Groovy. La méthode createStoredProcedure définit une variable appelée storProc comme une chaîne Groovy qui contient six lignes de code de procédure stockée SQL.

Les chaînes Groovy délimitées par des guillemets triples peuvent s’étendre sur plusieurs lignes. Outre des lignes étendues, la chaîne contient des références variables délimitées par des signes dollar et des accolades, dont les valeurs seront remplacées à l’exécution. Songez aussi à utiliser les classes SQL Groovy parce qu’elles réduisent nettement la quantité de JDBC que vous devez écrire.

– Don Denoncourt Rédacteur technique System iNEWS