Le blog de L'ami S'ami

Suite à un mail de l’ami Bruno sur Eclipse RAP (Yo!), je me suis empressé de tester ce n-ième Framework AJAX annoncé comme le GWT killer du moment (cf demo1 et demo2).

Après quelques tests et samples d’usage, je me suis plongé dans l’analyse du SDK et des classes qui composent RAP. Il ressort plusieurs choses : Dans la pratique, RAP est ce qu’on appelle un « Echo like ». Cela signifie que la majeure partie (sinon la totalité) des traitements sont confinés sur le serveur. A chaque évènement client (souris, clavier), un message AJAX est envoyé au serveur qui met ensuite en œuvre tout un cycle de vie consistant à lire les données de la page, recréer entièrement un arbre de contrôles côté serveur, exécuter des évènements puis effectuer le rendu (rendering) final. Ce cycle de vie n’est pas sans rappeler les phases JSF. D’ailleurs, les auteurs de ce Framework ne se cachent pas de s’en être fortement inspirés pour leur Design.

Cette approche possède des avantages et des inconvénients:
- avantages : le serveur gère tout, il ne peut y avoir de problèmes de compatibilité d’API ou de version de JDK tels qu’on le retrouve dans GWT par exemple. Il n’y a quasiment aucun code JavaScript généré sur le poste client
- inconvénients : le client fait d’incessants aller/retour avec le serveur, même pour effectuer des opérations basiques de rendu (click puis popup sous un menu). Le clavier devient difficile à gérer en mode OnKeyPressed, par exemple si on imagine tester la longueur d’un champ au fur et à mesure qu’un utilisateur saisit une valeur...développer un simple HelloWorld s’avère délicat lorsqu’on ne maîtrise pas les API Plugin d’Eclipse. RAP s'appuie sur le modèle de composant SWT et l'API RCP, du coup il faut dériver de pas moins d'une dizaine de classes telles que WorkbenchAdvisor, EntryPoint, ViewPart et PerspectiveFactory.

Pour finir sur une note d’humeur, j’avoue que la multiplication des Framework AJAX commence à être de plus en plus problématique. Problématique pour nous techniciens qui commençons à être de plus en plus submergés par autant de nouveautés (même si dans la pratique, peu innovent finalement). Et problématique pour le marché et les utilisateurs car du coup, plus personne ne sait aujourd’hui ce qu'il doit choisir dans le cadre d'un nouveau développement Web entre JSF, JSP, Struts 2 (j’y viendrais), GWT, Eclipse RAP, Echo2 ou DOJO (je ne parle pas de Zk, JMaki et autres Bindows et Backbase). Ajouté à cela le choix de la plateforme orientée service pour faire discuter tout ce beau monde, et on retrouve au menu Spring, EJB3, Guice, Pico, Rico et bientôt Mico (nan là je plaisante). Et last but not least, la partie accès aux données avec Hibernate, JPA, Toplink, JDBC ou iBatis…

Je me suis amusé à compter le nombre d’architecture possibles en Java avec les Framework disponibles aujourd’hui, on arrive au chiffre hallucinant d'une centaine, voire plus : 10 (présentation) x 5 (service - spring/manuel/ejb3/guice) x 5 (data - jpa/toplink/hibernate/jdbc/ibatis) ...

Vivement l'UInification tant attendue, tous ne survivront pas...