IBMi, Découverte du code Grails

C’est pourquoi Grails considère le contrôleur et la vue générés comme un « échafaudage » servant à la construction. Le code en question est intéressant parce que, en l’examinant, vous apprendrez rapidement à écrire votre propre code plus élaboré. Voyons d’abord le code du contrôleur dans la figure 8. Il ne comporte que 72 lignes et on peut le diviser en quatre zones importantes : extraction des domaines, liage des données, validation, et mise à jour de la base de données.

Extraction des domaines

Les classes de domaines Grails possèdent leurs propres méthodes d’extraction. Ma classe OrderDetailController utilise :

•    OrderDetail.list(), pour extraire une liste des enregistrements OEORD1 et
•    OrderDetail.get(), pour extraire un enregistrement unique par la clé.

Les méthodes d’extraction des objets domaines Grails peuvent aussi être construites de manière dynamique. Ce concept est difficile à comprendre si on ne le voit pas. C’est pourquoi je démontre généralement les finders dynamiques Grails aux clients potentiels en activant la console Grails, par la commande suivante :

grails console

Puis, après avoir demandé au client quel sous-ensemble de l’information de ses fichiers de données il souhaite voir, j’entre un finder dynamique, qui, pour l’essentiel, fait un SETLL et READE DS des enregistrements de la commande numéro 194710. Le finder range les résultats dans une matrice appelée list, et la list.each produit le numéro de ligne et la description de OrderDetail. Si le client avait souhaité voir tous les articles de la commande à partir de 14, j’aurais utilisé :

OrderDetail.findAllByItemNumberLike(« 14% »)

Liage des données

Le développement sur le Web effectue le liage les données d’entrée du formulaire HTML aux composants de gestion. Grails simplifie cela au moyen d’un paramètre standard appelé tout simplement params et une fonction des classes Groovy appelée properties. Le paramètre params est une association de paires name/value qui contient l’entrée provenant du formulaire HTML. Comme il est pratique de voir ces valeurs, je place souvent la ligne de code suivante comme première instruction de chaque action du contrôleur :

println « params: $params »

Pour illustrer, quand l’utilisateur cliquera sur le lien show sur la page list, la commande println montrera ceci sur la console :

params: [action:show, shipmentNumber:0,
  companyCode:01, controller:orderDetail,
  orderNumber:178100, lineNumber:20]

Observez comment on se passe de la clé complète nécessaire pour extraire un enregistrement détail de la commande. Pour l’action edit, l’association (map) params contient toutes les valeurs provenant de la page d’entrée. Ces quelques dizaines de valeurs de champs de formulaire doivent être introduites dans les attributs d’une instance de la classe de domaine OrderDetail. Grails fait cela très facilement à l’aide de la ligne suivante dans l’action update :

orderDetail.properties = params

Validation

Mais comme les valeurs de formulaire HTML entrées au hasard par un utilisateur sont introduites dans les attributs de domaine, elles doivent bien sûr être validées. Grails vérifiera toujours que les types de données conviennent (c’était la source de l’erreur dans la figure 6.) Pour une validation propre à l’application, Grails exécute la logique de contraintes présentée dans la figure 1.

Mise à jour de la base de données

Les mises à jour et les insertions dans votre base de données se font avec la méthode save de la classe de domaine Grails (comme vous pouvez le voir dans les actions update et save dans votre classe de contrôleur). Mais un problème se pose avec les anciens fichiers base de données : Grails, par convention, utilisera la vacuité d’une clé pour déterminer s’il faut appliquer une insertion ou une mise à jour à la base de données. Tout est bien quand la clé est autogénérée (un comportement standard sur les tables modernes), mais nos anciens fichiers reçoivent la clé de la part de l’application. Donc, Grails pourrait prendre la mauvaise décision, à moins que nous n’ayons utilisé un paramètre save-method qui impose une insertion. L’action save dans le contrôleur fait cela avec l’instruction suivante :

orderDetail.save(insert:orderDetail.newEntity)

Vue et contrôleur

La vue est un ensemble de HTML sous la forme de Groovy Server Pages (GSP). Elles incluent show, edit, list, et create. Une GSP est, en réalité, une JavaServer Page (JSP) qui accepte la syntaxe Groovy. Mais les GSP, tout comme PHP, sont faciles à coder. Les données variables sont facilement affichées au moyen de l’opérateur Groovy dollar :

<td>${ordDtl.lineNumber}</td>

La vue obtient les variables de la part du contrôleur. Par exemple, voici le code complet pour l’action qui traite un clic du lien show :

def show = {
 return [ordDtl : getOrderDetail(params) ]
}

La logique controller-to-view Grails prend l’association entre accolades retournée des paires name/value et les passe à la vue qui a le même nom que son action (dans ce cas, show).
Un aspect sympa de Grails est que vous pouvez changer les pages de vue GSP et la logique du contrôleur pendant que le serveur est actif ! De quoi accélérer le développement des applications.