Archive for the 'framework' Category

Un framework Swing

J’ai développé un framework Swing que j’ai appelé Swinger et qui permet de décrire une application de bureau avec un simple fichier XML :

<j:frame width="600" height="400" addWindowListener="actions.ActionQuitter" x="50" y="50">
	<j:menubar>
		<j:menu text="Fichier">
			<j:menuitem text="Quitter" addActionListener="actions.ActionQuitter"/>
		</j:menu>
	</j:menubar>
	<j:panel width="600" height="400">
		<j:textarea text="Hello !" width="300" height="200"/>
	</j:panel>
</j:frame>

Je dois avouer que je suis plutôt fier de mon bébé. Il est encore très incomplet car cela ne fait que trois jours que je travaille dessus, mais j’espère qu’il est promit à un bel avenir. J’ai écrit un KickStart sur le wiki du projet. Si vous avez des questions, n’hésitez pas à les poser dans l’onglet « Issues ».

Les frameworks Ajax

Les frameworks de développement Web reposant sur JSP on l’inconvénient majeur de nécessiter une bonne connaissance de JavaScript pour pouvoir développer un site en Ajax. Pendant longtemps, ces frameworks ne prennaient pas en compte cette dimension du développement Web. Mais un nouveau type de frameworks spécialement conçu autour de la technologie Ajax a fait son apparition depuis environ un an. Leur particularité est de permettre à un développeur Java d’écrire une application Ajax sans aucune connaissance de JavaScript.

Il existe deux frameworks plus ou moins équivalents que sont GWT (Google Web Toolkit) et Echo2. L’un comme l’autre permet de concevoir une application Ajax sans écrire une seule ligne de code en JavaScript. Leur principe est de proposer une librairie Java et un compilateur qui converti le code de cette librairie en JavaScript. Mais bien que reposant sur le même principe général, ces deux frameworks sont en fait très différents.

GWT distingue de façon très nette les parties cliente et serveur. La première est intégralement compilée en JavaScript et peut être exportée vers n’importe quel serveur Web tel que Apache, tandis que la partie serveur est destinée à tourner sur un conteneur de Servlet tel Tomcat. Bien sûr, il est possible de faire tourner le tout sur Tomcat, mais seules les librairies pouvant être compilées en JavaScript peuvent être inclues dans le code de la partie cliente.

En revanche, Echo2 n’offre pas de cadre pour distinguer le côté serveur et le côté client, il appartient au développeur de s’en tenir au design pattern adéquate. Et à la différence de GWT, Echo2 génère une véritable application Java dont le code est intégralement délivré par des Servlets. Il n’est donc pas possible d’exporter une application Echo2 vers un simple serveur Web.

Quel que soit le choix de la technologie, les frameworks Ajax ont l’avantage, pour un développeur Java, de pouvoir se lancer dans l’écriture de Services Web complexes. On signalera enfin l’existence d’une librairie Ajax conçue spécifiquement pour le framework JSF et qui s’appelle Ajax4Jsf, nous aurons l’occasion d’y revenir.

Les frameworks de développement Web et le pattern MVC

Le langage Java s’est principalement imposé côté serveur, cela s’entend dans une architecture client/serveur. C’est pourtant dans les applications autonomes que Java a tout d’abord mis en oeuvre l’architecture qui allait faire sa popularité, à savoir le pattern MVC. La philosophie sous-jacente à MVC est de supprimer les couplages inutiles, c’est-à-dire de décomposer l’application en modules indépendants les uns des autres. C’est déjà ce que permet de faire la programmation orientée objet en théorie, mais la réalité est que les développeurs, cherchant la facilité au premier abord, établissent souvent à des redondances inutiles qui sont à l’origine d’enchevêtrements abscons. Les designs patterns sont là pour rappeler les bonnes pratiques en matière de programmation et, de ce fait, faciliter tant la collaboration des équipes que la mise à jour ultérieure du code. Cette approche de la programmation a été adoptée dans la librairie swing qui est la librairie graphique de Java pour les application autonomes.

Parallèlement à son succès auprès des développeurs, Java s’est progressivement imposé côté serveur jusqu’à devenir un acteur incontournable du Web au même titre que le langage PHP. Mais cette progression c’est faite laborieusement comme nous avons pu le voir dans un billet précédent. Face à la complexité croissante des applications Web, la nécessité d’en revenir aux meilleurs pratiques de développement s’est rapidement fait sentir. C’est pour répondre à la détresse des architectes logiciels que la fondation Apache a crée le framework Struts. Un framework dont l’objectif avoué est d’inviter les développeurs à de meilleures pratiques, et notamment à recourir au fameux pattern MVC qui consiste à séparer une application en trois couches que sont la couche de présentation, la couche métier et la couche de contrôle, celle qui fait le pont entre les deux premières.

La couche de présentation (Vue) est celle qui a la responsabilité de générer ce qui est affiché à l’écran, c’est-à-dire le positionnement des composants graphiques ainsi que les détails de leur aspect comme la couleur. La couche métier (Model) est celle qui met en oeuvre la logique de l’application, elle a pour responsabilité de représenter les données du problème et de les résoudre. Enfin, le controleur (Controler) établit la relation entre la Vue et le Model, elle gère la dynamique de l’application.

Comme nous l’avons écrit dans dans un billet précédent, les JSP reposent sur un langage de balises extensible. Cette propriété a été exploitée par les concepteurs de Struts pour créer une librairie de balises permettant de résoudre la majorité des problèmes posés par l’écriture de la couche présentation, cela sans avoir besoin de recourir aux Scriptlets. Cela permet finalement d’unifier le langage utilisé pour la couche présentation généralement écrite par les équipes de design. Le langage Java est ainsi réservé à l’écriture des couches métier et controleur.

C’est donc pour répondre à ce motif que le framework Struts a été développé. Il y est parvenu au prix d’une certaine complexité qui le réserve aux projets de grande envergure.

Le développement Web en Java

La conception de sites Web est possible en Java, elle est basée fondamentalement sur la technologie des Servlets et requière l’installation d’un conteneur comme le serveur Tomcat. C’est ce conteneur qui reçoit et oriente les requêtes http vers les Servlets idoines. En retour, la Servlet doit construire la réponse à la requête, en général au format html ou xml.

Le principe des Servlets est très puissant car il permet de répondre à n’importe quel type de requête http qui est le protocole standard des applications Web. Mais l’inconvénient est que les développeurs partent d’un fichier en langage Java pour produire un document en langage html. Ainsi, la rédaction d’une page Web est malaisée. Le handicap se fait particulièrement ressentir lors de la mise à jour du document. Voyez par vous-même :

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class ExempleDeServlet extends HttpServlet {
    protected void doGet(HttpServletRequest req, HttpServletResponse res)
    throws  ServletException, IOException {
        OutputStream out = res.getOutputStream();
	out.println("<?xml version="1.0" encoding="UTF-8" ?>") ;
        out.println("<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitionnal//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitionnal.dtd\">"
        out.println("<html><head><meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\" /><title>Exemple de Servlet</title></head>");
        out.println("<body>Vous ne vous en rendez peut-être pas compte, mais ce n'est vraiment pas pratique</body></html>");
    }
    protected void doPost(HttpServletRequest req, HttpServletResponse res)
    throws  ServletException, IOException {
        doGet(res, req);
    }
}

Les fondements de la technologie n’ont jamais été remis en cause et ils ont maintes prouvé leur pertinence. En revanche, le langage Java a été enrichie d’une nouvelle spécification avec l’arrivé des JSP (Java Server Page) il y a bientôt dix ans. L’inconvénient des Servlets a ainsi été surmonté en inversant les pôles : les JSP sont des documents qui suivent la structure du langage html avec la possibilité d’ajouter du code Java.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Exemple de JSP</title>
</head>
<body>
C'est beaucoup plus pratique à écrire et à mettre à jour
</body>
</html>

Comme on le voit ci-dessus, une JSP ressemble à s’y méprendre à un document html, c’est le conteneur qui se charge de compiler la JSP en Servlet. En fait, une JSP permet de faire bien plus de choses que d’écrire des balises html. Comme nous l’avons dis, il est également possible d’y insérer du code Java grâce aux Scriplets mais aussi de faire référence à une variable avec les Expressions Langage. Enfin, et c’est le plus important, les JSP reposent sur un langage de balises extensible, c’est-à-dire que contrairement au langage html qui définit l’ensemble des balises autorisées, le développeur de JSP peut créer ses propres balises. Ce mécanisme est extrêmement puissant et offre un gain de temps considérable en permettant de créer des composants complexes qui pourront être utilisés par la simple apposition d’une balise.

Malgré tous ces avantages, les JSP ne sont pas pour autant la panacée. Elles ont l’inconvénient de leur avantage, leur souplesse est telle que les JSP deviennent rapidement illisibles si le développeur ne s’astreint pas à une certaine rigueur. C’est à ce niveau qu’intervient le framework. Le rôle qui lui est dévolu est de définir un cadre de travail qui doit permettre de conserver l’avantage premier des JSP, à savoir leur facilité de mise à jour.

Nous reviendrons sur les frameworks dans un prochain billet.

En bref