Tout d’abord j’ai fait 3 soirées ce soir : tout d’abord la présentation de Didier Girard sur GWT qui était vraiment sympa, la présentation de Jérome Louvel sur RESTlet et enfin la troisième mi-temps avec toute l’équipe du JUG et une dizaine de geeks autour d’une petite bière.

De l’avis de tout le monde, Didier a donné l’envie d’essayer GWT. La présentation rondement menée nous a permis de voir ce qu’est GWT. Cher lecteur ce soir je suis fainéant pour la première fois… Je ne vais pas bloguer des pages et des pages, je vous propose en attendant de relire des billets plus anciens sur GWT comme celui-ci ou celui-la sur Ext-GWT vs GWT-Ext.
Comme discuté avec Antonio, cela fait plaisir d’avoir quelqu’un qui apporte son expérience et partage sa passion sans concessions. En effet, Didier étant directeur technique de SFEIR, il parle en connaissance de cause, ce qui m’a intéressé.
Nous avons vu entre autre un plugin dans Eclipse facilitant l’écriture de code pour GWT, que GWT fonctionne avec Java 5 depuis le 28 août 2008, et un ensemble d’URL de sites d’exemples qui montrent GWT en action.
Mon avis sur la question c’est que GWT est destiné à réaliser des applications riches, et qu’en terme de productivité c’est un moteur puissant qui permet facilement de construire son application. Maintenant d’un point de vue web, je pense qu’il serait dommage de penser que GWT permet de faire une application type « vente de billet de trains »… Mais j’aimerai être convaincu du contraire.
En terme de mise en place, là où Adobe Flex propose avec BlazeDS et LiveCycle des solutions du côté du serveur, il n’y pas de solutions en GWT, car on parle bien d’un framework de présentation.
Je trouve par contre génial ce concept d’écrire du Java, de débuger dans Eclipse (ou IDEA IntelliJ) puis ensuite seulement de produire son code Javascript pour chacun des navigateurs, chacunes des langues supportées. Google est sur une niche et ce concept est réellement novateur.
Donc je reste fortement intéressé mais mon coeur balance plus pour Flex. Quitte à faire une application type client riche, je préfère travailler avec Flex. Cela me coûte une phase d’apprentissage du langage ActionScript, mais je gagne quelque chose par rapport à GWT, qui est le support de différents protocoles d’échanges entre le client et le serveur. Soit un échange de XML basique, soit du JSON, soit encore mieux, un format binaire propriétaire à Adobe qui permet d’optimiser encore plus la bande passante et les échanges entre le client et le serveur.
Merci en tout cas à Didier et vous pouvez retrouversur son site les URLs des démonstrations.

Ensuite un petit break pour le buffet organisé par la société Novedia Solutions. Honnêtement merci à eux car j’ai réussi à me caser derrière le buffet avec Cyrille Leclerc, Antonio Goncalves, Thomas et Alexis Moussine-Pouchkine. A nous 4 nous avons appliqué le pattern « Interceptor » et « Introspection » sur les plats de petits fours, que du bonheur.
Ma conclusion c’est que Spring n’a rien inventé. Au lieu de devoir faire un get et un set sur les petits fours, le serveur nous a tendu le plat et nous n’avions plus qu’à nous injecter ces bons petits gâteaux. Vive l’inversion de contrôle.

Bon reprenons la suite. Jérôme Louvel, membre de l’OSSGTP et auteur de Restlet nous a fait une démonstration plutôt pointue de Restlet. Tout d’abord ce que j’ai compris : Restlet est un framework léger REST en JAVA qui offre un système du côté client comme du côté serveur pour acceder à des Ressources. Je trouve que l’architecture REST est franchement intéressantante, et si vous voulez relire une présentation à ce sujet, voici un billet que j’aime bien écris il y a quelques mois sur REST.
Parlons un peu des choses qui fâche, désolé Jérôme si tu me lis. La présentation était vraiment très complète, voir un peu trop détaillé je pense pour le sujet de ce soir. Les efforts de migration et de portage vers la dernière version de GWT, quoique vraiment intéressant d’un point de vue technique, ont peut-être fait décrocher une partie de la salle.
Je pense qu’il est difficile en une heure de parler à la fois de Restlet et à la fois de GWT, c’était le format de la soirée qui donnait peut-être le cadre.
En tous les cas la présentation nous a donné un bon aperçu de Restlet et j’aurai aimé te poser des questions sur les annotations.
J’ai pensé un moment que Restlet se propose d’être un ‘ESB’ à la fois du côté du client et du côté du serveur, en simplifiant l’accès aux ressources et en utilisant les principes de REST. Durant la présentation, tu as cependant bien expliqué que grâce à Restlet, une application de type webmail a ajouté le support de GWT pour un coût de développement léger. Le système de sélection du type de rendu selon la source était bien expliqué.

Après la présentation nous nous sommes retrouvés au Falstaff à côté de l’ISEP autour d’une bonne bière. Moment agréable où j’ai écouté pas mal de monde, très sympa.

Sur ce, je vous donne rendez-vous la semaine prochaine pour un billet spécial pour fêter l’anniversaire du Touilleur Express ainsi que des nouveautés autour de Spring dès jeudi 13 novembre après la journée « Les Rencontres Spring« .

Je vous en reparlerai cette semaine.

Le coeur de mon métier, c’est le client riche. Avec mon équipe nous nous occupons d’un framework java propriétaire qui fonctionne en client léger dans IE ainsi qu’en mode client lourd (swing). Aujourd’hui je me rends compte qu’il est encore difficile de faire accepter l’évolution de l’architecture qui est en place. Nous passons d’un client lourd installé sur le poste de nos clients à une architecture déployée J2EE dont l’interface fonctionne dans un simple navigateur. Nous avons fait de gros efforts pour que l’application web soit aussi interactive que possible. En quelques sortes, cela fait plus de 2 ans que nous faisons de l’AJAX avant même que ce terme ne soit publié il y a maintenant 2 ans.
Et honnêtement le résultat est là.
Des tableaux éditables qui s’exportent vers Excel ou PDF, des graphiques avec JFreeChart, des blotters de données du marché qui se mettent à jour en temps réel… le tout avec du HTML, du CSS, des Javascripts et des composants HTC. Bref on est au limite de ce que peut faire un navigateur tel qu’IE6 sans aucuns plugins. Mais ça marche !

Aujourd’hui il y a encore quelques blocages qui font que nous avons ressorti le client lourd des cartons (Swing). Il y a aussi un coût plus important pour développer une interface riche web qu’une interface classique car les technologies actuelles (css,html,js,htc…) si l’on peut parler de technologies, ne sont pas très bien maîtrisées ou enseignées.

Ensuite sachez que tout n’est pas rose dans le monde AJAX. Ne vous emballez pas trop vite pour toutes ces librairies javascript comme Scriptaculous ou Prototype. Certes, elles vous font gagner du temps. Mais malheureusement elles ne sont pas toujours exemptes de bugs. Attention aussi au navigateur de Microsoft. Je pense particulièrement à Internet Explorer 6 (avant le SP2) et son moteur javascript. J’ai rencontré 2 fois un problème de fuite mémoire en javascript. Très difficile à identifier.

Pour revenir au débat « client riche/client lourd », je vois 2 soucis: je pense qu’il faut maintenant se tourner vers des technologies plus avancées pour faire un vrai produit fonctionnant dans un navigateur. J’ai testé Adobe Flex2 ainsi que Microsoft Expression Blend. Ces 2 produits sont adaptés pour construire un produit avancé qui fonctionnera en mode client lourd comme en mode client léger. Pour la technologie d’Adobe, Apollo AIR permet de faire fonctionner une application Flex en mode client lourd. Une syntaxe XML permet de définir l’interface, le MXML.

Chez Microsoft, la Beta 2 d’Expression Blend m’a agréablement surpris. Elle permet de construire une application qui fonctionnera avec le .Net framework 3,5. Elle peut fonctionner en client lourd comme en client léger grâce à Silverlight.

Adobe Flex 3 m’a semblé plus pratique au niveau des Layout Manager pour construire mon interface. Il est possible de définir un ensemble de composant et de les sauver dans sa boîte à outil afin de pouvoir s’en resservir. C’est aussi vrai pour Expression Blend. Du côté de Microsoft, l’éditeur est plus puissant. Il est moins facile à prendre en main mais la séparation entre l’interface et la partie dynamique est plus simple que chez Adobe. Je pense qu’il ne faut pas néglier ce que propose Microsoft. Nous arrivons à une solution mature pour développer à la fois en mode client lourd et en mode client léger.

Maintenant réveillons-nous un peu: je ne suis pas entrain de jeter aux orties tout le boulot web, et ce qui se passe derrière le décor. Je pense qu’il faut investir et commencer à regarder sérieusement Adobe Flex et/ou la couche Windows Presentation Framework avec Silverlight de Microsoft. Par contre je ne pense pas qu’il faille jeter l’architecture service J2EE pour autant. Et c’est l’un de mes soucis. On me demande de faire du client lourd. Du vrai client lourd 2-tiers avec la base de données et des services financiers déportés. Pour ma part, ma vision est que l’on devrait conserver un serveur d’application afin d’effectuer un certain nombre de services (profiling, authentification, authorisation…). Sur le serveur d’application, le coeur du produit continue à fonctionner. EJB3 ou pas, peu importe. En conservant une architecture Web+J2EE il reste possible de fonctionner en mode client léger dans un navigateur comme en mode client lourd déporté. Je pense que la méconnaissance de l’architecture J2EE nous conduit aujourd’hui à revenir en arrière, ce qui est vraiment dommage…

Deuxième réflexion: nous avons plusieurs produits. Nous offrons à nos clients une Suite qui regroupe tout ou partie de ces produits. Or si vous pensez en terme de client lourd, il devient rapidement compliqué de construire et livrer le binaire adapté à ce que le client a acheté. Pareil pour ce qui concerne les installations de patches… Avec 6 produits majeurs financiers, je peux vous assurer que vos équipes vont passer leur temps à mettre à jour tel ou tel produit… Mais bon, c’est envisageable.

En conservant une architecture 3 tiers, il est possible facilement d’ajouter ou de retirer tout ou partie d’un produit, car le coeur du produit n’est pas dans le client riche mais déporté sur le serveur d’application J2EE. Par ailleurs on concentrera les efforts sur l’ergonomie, l’interface du client, mais on se contentera d’effecteur des appels vers le serveur pour les traitements…

Voilà c’est tout… ce sont quelques idées qui me trottent dans la tête. L’arrivée des technologies de type client riche va bousculer une nouvelle fois nos connaissances d’architecture. Il faut penser maintenant à ce qui se passe derrière l’écran et la jolie fenêtre animé dans un écran Flex… Pensez-y si vous faites du client riche…

Mise en oeuvre:

• Téléchargez l’api ici
• Placer le fichier aa.js à la racine de votre répertoire web, les fichiers .class dans le répertoire WEB-INF/lib, le fichier ajaxanywhere.tld dans le répertoire META-INF\tlds.
• Configurez un nouveau filter:
  

        <filter>
          <filter-name>AjaxAnywhere</filter-name>
          <filter-class>org.ajaxanywhere.AAFilter</filter-class>
      </filter>
  
      <filter-mapping>
          <filter-name>AjaxAnywhere</filter-name>
          <url-pattern>*.jsp</url-pattern>
      </filter-mapping>
      <filter-mapping>
          <filter-name>AjaxAnywhere</filter-name>
          <url-pattern>*.do</url-pattern> <!-- default Struts mapping -->
      </filter-mapping>
      <filter-mapping>
          <filter-name>AjaxAnywhere</filter-name>
          <url-pattern>*.htm</url-pattern> <!-- other framewords mapping-->
      </filter-mapping>
  

Il faut maintenant brancher AjaxAnywhere sur vos composants JSF dans une page JSP. Vous pouvez voir ici une démo avec les composants MyFaces et l’intérêt de ne pas recharger toute la page. Pour ajouter AjaxAnywhere à une page JSP existante il faut:

• Importer la librairie de tag
• Appeler la methode AAUtil.addZones sur l’élement JSF à ajaxiser
• Importer les librairies JS et définir la FORM qui contient le composant
• Changer la target action de la balise FORM pour appeler du code JS d’AjaxAnywhere
• Pre et post fixer votre composant avec le tag JSF <aa:zone>

Si vous avez déjà une application avec JSF et que vous désirez tester le principe d’AJAX rapidement, alors AjaxAnywhere est pour vous

]]> http://www.touilleur-express.fr/2006/06/18/comment-ajax-iser-ses-composants-jsf/feed/ 0 http://www.touilleur-express.fr/2006/06/15/jboss-seam-10-ga-est-disponible-depuis-le-13-juin/ http://www.touilleur-express.fr/2006/06/15/jboss-seam-10-ga-est-disponible-depuis-le-13-juin/#comments Thu, 15 Jun 2006 08:10:44 +0000 Nicolas Martignole http://www.touillleur-express.fr/?p=67 A peine une semaine après le séminaire JBoss, la version 1.0 GA de JBoss Seam est disponible. En fait les archives étaient disponibles dès samedi 11 juin. Suite à cela nous avons vu cette semaine une pluie d’article sur les sites anglophones. Parmis ceux-ci, je vous conseille la lecture d’une interview de Gavin King le créateur d’Hibernate et de JBoss Seam sur InfoQ complète et intéressante. En deux pages il présente les idées phares de JBoss Seam qui en font un Framework de 3ème génération.

Pour ma part, depuis la semaine passée j’ai avancé sur ma maquette. J’ai intégré les tags JSF de l’api Jenia.org pour permettre d’avoir accès facilement dans JBoss Seam à JFreeChart. J’en aurai besoin pour la partie charting de notre application financière. Promis dès que j’ai un peu de temps je poste ici les modifications effectuées dans la build pour tester tout cela. Il a fallut notamment changer le build.xml pour pouvoir packager des JAR à la racine de l’EAR et changer le Manifest.mf pour le jar packagé dans le WAR… mais bon c’est du charabia et je prendrai le temps d’expliquer les modifications pour intégrer ces différents tags.

Pour tester JBoss Seam Remoting, en fait il ne m’a fallut qu’une petite heure pour reprendre « helloWorld » et créer un tag inputSearch à la AJAX. C’est vraiment simple. Seam = Simplicité.

La prochaine étape sera de voir comment appeler un web service à partir de la partie Seam. Il y a des specifications en cours dans EJB3 mais pour l’instant je n’en sais pas trop… A suivre donc

]]> http://www.touilleur-express.fr/2006/06/15/jboss-seam-10-ga-est-disponible-depuis-le-13-juin/feed/ 0 http://www.touilleur-express.fr/2006/06/11/migrer-de-jsf-12-vers-jboss-seam/ http://www.touilleur-express.fr/2006/06/11/migrer-de-jsf-12-vers-jboss-seam/#comments Sun, 11 Jun 2006 08:15:24 +0000 Nicolas Martignole http://www.touillleur-express.fr/?p=68 <P>Sur cet <a href= »http://weblogs.java.net/blog/bleonard/archive/2006/05/trying_out_jbos.html » target= »new2″>article</a> vous trouverez des explications claires et complètes pour intégrer JBoss Seam sur une application utilisant JSF 1.2. L’article comporte une deuxieme partie <a href= »http://weblogs.java.net/blog/bleonard/archive/2006/05/trying_out_jbos_1.html » target= »new22″>ici</a>. Seam permet de remplacer les backed-bean de JSF par des ejb3 rapidement et facilement.</P> <P>J’ai commencé hier une maquette en reprenant une application financière qui utilise notre propre framework pour évaluer le coût, la complexité et l’intérêt de passer à Seam. A suivre…</P> <P>Sinon la Suisse joue contre la France mardi soir… clin d’oeil à Luc et Thomas de Jboss inc.</P>
]]> http://www.touilleur-express.fr/2006/06/11/migrer-de-jsf-12-vers-jboss-seam/feed/ 0 http://www.touilleur-express.fr/2006/05/14/scriptaculous-et-fuites-memoires-javascript/ http://www.touilleur-express.fr/2006/05/14/scriptaculous-et-fuites-memoires-javascript/#comments Sun, 14 May 2006 10:30:16 +0000 Nicolas Martignole http://www.touillleur-express.fr/?p=73 Une nouvelle version de la librairie JavaScript Script.aculo.us est disponible sur le site http://script.aculou.us. Cette librairie vous permet d’ajouter dans vos pages facilement et rapidement des comportements dynamiques et asynchrones afin d’ajouter une petite touche AJAX à vos pages.

Parmies les améliorations notables, on note une mise à jour de la version de la librairie Prototype qui corrige des fuites mémoires d’Internet Explorer. En effet, AJAX c’est bien beau mais lorsque la partie Javascript est mal programmée, cela conduit rapidement à des problèmes de fuites mémoires. J’en parle en connaissance de cause puisque notre moteur souffre actuellement de ce souci. Pour aider les développeurs à rechercher les fuites mémoires du côté client dans le navigateur, il n’existe pas grand chose. Le seul outil pratique que j’ai trouvé s’appelle Drip. Il permet de suivre l’usage de la mémoire d’Internet Explorer et de voir les problèmes de Javascripts closure.
L’adresse du site est: http://outofhanwell.com/ieleak/index.php?title=Main_Page

Une autre ressource pour suivre l’utilisation mémoire d’IE est expliquée dans cet article du site Ajaxian.com.

Attention donc aux problèmes de mémoire avec Internet Explorer

]]> http://www.touilleur-express.fr/2006/05/14/scriptaculous-et-fuites-memoires-javascript/feed/ 0 http://www.touilleur-express.fr/2006/03/28/ajax-deja-un-an-deja-7-ans/ http://www.touilleur-express.fr/2006/03/28/ajax-deja-un-an-deja-7-ans/#comments Tue, 28 Mar 2006 13:51:51 +0000 Nicolas Martignole http://www.touillleur-express.fr/?p=76 AJAX existe officiellement depuis un an suite à l’article d’un consultant en mars 2005. Cependant d’un point de vue
technique AJAX existe depuis 1999 comme l’explique l’article de Wikipedia.

Avez-vous entendu parler du Web 2.0 ?

Basé sur des technologies comme AJAX, DHTML, XML ou Soap, le concept de « Web 2.0″ regroupe
l’annonce de l’arrivée prochaine d’application légère dans votre navigateur.
Microsoft ainsi commence à croire que Google pourrait être son plus sérieux compétiteur. La présentation de Google faites aux analystes financiers parle
ainsi d’un nouveau concept de Web. Google proposerait un espace de stockage
illimité pour vos fichiers, des applications légères embarquées dans votre
navigateur pour les utiliser, et donc la fin des logiciels installés sur votre
ordinateur personel. Un espace disque infini serait alors offert et accessible
de votre travail, de votre téléphone mobile et de votre télévision à la maison…
Peut-être que d’ici 4 à 5 ans, Google prendra la première place devant Microsoft ?

En attendant celui-ci cependant n’attend pas les bras croisés de se faire distancer. Microsoft annonce ainsi quelques nouveautés basé sur AJAX dont Atlas,
un framework de développement qui devrait permettre aux éditeurs de logiciels
d’offrir une version « Web 2.0″ de leurs logiciels. La version CTP d’Atlas est
sortie au début du mois de mars.
Allez faire un tour (avec Internet Explorer) aussi sur Live.com de Microsoft.Vous y trouverez un moteur
de recherche à la Google (sans publicité apparente) utilisant AJAX. Le logo
« Windows Live Beta » fait cependant un peu croire à la sortie d’un OS en ligne,
alors qu’il n’en n’est rien.

Et les développeurs…
Depuis quelques mois, on voit ici et là de plus en plus de librairies et de
frameworks d’application clairement orienté Web 2.0. Leur objectif est de faciliter
la création de site « AJAX » tout en conservant du côté du serveur un modèle qui
tienne la route. Vous pouvez trouver sur ToutAjax
une liste assez complète d’applications,
de démos et de librairies pour se lancer.

Ce qui m’intéresse en temps qu’architecte J2EE, c’est la facilité de
mise en oeuvre d’une ergonomie et d’une interactivité comme AJAX dans mes
applications Webs, ainsi que la facilité de maintenance ensuite.
Du côté du client, il existe désormais des librairies gratuites puissantes
à intégrer dans une application qui nous permettent de construire nos interfaces
en ayant l’interactivité d’AJAX. Quelques librairies comme Script.aculo.us,
Rialto ou Dojo Toolkit sont puissantes et efficaces mais pas toutes semblable.
Rialto est celle qui m’intéresse en ce moment, notamment à cause du support de Java Server Faces.

Il me semble que JSF + AJAX est un peu le couple à marier en 2006.
Java Server Faces apporte un modèle composant à une application et permet de
définir ses composants tels qu’ils seront représentés dans le navigateur.
Il n’a pas fallut attendre longtemps avant de voir apparaître ici et là des
composants JSF utilisant AJAX comme ce composant pour télécharger uploader un fichier vers une JSP.
Si vous avez lu aussi mon post sur Shale (Struts 2.0 mais pas vraiment) vous savez déjà que Shale aura un composant de Rendering et s’intégrera avec Apache MyFaces pour pouvoir au final offrir des composants JSF utilisant AJAX (entre autre).
Pour terminer, je vous donne un lien vers le fameux PetStore mais réalisé avec donc ces nouveaux composants qui font que dans quelques mois, le web va changer.
Ajax PetStore vu sur l’excellent site Ajaxian.com

]]> http://www.touilleur-express.fr/2006/03/28/ajax-deja-un-an-deja-7-ans/feed/ 0 http://www.touilleur-express.fr/2005/12/02/client-riche-xul-ajax-flash/ http://www.touilleur-express.fr/2005/12/02/client-riche-xul-ajax-flash/#comments Fri, 02 Dec 2005 08:40:11 +0000 Nicolas Martignole http://www.touillleur-express.fr/?p=88 J’ai assisté vendredi 25 novembre à une présentation de Valtech Training sur « les Clients Riche, périmètre et solutions techniques ». Cette présentation visait à nous présenter les dernières technologies pour porter ou réaliser un client riche.
Denis Peyrusaube de Valtech Training a tout d’abord présenté ce qu’est un client riche, pour expliquer ensuite XUL, AJAX, Flash, Java Web Start et enfin Eclipse SWT.
Je vais essayer de résumer sa présentation, en donnant au passage mon avis.

Qu’est-ce qu’un client riche ?
Un client riche est un système qui est hébergé sur un serveur pour faciliter les mises-à-jour et le déploiement, tout en offrant une interface riche à l’utilisateur. Il n’embarque pas toute la logique de l’application. La majorité des traitements sera effectuées côté serveur. Cependant l’ergonomie et la richesse fonctionnelle offertes à l’utilisateur sont très proches d’un client lourd classique.

La conception d’une application en mode page au sens Web du terme tend à disparaître. Aujourd’hui une application doit offrir une ergonomie et une navigation par composant plutôt que par page d’état comme ce fut le cas au début des applications webs.

Idéalement une techno doit proposer des composants graphiques de haut niveau tout en restant facilement déployable. D’autre part, quelque soit la techno retenue, la notion de conteneur sur le poste client apparaît. En règle général le navigateur internet est suffisant.

1. XUL
XUL (prononcer [Zool]) est le précurseur des technologies de présentation web. Il s’agit d’un langage XML décrivant des composants (Menu, ComboBox) destiné à remplacer le langage HTML. Dans les faits aujourd’hui, XUL est porté par la communauté open-source Mozilla, mais Microsoft s’y intéresse aussi.
Un exemple de site utilisant XUL: http://www.georgenava.com/
Ce site ne fonctionne que si vous avez Firefox ou Mozilla. Il ne fonctionne pas avec Internet Explorer.

2. AJAX
AJAX (Asynchronous Javascript And XML) n’est pas réellement une nouveauté même si en ce moment c’est un sujet chaud dans la communauté Web. Au départ il ne s’agit que d’un article écrit par un consultant destiné à formaliser un mécanisme Asynchrone qui permet de rafraichir une page dans un navigateur sans devoir recharger toute la page. AJAX fonctionne avec Internet Explorer et Firefox car il s’agit ni plus ni moins que du? Javascript côté client. Premier avantage donc: la portabilité.
AJAX du côté serveur n’impose pas de modèle de programmation. Il n’y a donc aucunes normes XML, ni DTD. Le message envoyé par le serveur est au format XML et le client le reçoit de manière indirecte. Il peut alors afficher des informations en utilisant du Javascript, du Dynamic HTML et des feuilles de style.
Donc pour résumer: le serveur envoie un message XML, le navigateur le reçoit via un objet XMLHttpRequest de manière asynchrone. Une librairie Javascript modifie la page, change la couleur d’un combo, fait apparaître un menu déroulant ou masque un tableau par exemple.
Puisqu’une démo est mieux qu’un long discours voici quelques sites utilisant AJAX:
GoogleSuggest
Si vous tapez JAV puis vous attendez un instant, votre navigateur envoi au serveur ces 3 lettres. Le serveur retourne une réponse au format XML en utilisant un format propriétaire à Google. La partie Javascript d’AJAX dans le navigateur lit la réponse, construit alors un DIV en HTML (une boîte) et vous liste le nombre de site parlant de java, javascript…
AJAX permet d’ajouter des mécanismes côté client pour ne recharger qu’une partie d’une page internet. Il existe aussi des librairies Javascript destinées à faciliter les développements d’application AJAX comme ScriptAcuLous (http://script.aculo.us/) ou surtout ProToType (http://prototype.conio.net/). Elles permettent de coder des fonctions de Drag-and-drop par exemple (http://wiki.script.aculo.us/scriptaculous/show/DragAndDrop)

Les inconvénients ?

• Pas de DTD/XSD côté serveur concernant le XML. Chacun fait ce qui lui plait.
• Le Javascript est difficile à coder/débugger et n’est pas un langage très puissant.
• Difficile à tester en phase de développement
• Il existe des composants riches mais ils sont payant
• Pertinence et pérennité du JavaScript dans 2 ou 3 ans ?

Les avantages?

• Simple à mettre en ?uvre
• Puissant
• Effets intéressants offrant de nouvelles possibilités en terme d’ergonomie
• Compatible Internet Explorer et Firefox dans la mesure où le code JS l’est
• Communauté de développeur très active
• Bientôt intégré dans des composants Java Server Faces (JSF) pour faciliter le codage.

Outils AJAX:
- ATLAS (Microsoft) framework intégré dans Visual Studio et .NET destiné à simplifier le développement d’application Web. A noter que Microsoft a annoncé que d’ici 2 ans, Office 13 sera majoritairement en mode serveur lourd-client riche et que c’est l’une des raisons qui font que Microsoft pousse cette techno. Voir l’article d’un des gourou de Microsoft http://weblogs.asp.net/scottgu/archive/2005/06/28/416185.aspx
Est-ce un effet d’annonce de Microsoft ou vas-t-on voir un nouveau système pour créer une application riche ?

- SAJAX: Toolkit de dév pour AJAX (http://www.modernmethod.com/sajax)

- DoJoToolKit http://dojotoolkit.org) API Javascript pour résoudre les problèmes de portabilité entre IE et les autres navigateurs.

3. Macromédia FLASH
Sans doute pour moi la révélation de cette présentation. Je pensais que Macromedia Flash servait soi à faire un site joli et animé, soit à afficher des bandeaux de publicité lorsque Firefox bloque les pop-ups. Et bien non? nous sommes en 2005 et ce que j’ai vu était vraiment intéressant.

Flash est une techno créée par Macromédia (qui appartient à ADOBE) utilisant un plug-in installé sur un navigateur Web. Conçu à l’origine pour l’animation Web, Flash est un outil pour les graphistes ou les animateurs. Aujourd’hui l’évolution est le fait que Flash peut aussi servir à faire des applications type Client Riche.
Exemple 1: Le site internet du Club Med utilise Flash pour vous permettre de trouver un séjour sur mesure.
L’évolution est du côté de la conception. La première monture du Studio Flash était destinée à des animateurs Web, avec une ligne de temps et des outils de déformation vectorielle. Ce qui est nouveau c’est la phase de développement et de rendu dynamique.

Il existe 2 solutions basées sur Flash: Macromedia Flex et Laszlo

Macromedia Flex:
Solution propriétaire et payante de Macromédia. Il s’agit d’un studio qui vous permet de construire votre page en utilisant des composants (Label, Buttons, ComboBox?).

Flex se décompose d’un fichier MXML pour décrire l’interface et d’un fichiet ActionScript pour décrire ce qui se passe et les interactions entre les composants. Ces fichiers sont compilés par un conteneur de Servlet (comme JSP) pour générer un flux binaire de type Flash qui sera envoyé au client. Etant donné qu’il ne s’agit que d’une servlet il est donc possible de rendre dynamique une partie du contenu XML par exemple.

Un plugin Eclipse pour FLEX est en cours de réalisation.

OpenLaszlo est basé sur le même système que Flex, à la différence prêt qu’il s’agit d’une initiative Open-source. Démo disponible à cette adresse : http://www.laszlosystems.com/demos.
La société LaszloSystem propose des services comme le fait Jboss Inc. en terme de support si nécessaire.
Flash est finalement intéressant car les outils de conception de page existent déjà et permettent donc de bien séparer la partie GUI de la partie data. Cependant difficile de se rendre compte si les données dynamiques sont faciles à gérer ou non.

4. Java Web Start
JWS ajoute à Java des fonctionnalités de déploiement, de gestion de cache et d’exécution distante. A ce titre c’est donc une technologie pour Client riche. JWS fonctionne via un navigateur internet ou non. Permet de mettre à jour rapidement les clients répartis, tout en ayant une richesse fonctionnelle complexe.
En gros inconvénient, il faudra recoder un container pour remplacer ce qu’offre le navigateur Web (partie réseau, chargement du contenu, gestion Proxy, CSS?)
JWS ne convient que si le client riche doit vraiment avoir des fonctions qu’un navigateur web ne peut pas offrir.
En terme d’avantage, on revient au modèle client-serveur classique, ce qui est beaucoup plus facile à coder/débuger que via le Javascript par exemple.

5. Eclipse Platform
Eclipse est un éditeur Java bien connu mais surtout un moteur de rendu appelé Platform.
Ce système est composé d’un ensemble de service, de widgets, de gestion des ressources qui permettent d’utiliser le squelette d’eclipse comme base de dévelopement de client lourd.
D’autre part, il est possible d’intégrer d’autres plugins et donc d’enrichir son application facilement. A noter que l’on peut utiliser JWS pour installer une application basée sur Eclipse.

http://www.eclipse.org/platform/index.html

Conclusion
Les clients riches seront fortement présent dans les années à venir car les navigateurs Web deviennent aussi de plus en plus puissant. La facilité de déploiement, l’absence de gestion de mise à jour sur le poste client et l’ergonomie riche sont les critères qui font un client riche. On parle beaucoup d’AJAX et je sais qu’il existe des composants JSF (côté serveur) qui permettent de s’interfacer via J2EE avec les applications métiers. Il sera donc certainement facile d’ici quelques mois de tester et voir si ce genre de solution peut nous intéresser.
Flash via Flex ou Laszlo offre le meilleur résultat en terme de rendu côté client. N’ayant pas vu en détail le côté serveur, il est difficile d’estimer si cette technique est adaptée à des données très dynamique comme dans la finance. Java Web Start et Eclipse Platform sont deux solutions pour développer des clients riches sans retomber dans le modèle client-serveur.

]]> http://www.touilleur-express.fr/2005/12/02/client-riche-xul-ajax-flash/feed/ 0