3. Environnement Java#

Ce chapitre est particulier: il explique comment installer et configurer tous les outils de notre environnement de travail pour le développement d’une application Web, à l’exception de ce qui concerne la base de données: nous y reviendrons plus tard.

Comme nous allons travailler en Java, la présence d’un environnement de développement Java sur votre poste de travail est un pré-requis. En principe, ce devrait déjà être le cas, sinon allez sur la plateforme Java maintenue par Oracle et récupérez une version récente (supérieure ou égale à 6) du Java Development Kit (JDK). L’installation se fait en quelques clics.

_images/EnvJava.png — Figure 1: Les outils de notre environnement#

La figure Les outils de notre environnement résume l’environnement que nous utilisons. La logique de notre processus de développement est la suivante:

Une application est gérée par un projet de l’environnement de développement intégré (IDE) Eclipse; les fichiers correspondant à ce projet sont stockés, localement, sur votre disque dans un répertoire workspace affecté à Eclipse.
Quand nous sommes satisfaits d’un stade du développement, nous pouvons tester notre application en la déployant vers un serveur d’application Web; dans notre cas, ce serveur est Tomcat.
Comme il s’agit d’une application Web, nous devons visualiser des pages HTML avec un client web; il en existe un intégré à Eclipse, mais il est plus agréable à la longue d’utiliser un navigateur complet comme Firefox ou Chrome.

Eclipse est donc notre outil de contrôle général: il permet d’éditer le code, de contrôler son exécution sur le serveur, et même de visualiser un client Web. L’apprentissage des commandes Eclipse se fera tout au long des sessions. Comme tout apprentissage, il peut sembler fastidieux et frustrant au départ (les menus à parcourir pour trouver la bonne commande…), mais on se trouve rapidement récompensé.

Note

Si vous préferez utiliser un autre IDE, par exemple NetBeans, cela ne pose pas de problème. À vous bien entendu d’assumer dans ce cas cet apprentissage particulier.

Les sessions de ce chapitre consistent à installer les outils décrits ci-dessus, et à tester un premier projet, minimal.

S1: Serveur d’application: Tomcat#

Supports complémentaires :

Diapos pour la session « S1 : Serveur d’application: Tomcat »

Vidéo associée : https://mediaserver.lecnam.net/permalink/v125f3576b4a1wj6eg0n/

Notre application web écrite en Java doit être intégrée à un serveur Web apte à interagir avec elle correctement. Nous allons utiliser Tomcat, un logiciel libre de droit proposé par la Fondation Apache.

Note

Tomcat n’est pas un serveur d’application JEE complet à proprement parler, mais il suffit largement à nos besoins. Pour un déploiement professionnel, un serveur comme Glassfish, WebSphere ou autre est préférable.

Comme d’habitude, l’installation consiste à se rendre sur le site de Tomcat. Allez à l’espace de téléchargement et choisissez la dernière version stable de Tomcat (au moins la 7) pour votre système.

On obtient une archive qui, une fois décompressée, donne un répertoire racine nommé apache-tomcat-xxx où xxx est un numéro de version.

Simplifions: renommez ce répertoire en tomcat et placez-le dans votre répertoire Home. Bien entendu, si vous pensez pouvoir vous en tirer avec une approche plus générale, faites!

Nous n’avons pas pour ambition de devenir des administrateurs émérites de Tomcat. Notre objectif est d’être capable d’installer et de de tester notre application sur le serveur local. Il peut quand même être intéressant (et surtout utile) de jeter un oeil à l’organisation des répertoires de Tomcat: voir la figure Les répertoires de Tomcat (ici, version 7).

le répertoire bin contient des programmes exécutables et notamment des scripts de démarrage et d’arrêt de Tomcat (startup.sh et shutdown.sh);
conf contient les fichiers de configuration;
log contient les fichiers log;
enfin, webapps est le répertoire contenant les applications gérées par le serveur Tomcat.

_images/tomcat-dirs.png — Figure 2: Les répertoires de Tomcat (ici, version 7)#

Pour pouvoir démarrer et stopper Tomcat sans avoir à se déplacer dans le répertoire bin à chaque fois, il peut être utile de placer le chemin d’accès à ce dernier dans la variable d’environnement PATH. Par exemple, sous Linux ou Mac OS X:

export PATH=$PATH:$HOME/tomcat/bin

Placez cette commande dans un fichier d’initialisation de votre environnement (par exemple .bashrc si vous utilisez un environnement BASH shell).

Pas besoin d’en faire plus, au moins à ce stade (pour un déploiement réel il faudrait bien sûr se pencher sérieusement sur la question de la configuration de Tomcat). En fait nous allons piloter le serveur à partir d’Eclipse qui sera vraiment notre tour de contrôle.

Vérification: lancement et accès à Tomcat

Lancez Tomcat avec la commande startup.sh. Les messages d’information ou d’erreur (éventuelle) sont placés dans des fichiers dans le répertoire tomcat/logs. Si tout se passe bien, Tomcat se lance et se met en écoute sur le port 8080. Vous devriez avec votre navigateur accéder à l’URL http://localhost:8080 et obtenir une page d’accueil donnant accès à la documentation. Rien ne vous empêche de lire cette dernière si vous avez un peu de temps.

Arrêtez Tomcat avec la commande shutdown.sh quand vous avez terminé.

S2: L’environnement de développement: Eclipse#

Supports complémentaires :

Diapos pour la session « S2 : L’environnement de développement Eclipse »

Vidéo associée : https://mediaserver.lecnam.net/permalink/v125f3585f428qwbgftq/

Tout développement peut être vu de manière simpliste comme une séquence de tâches élémentaires: édition du code, compilation, test, correction, etc. On peut effectuer ces tâches avec des outils rudimentaires comme le Bloc Note Windows, vi sous Unix, et un terminal pour entrer des lignes de commande… Heureusement, il existe des environnements de développement dédiés qui allègent considérablement toutes ces tâches. Inutile d’énumérer tous leurs avantages: vous serez rapidement convaincus à l’usage.

Nous allons utiliser l’un des plus connus, Eclipse (un autre candidat sérieux pour du développement Java est Netbeans).

Installation#

Si Eclipse n’est pas déjà présent sur votre poste, rendez-vous sur le site https://www.eclipse.org/downloads/packages/ (section : Eclipse IDE for Enterprise Java and Web Developers) et choisissez l’installeur correspondant à votre système (Windows, MacOS, Linux).

Renommez le répertoire racine obtenu en décompressant l’archive eclipse (par simplicité) et placez-le dans votre répertoire racine (par simplicité encore).

Et voilà. Dans le répertoire eclipse vous trouverez un exécutable que vous pouvez lancer pour bénéficier de l’affichage de la page d’accueil. Maintenant, il faut faire un peu de configuration.

Configuration#

Nous allons pré-régler quelques options utiles pour éviter des problèmes ultérieurs.

Encodage UTF-8#

Tous nos documents vont être encodés en UTF-8. C’est une bonne habitude à prendre pour éviter des problèmes d’affichage (et aussi éviter de se poser des questions).

accédez au menu Préférences d’Eclipse, en principe sous le menu Windows (sauf sous Mac OS…)

entrez encoding dans la fonction de recherche; une liste d’options s’affiche;

pour chaque option, repérer le formulaire de réglage de l’encodage, et choisissez UTF-8.

_images/eclipse-encoding.png — Figure 3: Choix de l’encodage par défaut#

La figure Choix de l’encodage par défaut montre une des fenêtres de configuration en cours de paramétrage.

Réglages de l’éditeur de code#

Vous pouvez (toujours dans les Préférences), configurer l’éditeur de code, par exemple pour afficher les numéros de ligne. Accédez à la fenêtre General -> Editors -> Text Editor (figure Réglage de l’éditeur de code). Notez que le sous-menu Spelling permet d’activer/désactiver la correction orthographique, à votre convenance.

_images/eclipse-editor.png — Figure 4: Réglage de l’éditeur de code#

Association Eclipse/Tomcat#

Pendant nos développements, nous testerons chaque étape en déployant l’application sur le serveur Tomcat. Eclipse est capable de faire cela automatiquement, et même de prendre en compte en continu les modifications du code pour les installer dans le serveur.

Il faut au préalable configurer un environnement d’exécution (Runtime environment) dans Eclipse. pour cela, toujours à partir du menu Préférences, accéder à Servers -> Runtime environments. On obtient la fenêtre de la figure Configuration d’un serveur dans Eclipse.

_images/eclipse-addserver.png — Figure 5: Configuration d’un serveur dans Eclipse#

Suivre le bouton Add, ce qui mène à la fenêtre de la figure Choix du serveur dans Eclipse. Sélectionner Apache Tomcat dans la liste de tous les conteneurs JEE connus par Eclipse. La fenêtre suivante vous demandera le répertoire d’installation de Tomcat, autrement dit votre répertoire Home si vous avez scrupuleusement suivi les instructions ci-dessus.

_images/eclipse-chooseserver.png — Figure 6: Choix du serveur dans Eclipse#

Note

Cocher l’option Create a local server n’est utile que si vous partagez l’installation de Tomcat avec d’autres utilisateurs ou d’autres applications. Dans ce cas il peut être gênant de démarrer/stopper le serveur pour vos tests, en perturbant les autres. Si vous utilisez une machine personnelle, pas de problème.

Et voilà, la beauté de la chose est que vous pouvez maintenant démarrer ou stopper votre instance de Tomcat depuis Eclipse. Ajouter une vue Server dans la fenêtre en bas à droite, avec le menu Window -> Show view -> Servers comme montré sur la figure Démarrage/arrêt de Tomcat depuis Eclipse. Un onglet Servers apparaît avec la liste des serveurs configurés à l’étape précédente. Cliquez sur le nom du serveur. La flèche verte dans la barre des onglets sert à démarrer un serveur, un rectangle rouge à le stopper.

_images/eclipse-showservers.png — Figure 7: Démarrage/arrêt de Tomcat depuis Eclipse#

Nous voici dotés d’un environnement d’exécution prêt à l’emploi. Il ne reste plus qu’à lui fournir une application.

Vérification: pilotage de Tomcat par Eclipse.

Vérifiez que vous pouvez lancer Tomcat avec Eclipse, accéder à l’URL http://localhost:8080 avec votre navigateur préféré, puis stopper Tomcat (avec Eclipse).

S3: Création d’une application JEE#

Supports complémentaires :

Diapos pour la session « S3 : Création d’une application JEE »

Vidéo associée : https://mediaserver.lecnam.net/permalink/v125f3585f4a8jlzrhns/

Le moment est enfin venu de créer notre première application JEE avec notre Eclipse tout frais. Nous allons créer une application par défaut et faire quelques essais pour vérifier que tout fonctionne.

Création de l’application#

Dans le menu Eclipse, accédez à File -> New -> Project. On obtient la fenêtre de la figure Choix du type d’un nouveau projet.

_images/newproject.png — Figure 8: Choix du type d’un nouveau projet#

Vous devriez trouver un choix “Web” et un sous-choix “Dynamic Web Project”. C’est ce dernier qui nous intéresse.

Important

Si vous ne trouvez pas ces choix, c’est que vous utilisez un package Eclipse qui n’est pas équipé des outils JEE. Revoyez votre installation, demandez de l’aide sur Google ou à votre enseignant préféré…

Vous accédez alors à une fenêtre de création de projet (figure La fenêtre de création de projet). Deux options sont importantes:

le nom du projet: chosissez ce qui vous convient, disons test si vous n’êtes pas inspiré(e);

le Target Runtime: c’est le serveur/conteneur Java qui va vous permettre d’exécuter et de tester votre application; choisissez tout simplement le serveur que vous avez défini pendant la configuration d’Eclipse (ici il apparaît comme « Apache Tomcat v7.0 »).

_images/eclipse-createproject.png — Figure 9: La fenêtre de création de projet#

Pour le reste, gardez les choix par défaut et validez. Le projet doit alors apparaître dans la liste de gauche d’Eclipse. Cliquez-droit sur le nom du projet et choissez Run As -> Run on Server dans la liste des actions qui s’affiche. Vous devriez obtenir la fenêtre de la figure Exécuter une application sur un serveur.

_images/eclipse-runonserver.png — Figure 10: Exécuter une application sur un serveur#

Est-ce assez clair? Eclipse vous propose d’exécuter votre application (vide pour l’instant) sur un des serveurs pré-définis. Vous pouvez même indiquer que vous souhaitez toujours utiliser le même serveur, ce qui simplifie encore la tâche.

Choisissez votre serveur et continuez. La première fois, une fenêtre intermédiaire affiche la liste des applications configurées pour ce serveur (vérifiez que la vôtre y figure). Puis le serveur Tomcat est lancé, et votre application s’exécute, produisant une belle erreur HTTP 404. Pas d’inquiétude, c’est normal puisqu’à ce stade il n’existe aucune ressource à afficher.

_images/eclipse-appvide.png — Figure 11: Exécution d’une application (vide)#

Eclipse devrait afficher à peu près le contenu de la figure Exécution d’une application (vide). Nous avons

dans la liste de gauche (les projets), votre nouvelle application, ici nommée nsy135; notez un début d’arborescence, détaillé plus loin;

dans la fenêtre centrale, l’affichage par un navigateur embarqué dans Eclipse de la page d’accueil de votre application (soit une erreur 404 pour l’instant); vous pouvez aussi utiliser Firefox ou un autre navigateur, à l’adresse http://localhost:8080/nsy135 (évidemment, remplacez nsy135 par le nom de votre application);

enfin, la fenêtre au centre en bas montre, dans l’onglet Servers, votre instance de Tomcat en cours d’exécution.

Bravo, vous venez de mettre en place un environnement de développement et de test pour une application JEE. L’étape suivante consiste à lui donner du contenu.

Qu’est-ce qu’une application JEE?#

La figure suivante montre les répertoires constituant l’arborescence standard d’une application JEE telle qu’elle doit être fournie à un serveur d’application comme Tomcat. Le répertoire racine porte le nom de votre application (c’est par exemple nsy135 dans les manipulations précédentes). Vous avez ensuite un sous-répertoire WEB-INF qui contient, pour le dire brièvement, tout ce qui constitue la configuration et la partie dynamique de votre application. Ce répertoire n’est pas accessible par HTTP, et vous êtes donc assurés que le client Web (ou toute application externe en général) ne pourra pas récupérer les ressources qui s’y trouvent.

Notez par exemple que WEB-INF a un sous-dossier lib qui doit contenir toutes les librairies (jar ou autres) dont votre application dépend, et un sous-dossier classes contenant vos propres classes compilées. Le fichier web.xml est un fichier de configuration que nous n’avons pas besoin de modifier pour ce cours.

_images/J2ee-appdir.png — Figure 12: Structure d’une application JEE#

Tout ce qui n’est pas dans WEB-INF contient la partie statique/publique de votre application Web, autrement dit les ressources directement accessibles par une URL avec le navigateur: fichiers de style (CSS), code javascript, images, fichiers à télécharger éventuels, voire des pages HTML si votre application en contient.

Et dans Eclipse?#

Dans Eclipse, nous retrouvons cette structure, plus, bien entendu, le code de l’application lui-même, ce qui donne la hiérarchie de répertoires de la figure Structure d’une application JEE dans Eclipse. Tout ce qui est sous src/main/webapp correspond donc au contenu qui doit être « packagé » et transmis au serveur d’application (Tomcat). Ne vous inquiétez pas: c’est Eclipse qui s’en charge.

_images/Eclipse-appdir.png — Figure 13: Structure d’une application JEE dans Eclipse#

Quand on exécute une application, le code nouveau ou modifié est compilé, transféré sous src/main/webapp/WEB-INF/classes, puis l’ensemble du contenu de src/main/webapp/ est mis à disposition de Tomcat qui peut alors exécuter l’application. Tout cela se fait en un clic, sans avoir à se soucier des détails.

Premier pas: création d’un contenu statique#

Pour vérifier que tout fonctionne nous allons créer quelques fichiers statiques et les déployer. Avec le menu contextuel (bouton droit) de votre projet, choissisez la création d’un nouveau fichier HTML (figure Création d’un nouveau document HTML).

_images/newHTML.png — Figure 14: Création d’un nouveau document HTML#

Eclipse vous propose gentiment une structuration de base pour votre document. Complétez-là comme dans l’exemple ci-dessous, et sauvegardez le fichier dans src/main/webapp/maPage.html.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
     Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
 <head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  <title>Ma première page HTML</title>
 </head>
 <body>
  Ma première page HTML pour mon application JEE.
 </body>
</html>

What else? Et bien rien du tout. En accédant avec un navigateur à l’adresse http://localhost:8080/nsy135/maPage.html, vous devriez simplement voir s’afficher votre document HTML. Au passage, cela nous montre qu’Eclipse déploie automatiquement toute modification du code de l’application sur le serveur Tomcat associé, ce qui permet de vérifier tout de suite l’impact du développement.

Note

Cela suppose bien entendu que vous ayez au préalable exécuté votre application avec l’option Run on server comme indiqué précédemment.

Vous voici prêts à faire un premier exercice par vous-mêmes.

Exercice: installation d’un contenu statique complet.

Le but est de mettre en place un contenu statique complet, avec images, CSS, et peut-être Javascript. Pour cela, cherchez sur le Web un template de site Web prêt à l’emploi et gratuit. Vous en trouverez, par exemple, sur http://www.freecsstemplates.org. Récupérez le code et installez le template dans votre application JEE. Au final, http://localhost:8080/nsy135/ pourrait ressembler à la figure Notre application avec un modèle de site prêt à l’emploi., avec bien entendu le modèle que vous avez choisi (astuce: si le nom du fichier HTML n’est pas donné dans l’URL, Tomcat prend le fichier index.html si ce dernier existe). Profitez-en pour effectuer quelques modifications du code HTML ou CSS, et vous familiariser avec les commandes d’Eclipse.

_images/templateSite.png — Figure 15: Notre application avec un modèle de site prêt à l’emploi.#

Premier pas, bis: création d’un contenu dynamique#

Bien entendu, notre but est de développer une application dynamique qui va produire du contenu HTML à la volée en réponse aux actions utilisateurs. Cela demande une certaine méthodologie qui va être exposée par la suite, mais pour commencer nous allons créer un premier composant qui servira de base à des discussions initiales.

Ce premier composant est une servlet. Qu’est-ce qu’une servlet? Très concrètement, c’est un objet (Java) qui parle le HTTP. Il est pré-équipé d’une interface qui lui permet de recevoir des requêtes transmises par un client web, et de répondre à ce client, en général sous la forme d’un document HTML.

_images/archi-servlets.png — Figure 16: Un conteneur d’application et ses *servlets*#

Pendant l’exécution d’une application, une servlet est un objet contenu dans le serveur (d’où le nom de conteneur parfois donné à ce dernier), et la configuration de l’application indique à quelle URL cette servlet sait répondre. Quand une requête est transmise, le serveur (disons Tomcat), analyse l’URL, détermine quelle est la servlet appropriée, et transmet la requête à cette dernière (figure Un conteneur d’application et ses servlets).

Soyons concrets et créons une classe pour notre première servlet. Comme d’habitude, Eclipse est notre ami et nous facilite le travail. Choisissez l’option New dans le menu contextuel de votre application, et cherchez Servlet. Vous obtenez la fenêtre de la figure Fenêtre de création d’une servlet.

_images/creation-servlet.png — Figure 17: Fenêtre de création d’une *servlet*#

Il ne reste qu’à choisir le nom du package et celui de la classe. Disons que le premier est tests et le second Basique. On arrive alors à une seconde fenêtre, ci-dessous.

_images/creation-servlet2.png — Figure 18: Seconde fenêtre de création d’une *servlet*#

Ce qui est important ici c’est le champ URL mapping. Il indique le chemin qui va déterminer le déclenchement de la servlet par le conteneur d’application. Le choix par défaut est d’utiliser le nom de la classe (ici Basique). Cliquez directement sur Finish, et Eclipse crée la classe Java suivante, que nous copions intégralement pour pouvoir l’examiner.

package tests;

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
 * Servlet implementation class Basique
*/
@WebServlet(description = "Une première servlet pour voir ce qui se passe",
   urlPatterns = { "/Basique" })
public class Basique extends HttpServlet {
     private static final long serialVersionUID = 1L;

 /**
  * @see HttpServlet#HttpServlet()
  */
 public Basique() {
     super();
     // TODO Auto-generated constructor stub
 }

     /**
      * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
      */
     protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
             // TODO Auto-generated method stub
     }

     /**
      * @see HttpServlet#doPost(HttpServletRequest request, HttpServletResponse response)
      */
     protected void doPost(HttpServletRequest request, HttpServletResponse response)
       throws ServletException, IOException {
             // TODO Auto-generated method stub
     }
}

Donc, les lignes 2 à 8 importent les packages Java correspondant aux super-classes et interfaces des servlets. En particulier, la classe HttpServlet doit être la super-classe de nos servlets spécifiques:

public class Basique extends HttpServlet

En l’occurrence, Basique hérite du comportement général (dialogue via HTTP) défini par HtppServlet et doit implanter quelques méthodes abstraites sur lesquelles nous revenons plus loin.

L’annotation WebServlet définit l’association (mapping) entre une URL relative (à l’URL de l’application) et la servlet:

@WebServlet(description = "Une première servlet pour voir ce qui se passe",
 urlPatterns = { "/Basique" })

Il est possible d’associer plusieurs motifs d’URL (url patterns) à une servlet. Cette annotation peut également contenir des paramètres d’initialisation de la servlet. Nous n’allons pas détailler tout cela, au moins pour l’instant.

Important

Cette annotation n’existe que depuis la mise en place de la version 3 des servlets. Auparavant, tout devait être indiqué dans le fichier de configuration web.xml. Voici d’aileurs le contenu de ce fichier, pour une configuration équivalente. Les annotations évitent dans une large mesure d’avoir à éditer le fichier de configuration en parallèle au code java.

<?xml version="1.0" encoding="UTF-8"?>
<web-app
  xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
      version="3.0">
           <servlet>
                   <servlet-name>Basique</servlet-name>
                   <servlet-class>tests.Basique</servlet-class>
           </servlet>

           <servlet-mapping>
                   <servlet-name>Basique</servlet-name>
                   <url-pattern>/Basique</url-pattern>
           </servlet-mapping>
     </web-app>

Continuons l’exploration du code. Deux méthodes ont été automatiquement produites, avec un contenu vide: doGet et doPost. Comme leur nom le suggère, ces méthodes correspondent respectivement au code à exécuter en réponse à une requête HTTP GET ou POST. Nous allons compléter la méthode doGet de la manière suivante.

protected void doGet(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
        response.setContentType("text/html");
        response.setCharacterEncoding( "UTF-8" );
        PrintWriter out = response.getWriter();
        out.println("Ma première <i>servlet</i> s'exécute");
}

Notons tout d’abord que cette méthode reçoit deux paramètres représentant respectivement la requête HTTP reçues (request) et la réponse HTTP à transmettre (response). Le contenu des messages HTTP a été automatiquement analysé, structuré, et placé dans l’objet request. Réciproquement, le message HTTP à envoyer en réponse au programme client sera automatiquement mis en forme en fonction des informations que nous plaçons dans l’objet response. En d’autres termes, on n’a plus à se soucier du protocole HTTP, ou même du caractère distribué de l’application que nous réalisons.

Il nous reste à tester cette servlet. Pour cela, redémarrez Tomcat pour qu’il enregistre son existence (dans l’onglet Servers, utilisez la flèche verte). L’URL http://localhost:8080/nsy135/Basique devrait afficher le résultat de la figure Exécution de notre première servlet..

_images/ExecPremiereServlet.png — Figure 19: Exécution de notre première servlet.#

Résumé: savoir et retenir#

À ce stade, vous diposez déjà des bases pour réaliser une application Web: vous savez organiser une application, la tester avec Eclipse, Tomcat et un navigateur, et écrire du code Java traitant les requêtes et réponses HTTP. Avec beaucoup d’efforts, de tatonnements et d’erreurs, vous pourriez réaliser des fonctionnalités sophistiquées impliquant des accès à une base de données, la mise en forme de documents HTML complexes, etc.

Vous pourriez le faire, mais vous ne le ferez pas, car ce serait infiniment pénible et long. Comme le montrent les quelques commandes qui précèdent, l’écriture d’applications Web avec Java est maintenant très balisée, et des outils comme Eclipse apportent un gain de temps considérable pour appliquer automatiquement les bonnes pratiques mises au point pendant les dernières décennies. Imaginez juste à quel point il serait épouvantable de produire un long document HTML avec des séries d’appels ou.println…

Sans chercher à refaire l’histoire pas à pas, nous allons directement mettre en œuvre les meilleures pratiques et leurs techniques associées, en commençant par le motif de conception MVC pour notre application Web. La bonne nouvelle est qu’il s’agit également de la manière la plus simple et la plus économique de produire le code de notre application.

Pour la suite, vous devez avoir intégré les choses suivantes:

Eclipse est notre tour de contrôle pour tout faire dans la phase de développement; vous devriez avoir configuré Eclipse correctement, et être familier des commandes de création de fichiers divers, d’interaction avec Tomcat, de test de votre application;

Une application JEE obéit à une certaine organisation, est composée de servlets, et s’exécute dans un conteneur comme Tomcat;

La programmation Java, sans recourir à un environnement et à des outils spécialisés dans la production d’application Web, serait tout simplement un cauchemard (que certains ont vécu dans le passé, mais qu’il serait maintenant inexcusable de revivre).

Environnement Java

Contenu

3. Environnement Java#

S1: Serveur d’application: Tomcat#

S2: L’environnement de développement: Eclipse#

Installation#

Configuration#

Encodage UTF-8#

Réglages de l’éditeur de code#

Association Eclipse/Tomcat#

S3: Création d’une application JEE#

Création de l’application#

Qu’est-ce qu’une application JEE?#

Et dans Eclipse?#

Premier pas: création d’un contenu statique#

Premier pas, bis: création d’un contenu dynamique#

Résumé: savoir et retenir#