Bienvenue dans le cinquième article de notre série sur le framework Grails ! Nous allons aborder aujourd’hui les contrôleurs et les vues.
Nous partons du principe que vous avez déjà suivi les quatre articles précédents : Introduction à Grails, Grails partie 2 : création d’une application basique, Grails partie 3 : La validation et Grails partie 4 : Les relations.
Nous allons en premier lieu analyser le contenu d’un contrôleur, puis nous verrons les éléments importants à connaitre sur les vues.
Les contrôleurs
Ouvrez un de vos contrôleurs (ceux-ci sont tous identiques, mis à part le type des objets manipulés à l’intérieur) et commençons par le premier élément :
[pastacode lang=”java” message=”” highlight=”” provider=”manual”]
static allowedMethods = [save: "POST", update: "PUT", delete: "DELETE"][/pastacode]
Pour configurer les types de requêtes supportées par les méthodes (ou closures), Grails nécessite de déclarer un objet de type java.util.Map au début du contrôleur. Cette configuration s’oppose à celle de Spring MVC, par exemple, qui nécessite de mettre des annotations sur chaque méthode.
Dans cet objet allowMethods, nous spécifions que les closures save, update et delete supporteront respectivement les requêtes POST, PUT et DELETE. Toutes les autres supporteront par défaut les requêtes GET.
Regardons maintenant la première méthode de ce contrôleur :
[pastacode lang=”java” message=”” highlight=”” provider=”manual”]
def index(Integer max) {
params.max = Math.min(max ?: 10, 100)
respond Runner.list(params), model:[runnerInstanceCount: Runner.count()]
}[/pastacode]
Pour comprendre pleinement le fonctionnement de cette closure, il faut tout d’abord savoir comment Grails construit ses URL. Si vous accédez à la liste des Runners, vous aurez l’URL suivante: http://localhost:8080/RaceTrack/runner/index. De plus, si vous consultez le détail d’un Runner, vous aurez alors ceci: http://localhost:8080/RaceTrack/runner/show/1. Les URL sont donc construites de la manière suivante :
http://domaine:port/Application/Controleur/methode/parametre
L’adresse de cette méthode index sera par conséquent : http://localhost:8080/RaceTrack/runner/index
À savoir que vous pouvez omettre index, puisqu’il s’agit de la vue par défaut.
Cette méthode retourne deux paramètres (en utilisant le mot-clé respond). La vue utilisée dans notre cas sera RaceTrack/grails-app/view/runner/index.gsp. La closure retourne une liste de Runners de taille max, et le nombre total de Runners présents dans la base de données (et qui sera utile à la vue pour la gestion de la pagination). Pour utiliser ce paramètre max, vous devez le renseigner tout simplement à la fin de l’URL: http://localhost:8080/RaceTrack/runner/index?max=10.
Il vous reste maintenant à comprendre deux éléments de plus dans les contrôleurs avant d’en saisir la totalité.
Vous aurez probablement remarqué que plusieurs appels sont effectués à une méthode appelée respond:
[pastacode lang=”java” message=”” highlight=”” provider=”manual”]
respond runnerInstance, [status: CREATED][/pastacode]
Cet appel se situe dans la closure save. Il permet d’afficher la vue create, tout en lui passant une instance de Runner. Cette méthode prend donc en premier paramètre l’objet à afficher et en deuxième paramètre une map d’arguments (un status created dans notre cas). Dans cette map vous pouvez éventuellement spécifier les attributs view et model pour personnaliser la vue et le modèle à afficher.
Une dernière instruction doit vous rester mystérieuse :
[pastacode lang=”java” message=”” highlight=”” provider=”manual”]
flash.message = message(code: 'default.created.message', args: [message(code: 'runner.label', default: 'Runner'), runnerInstance.id])[/pastacode]
Ici, Grails stocke un message dans une variable flash.message. Le texte de ce message est renseigné dans le fichier messages_fr.properties que nous avons déjà abordé dans la partie 3. Cet objet flash est principalement utilisé pour les messages d’erreur et survivra uniquement à une seule redirection. Si vous jetez un œil à la vue create, vous pourrez y voir que cette variable message y est bien utilisée :
[pastacode lang=”java” message=”” highlight=”” provider=”manual”]
${flash.message}[/pastacode]
Nous n’allons pas détailler plus le reste du contrôleur, vous avez dorénavant toutes les connaissances nécessaires pour le comprendre par vous-même.
Les vues
Les tags
Nous allons maintenant analyser le fonctionnement des Groovy Server Pages (GSP). Celles-ci ressemblent beaucoup aux JSP que vos connaissez probablement.
Commençons par ouvrir la page d’accueil de notre site : RaceTrack/grails-app/view/index.gsp. Comme vous pouvez le voir, cela ressemble ni plus ni moins à un fichier HTML. Il y a toutefois deux principales subtilités qui vont vous faciliter le travail :
- Des expressions utilisant la syntaxe ${…}. Celle-ci permet l’utilisation d’objets et variables dans votre vue. Par exemple, si le contrôleur vous renvoie un objet runner, vous pourrez afficher le nom de celui-ci en faisant simplement ${runner?.lastName} (souvenez-vous, le point d’interrogation permet d’éviter les NullPointerException).
- Des tags de la forme <g:… >. Ceux-ci sont des tags Grails. Ils vous permettront notamment de faire des conditions et des boucles. Nous pouvons par exemple en voir deux à la fin de notre GSP :
[pastacode lang=”markup” message=”” highlight=”” provider=”manual”]
<g:each var="c" in="${grailsApplication.controllerClasses.sort { it.fullName } }">
<li class="controller"><g:link controller="${c.logicalPropertyName}">${c.fullName}</g:link></li>
</g:each>[/pastacode]
La première, <g:each>, permet de parcourir une collection. Le deuxième, <g:link>, permet de réaliser simplement un lien vers un autre élément de votre application, un contrôleur par exemple.
Vous pourrez en apercevoir d’autres dans différentes GSP, dont <g:if>, <g:else>, <g:form>… Tous ont leur fonctionnalité très utile qui vous permettra de construire votre GSP facilement. Pour connaître leurs paramètres, il vous suffira d’utiliser le raccourci d’Eclipse Ctrl + Espace à l’intérieur de ceux-ci, ou d’utiliser la documentation officielle et sa barre latérale pour en avoir une liste et des exemples d’utilisation.
Les templates
Voyons maintenant une autre spécificité des GSP, les templates. Souvenez-vous du premier article de cette série, nous avions vu que Grails utilise le framework SiteMesh. Celui-ci va nous permettre d’appliquer le principe Don’t Repeat Yourself. Par défaut, il existe un template global utilisé dans toutes les GSP. Vous pouvez voir son appel dans la balise head de votre index.gsp.
[pastacode lang=”markup” message=”” highlight=”” provider=”manual”]
<meta name="layout" content="main"/>[/pastacode]
Cette page d’index inclut donc le layout main. Ouvrons celui-ci pour voir de quoi il est composé. Vous pouvez y voir tous les éléments qui seront répétés sur chacune de nos pages, notamment l’inclusion des feuilles de style et des scripts. Vous pouvez également voir deux balises intéressantes:
[pastacode lang=”markup” message=”” highlight=”” provider=”manual”]
<g:layoutHead/>[/pastacode]
[pastacode lang=”markup” message=”” highlight=”” provider=”manual”]
<g:layoutBody/>[/pastacode]
Celles-ci indiquent que le header et le body de nos autres vues sont inclus à ces endroits précis. Vous pourrez le vérifier en inspectant le code HTML d’une page dans votre navigateur.
Il existe également des templates partiels. Ceux-ci sont nommés de la manière suivante : _templateName.gsp. Si vous observez les GSP qui ont été générées par Grails, vous verrez que des templates partiels sont déjà présents. Il s’agit en effet des formulaires. Ceux-ci étant utilisés dans les vues create et edit, il est judicieux de les inclures dans des templates pour ne pas se retrouver avec de la duplication de code. Pour en inclure un dans une GSP, il vous suffira d’écrire :
[pastacode lang=”markup” message=”” highlight=”” provider=”manual”]
<g:render template="templateName"/>[/pastacode]
Ainsi nous avons vu dans cet article le fonctionnement des contrôleurs et des vues dans Grails. Si vous souhaitez aller plus loin, sachez qu’il est possible de créer vos propres tags pour les utiliser dans vos GSP. Il est également bon à savoir que vous pouvez modifier les vues et contrôleurs générés par défaut en exécutant la commande install-templates puis en éditant les fichiers qui viennent d’être créés dans RaceTrack/src/templates/scaffolding.
Ceci conclut notre série d’articles sur le framework Grails. Si vous souhaitez approfondir vos connaissances, notamment sur les tests unitaires et la sécurité, rendez-vous sur la documentation officielle et/ou sur le livre Getting Started with Grails Second Edition.
Sources
http://www.infoq.com/minibooks/grails-getting-started
