TOC

Introduction à la lecture en Java

Introduction à la lecture en Java

1. Vue d'ensemble

Le but de ce didacticiel d’introduction est d’explorer le Play Framework et de déterminer comment créer une application Web avec celui-ci.

Play est un framework d’applications Web à haute productivité pour les langages de programmation dont le code est compilé et exécuté sur la machine virtuelle Java, principalement Java et Scala. Il intègre les composants et les API nécessaires au développement d'applications Web modernes.

2. Configuration du cadre de jeu

Passons auxofficial page du framework Play et téléchargez la dernière version de la distribution. Au moment de ce tutoriel, la version la plus récente est la version 2.7.

Nous allons télécharger le dossier zip du didacticiel Play Java Hello World et décompresser le fichier dans un emplacement pratique. À la racine de ce dossier, nous trouverons un exécutablesbt que nous pouvons utiliser pour exécuter l'application. Alternativement, nous pouvons installersbt à partir de leursofficial page.

Pour utilisersbt  du dossier téléchargé, procédons comme suit: 

cd /path/to/folder/
./sbt run

Notez que nous exécutons un script dans le répertoire courant, d'où l'utilisation de la syntaxe./.

Si nous installonssbt,, nous pouvons l'utiliser à la place: 

cd /path/to/folder/
sbt run

Après avoir exécuté cette commande, nous verrons une instruction qui dit "(Le serveur a démarré, utilisez Entrée pour arrêter et revenir à la console…)". Cela signifie que notre application est prête. Par conséquent, nous pouvons maintenant accéder àhttp://localhost:9000 où une page de bienvenue Play nous sera présentée:

image

3. Anatomie des applications de jeu

Dans cette section, nous allons mieux comprendre comment une application Play est structurée et à quoi sert chaque fichier et répertoire de cette structure.

Si vous souhaitez vous mettre immédiatement au défi avec un exemple simple, passez à la section suivante.

Voici les fichiers et dossiers que nous trouvons dans une application typique de Play Framework: 

├── app                      → Application sources
│   ├── assets               → Compiled Asset sources
│   │   ├── javascripts      → Typically Coffee Script sources
│   │   └── stylesheets      → Typically LESS CSS sources
│   ├── controllers          → Application controllers
│   ├── models               → Application business layer
│   └── views                → Templates
├── build.sbt                → Application build script
├── conf                     → Configurations files and other non-compiled resources (on classpath)
│   ├── application.conf     → Main configuration file
│   └── routes               → Routes definition
├── dist                     → Arbitrary files to be included in your projects distribution
├── lib                      → Unmanaged libraries dependencies
├── logs                     → Logs folder
│   └── application.log      → Default log file
├── project                  → sbt configuration files
│   ├── build.properties     → Marker for sbt project
│   └── plugins.sbt          → sbt plugins including the declaration for Play itself
├── public                   → Public assets
│   ├── images               → Image files
│   ├── javascripts          → Javascript files
│   └── stylesheets          → CSS files
├── target                   → Generated files
│   ├── resolution-cache     → Information about dependencies
│   ├── scala-2.11
│   │   ├── api              → Generated API docs
│   │   ├── classes          → Compiled class files
│   │   ├── routes           → Sources generated from routes
│   │   └── twirl            → Sources generated from templates
│   ├── universal            → Application packaging
│   └── web                  → Compiled web assets
└── test                     → source folder for unit or functional tests

3.1. Le répertoireapp

Ce répertoire contient le code source Java, les modèles Web et les sources d’actifs compilées, c’est-à-dire toutes les sources et toutes les ressources exécutables.

Le répertoireapp contient quelques sous-répertoires importants, chacun contenant une partie du modèle architectural MVC:

  • models - c'est la couche métier de l'application, les fichiers de ce paquet modéliseront probablement nos tables de base de données et nous permettront d'accéder à la couche de persistance

  • views - tous les modèles HTML qui peuvent être rendus dans le navigateur contiennent ce dossier

  • controllers - un sous-répertoire dans lequel nous avons nos contrôleurs. Controllers sont des fichiers source Java contenant des actions à exécuter pour chaque appel d'API. Actions sont des méthodes publiques qui traitent les requêtes HTTP et renvoient les mêmes résultats que les réponses HTTP

  • assets– un sous-répertoire qui contient des éléments compilés tels que CSS et javascript. Les conventions de dénomination ci-dessus sont flexibles, nous pouvons créer nos packages, par exemple. un packageapp/utils. Nous pouvons également personnaliser le nom du packageapp/com/example/controllers

Il contient également des fichiers et des répertoires facultatifs en fonction des besoins de l’application concernée.

3.2. Le répertoirepublic

Les ressources stockées dans le répertoirepublic sont des actifs statiques qui sont servis directement par le serveur Web.

Ce répertoire contient généralement trois sous-répertoires pour les images, les fichiers CSS et JavaScript. Il est recommandé d’organiser les fichiers d’éléments comme celui-ci par souci de cohérence dans toutes les applications Play.

3.3. Le répertoireconf

Le répertoireconf  contient les fichiers de configuration de l'application. Leapplication.conf  est l'endroit où nous placerons la plupart des propriétés de configuration de l'application Play. Nous définirons les points de terminaison de l'application dansroutes.

Si l'application nécessite des fichiers de configuration supplémentaires, ils doivent être placés dans ce répertoire.

3.4. Le répertoirelib

Le répertoirelib est facultatif et contient des dépendances de bibliothèque non gérées. Si nous avons des fichiers jars non spécifiés dans le système de construction, nous les mettons dans ce répertoire. Ils seront ajoutés automatiquement au chemin de classe de l'application.

3.5. Le fichierbuild.sbt

Lebuild.sbt file est le script de construction de l'application. C'est ici que nous listons les dépendances nécessaires à l'exécution de l'application, telles que les bibliothèques de test et de persistance.

3.6. Le répertoireproject

Tous les fichiers qui configurent le processus de construction basé sur SBT se trouvent dans le répertoireproject.

3.7. Le répertoiretarget

Ce répertoire contient tous les fichiers générés par le système de construction - par exemple, tous les fichiers.class.

Après avoir vu et exploré la structure de répertoires de l'exemple Play Framework Hello World que nous venons de télécharger, nous pouvons maintenant passer en revue les principes fondamentaux du cadre à l'aide d'un exemple.

4. Exemple simple

Dans cette section, nous allons créer un exemple très basique d'application Web. Nous utiliserons cette application pour nous familiariser avec les principes de base du framework Play.

Au lieu de télécharger un exemple de projet et de construire à partir de celui-ci,let’s see another way we can create a Play Framework application, using the sbt new command.

Ouvrons une invite de commande, accédez à l'emplacement de votre choix et exécutons la commande suivante: 

sbt new playframework/play-java-seed.g8

Pour celui-ci, nous devons avoir installésbt already comme expliqué dansSection 2.

La commande ci-dessus nous demandera d’abord un nom pour le projet. Ensuite, il vous demandera le domaine (à l’inverse, de même que la convention de dénomination des paquets en Java) qui sera utilisé pour les paquets. On appuie surEnter sans taper de nom si on veut garder les valeurs par défaut qui sont données entre crochets.

L'application générée avec cette commande a la même structure que celle générée précédemment. Nous pouvons donc continuer à exécuter l'application comme nous l'avons fait précédemment: 

cd /path/to/folder/
sbt run

La commande ci-dessus, une fois l'exécution terminée,will spawn a server on port number 9000 to expose our API, à laquelle nous pouvons accéder viahttp://localhost:9000. Nous devrions voir le message «Bienvenue à jouer» dans le navigateur.

Our new API has two endpoints that we can now try out in turn from the browser. Le premier - que nous venons de charger - est le point de terminaison racine, qui charge une page d'index avec le "Welcome to Play!" message.

Le second, àhttp://localhost:9000/assets,, est destiné au téléchargement de fichiers depuis le serveur en ajoutant un nom de fichier au chemin. Nous pouvons tester ce point de terminaison en récupérant le fichierfavicon.png , qui a été téléchargé avec l'application, àhttps://localhost:9000/assets/images/favicon.png.

5. Actions et contrôleurs

Une méthode Java dans une classe de contrôleur qui traite les paramètres de requête et produit un résultat à envoyer au client est appelée une action.

Un contrôleur est une classe Java qui étendplay.mvc.Controller qui regroupe logiquement les actions qui peuvent être liées aux résultats qu'elles produisent pour le client.

Passons maintenant àapp-parent-dir/app/controllers et faisons attention àHomeController.java.

L'action d'indexation deHomeController renvoie une page Web avec un simple message de bienvenue: 

public Result index() {
    return ok(views.html.index.render());
}

Cette page Web est le modèle par défaut deindex dans le package de vues: 

@main("Welcome to Play") {
  
Welcome to Play!

}

Comme indiqué ci-dessus, le spageindex appelle le modèlemain. Le modèle principal gère ensuite le rendu des balises d'en-tête de page et de corps. Il prend deux arguments: unString  pour le titre de la page et unHtml object à insérer dans le corps de la page. 

@(title: String)(content: Html)



    
        @* Here's where we render the page title `String`. *@
        @title
        
        
    
    
        @* And here's where we render the `Html` object containing
         * the page content. *@
        @content

Modifions un peu le texte du fichierindex: 

@main("Welcome to example") {
  
Welcome to Play Framework Tutorial on example!

}

Recharger le navigateur nous donnera une rubrique en gras: 

Welcome to Play Framework Tutorial on example!

Nous pouvons supprimer complètement le modèle en supprimant la directiverender  dans la méthodeindex() desHomeController afin de pouvoir renvoyer directement du texte brut ou du texte HTML: 

public Result index() {
    return ok("REST API with Play by example");
}

Après avoir modifié le code, comme indiqué ci-dessus, nous n'aurons que le texte dans le navigateur. Ce sera juste du texte brut sans HTML ni style: 

REST API with Play by example

Nous pourrions tout aussi bien produire du HTML en enveloppant le texte dans les balises d'en-tête<h1></h1>, puis en passant le texte HTML à la méthodeHtml.apply. N'hésitez pas à jouer avec elle.

Ajoutons un point de terminaison/example/html dansroutes: 

GET    /example/html    controllers.HomeController.applyHtml

Créons maintenant le contrôleur qui gère les requêtes sur ce point de terminaison: 

public Result applyHtml() {
    return ok(Html.apply("
This text will appear as a heading 1
"));
}

Lorsque nous visiteronshttp://localhost:9000/example/html, nous verrons le texte ci-dessus formaté en HTML.

Nous avons manipulé notre réponse en personnalisant le type de réponse. Nous examinerons cette fonctionnalité plus en détail dans une section ultérieure.

Nous avons également vu deux autres caractéristiques importantes du Play Framework.

Premièrement, le rechargement du navigateur reflète la version la plus récente de notre code; c'est parce que noscode changes are compiled on the fly.

Deuxièmement, Play nous fournit des méthodes d'assistance pour les réponses HTTP standard dans la classeplay.mvc.Results. Un exemple est la méthodeok(), qui renvoie une réponse HTTP 200 OK à côté du corps de la réponse que nous lui passons en paramètre. Nous avons déjà utilisé la méthode d'affichage du texte dans le navigateur.

Il existe d'autres méthodes d'assistance telles quenotFound() etbadRequest() dans la classeResults.

6. Manipuler les résultats

Nous avons étébenefiting from Play’s content negotiation feature sans même nous en rendre compte. Lire déduit automatiquement le type de contenu de la réponse à partir du corps de la réponse. C'est pourquoi nous avons pu renvoyer le texte dans la méthodeok: 

return ok("text to display");

Et alors Play définirait automatiquement l'en-têteContent-Type surtext/plain. Bien que cela fonctionne dans la plupart des cas, nous pouvons prendre le contrôle et personnaliser l'en-tête de type de contenu.

Soitcustomize the response for HomeController.customContentType action to text/html: 

public Result customContentType() {
    return ok("This is some text content").as("text/html");
}

Ce modèle concerne tous les types de contenu. Selon le format des données que nous passons à la méthode d'aideok, nous pouvons remplacertext/html partext/plain ouapplication/json.

Nous pouvons faire quelque chose de similaire pour définir les en-têtes: 

public Result setHeaders() {
    return ok("This is some text content")
            .as("text/html")
            .withHeader("Header-Key", "Some value");
}

7. Conclusion

Dans cet article, nous avons exploré les bases du Play Framework. Nous avons également pu créer une application Web Java de base à l'aide de Play.

Comme d'habitude, le code source de ce tutoriel est disponibleover on GitHub.

Related