Le blog de Phil

J'habite Malakoff, la plus belle ville du monde

JSF VS GWT: Choix final: JSF

Ça fait depuis 3 mois que l’on a débuté notre nouveau projet.

Mais comme il arrive que cette note soit consultée, je vais donner les choix que l’on a effectués.

 

Nous avons finalement opté pour JSF.

Le lancement en dé-bug est plus rapide, par ailleurs, une fois le projet construit (j’ai fait le même projet deux fois, une fois en JSF, l’autre fois en GWT), le projet JSF tourne plus vite sous JBoss que le projet GWT.

 

Par ailleurs, s’il faut regarder dans la boite noire, il est plus facile de regarder JSF que GWT.

Donc on peut dire que le choix s’est basé sur les critères suivants:

JSF s’intègre plus facilement dans le reste (Spring, Hibernate, Maven), permet de séparer plus facilement les couches et les fonctionnalités (ce qui est nécessaire car notre fonctionnel est lourd)  et le résultats s’est montré plus performant une fois que l’on a construit le projet (via Maven) et que l’on l’a fait tourner sous JBoss.

Publicités

25 juillet 2012 Posted by | GWT, Informatique, Java, JSF | , , | Laisser un commentaire

JSF VS GWT, round 1.

Mon blog ne parlant pas que de politique (si, si, je vous jure, c’est vrai), j’ai eu envie de parler de mon travail.

En ce moment, je regarde à fond le choix entre deux technologies: GWT et JSF.

Et j’ai eu envie de revenir sur mon ressenti, surtout que l’ami Sami, qui a écrit un très bon livre sur GWT, a répondu à un autre de ses amis (que je ne connaissais pas) qui explique que GWT n’est plus aussi pertinent qu’avant.
De quoi s’agit-il?

Alors que JSF est un MVC permettant de séparer la présentation d’une vue du traitement métier pour une application web, GWT est un compilateur qui va transformer du code Java, langage informatique universel, en HTML/Java-script/CSS pour la vue.

 

Pour comprendre l’enjeu, il faut revenir à la préhistoire de l’informatique.

Avant, on envoyait une requête au serveur, le serveur traitait, et il rechargeait toute la page. JSF part de ce principe.

Le java-script, langage interprété par votre navigateur, était peu utilisé.

 

Aujourd’hui, le java-script, combiné avec le CSS et le HTML, est mieux utilisé. Votre page web devient une application à part entière et il est possible de demander au serveur de ne recharger qu’une partie de la page.

C’est l’avènement des technologies AJAX et de la philosophie web 2.0.

C’est beau?

Oui mais, il y a un problème: le java-script dépend de votre navigateur, et certains navigateurs sont des cauchemars pour les développeurs (enfin surtout un: Internet Explorer).

 

C’est là qu’intervient GWT: GWT va compiler un site en plusieurs versions, et il va le faire pour chaque navigateur. GWT va optimiser le java-script pour chaque navigateur.

Là est la force de GWT.

Par ailleurs, grâce à l’IDE Eclipse, il sera possible de lancer le site en mode Hosted pour le débogage.

 

Seulement, le choix entre GWT et JSF n’est pas si évident, et aujourd’hui, j’ai tendance à préférer JSF.

La première raison est que JSF est plus facile à maîtriser et qu’il permet de séparer la vue des autres couches plus facilement.

La seconde raison est que JSF ou GWT doivent s’intégrer facilement dans les autres technologies qui ont fait leurs preuves, c’est à dire Maven pour la construction de projet, Hibernate pour la persistance, et Spring pour l’injection de dépendance.

Or l’archétype Maven pour GWT est bourré de faute.

Et comme en mode hosted Google nous impose un Jetty comme moteur de Servlet (alors que le Tomcat est tellement plus simple), j’ai un peu de mal à faire tourner l’ensemble GWT/Jetty dès que j’ajoute Spring (en ce moment, il ne trouve pas une classe Spring).

 

Bref, JSF, même si au départ a été mal conçu, a une structure tellement flexible, que Aujourd’hui, il est possible de faire de l’AJAX avec JSF sans toucher au java-script.

Il existe des librairies comme Primefaces ou RichFaces.

A lire aussi sur le sujet:JSF, je t’aime, moi non plus.

1 mars 2012 Posted by | GWT, Java, JSF | , , , , , | Laisser un commentaire

GWT

Au travail, je suis en train de (re)découvrir GWT (Google Web Toolkit) dans le cadre de veille technologique.

 

Je devrais tout de suite décrire l’outil en lui même, mais je préfère d’abord décrire le pourquoi.

 

Pourquoi GWT?

 

Il faut remonter à la préhistoire du web. A l’époque, lorsque l’on cliquait sur un bouton soumettant un formulaire web, on laissait les traitements au serveur, puis celui-ci rechargeait toute la page.

 

Aujourd’hui, avec une meilleure prise en compte du java-script, langage interprété par le navigateur côté client, la page web elle-même devient une application. De plus, lors de l’appel au serveur, seulement une partie de la page est rechargée. C’est là qu’est apparu ce que l’on appelle les technologies AJAX mêlant HTML(ou XHTML), CSS et java-script.

Ceci a permis l’essor du web 2.0.

 

Or, cette nouvelle approche est délicate. Elle demande des notions dans un ensemble de compétences. Pire, le java-script est implémenté totalement différemment d’un navigateur  à un autre.

Et les spécialistes sont rares dans le domaine.

 

C’est là que Google a eu une idée géniale: On écrit son site en Java, langage informatique, et la boite noire Google traduit en java-script/CSS/HTML ce qui doit être traduit en java-script/CSS/HTML.

Du coup, il ne nous reste plus qu’à coder l’ensemble du site web en Java comme une vulgaire application SWING.

C’est l’outil GWT.

Par ailleurs, GWT fournit pour chaque navigateur une version différente du site, optimisant par la même occasion le Java-script.

 

Pour en savoir plus, je recommande le site de Sami Jaber et son excellent livre.

25 janvier 2012 Posted by | GWT, Informatique, Java | , , , , , | Laisser un commentaire