Blog Objet Direct

Comme promis sur ce billet, nous allons faire un retour sur le séminaire organisé par jWeekend ce samedi 21 Novembre: le London Wicket Event.

Des commiters, des développeurs ou tout simplement des personnes curieuses de connaître Wicket, se sont retrouvés dans les locaux de la librairie Floyds pour assister au London Wicket Event. Lors de cette session d’environ quatre heures, cinq présentations nous ont été faites :

• L’intégration de Javascript dans les applications Wicket,
• WiQuery,
• Brix,
• Les composants de Sven Meier,
• Wicket 1.5

De plus, Martijn Dashorst, auteur de Wicket in Action, nous a annoncé la sortie prochaine de la seconde édition de son livre.

L’intégration de Javascript dans les applications Wicket

Jeremy Thomerson, commiter américain dans le projet Wicket, est venu nous parler du besoin de pouvoir insérer via des composants ou des behaviors Wicket des portions de code Javascript (pour pouvoir rendre plus dynamique nos applications ainsi que de pouvoir utiliser l’internalisation que nous offre Wicket via la gestion des ResourceModel) et aussi les différents moyens pour y arriver.

La première approche est d’utiliser un behavior Wicket, et dans la méthode renderHead, indiquer les ressources Javascript à utiliser, ainsi que le code Javascript à exécuter lors du chargement de la page. Un exemple de code basique :

Dans un second, nous pouvons ajouter à notre behavior la méthode bind. Celle-ci va nous permettre de savoir sur quel composant Wicket le behavior sera utilisé. Ainsi, en récupérant l’identifant HTML que Wicket génère, nous pourrons agir sur le composant via notre Javascript.

Enfin, une dernière approche est d’utiliser un IHeaderContributor sur les composants Wicket qui va nous offrir la méthode renderHead que nous avons vu précédemment.

Grâce à ces différentes techniques, nous pourrions envisager de coupler les validateurs Wicket avec des plugins de validation Javascript, comme le plugin jQuery « jVal ». Nous n’aurions qu’à créer un behavior qui lors du bind, ajout le validateur souhaité (par exemple, MaximumValidator) et aussi d’insérer le Javascript équivalent au validateur sur le composant.

wiQuery

Lors de ce séminaire, Lionel Armanet (accompagné de François Delalande et de Julien Roche) a présenté l’un des projets d’OD labs : wiQuery.

wiQuery est un framework d’intégration, permettant de coupler Wicket avec jQuery, afin de pouvoir élaborer des composants et des behaviors riches.

Ce framework a été conçu de sorte que les développeurs puissent facilement coupler un plugin jQuery avec Wicket. De plus, le framework propose d’utiliser tous les composants, effets et behaviors de la librairie jQuery UI, ainsi que la possibilité d’appliquer les thèmes de jQuery UI à travers son application.

La mécanique interne s’assure de charger les ressources jQuery et jQuery UI nécessaires aux plugins (ainsi que toutes ressources nécessaires qu’auraient déclarés les développeurs), de générer le javascript, et l’insérer lors du chargement de la page ou si nécessaire de l’injecter lors d’une transaction Ajax.

La version 1.0 est officiellement sortie le 18 novembre, et est téléchargeable sur le site de wiQuery.

Brix

Matej Knopp, commiter Wicket, est venu nous présenter Brix.

Brix est un framework basé sur Wicket et JCR (Java Content Repository).  C’est un CMS qui permet :

• De gérer des pages
• De gérer des ressources (images, …)
• De gérer des templates.

Ainsi, une page Wicket peut être décorée avec un template Brix (lui-même pouvant contenir d’autres templates) avec l’utilisation de Tile.

Un Tile est un composant de gestion de contenu quelconque. Un ensemble de tags XHTML dédiés à brix sont utilisés pour insérer des tiles dans un template. Avec Brix, l’écriture d’un tile se limite à l’implémentation d’une interface. Cette interface demande d’implémenter deux factory methods : l’une pour le contenu du tile, l’autre pour son administration.

Brix permet d’élaborer son site de manière simple sans avoir une grande connaissance de l’HTML, ni même de Wicket. En effet, Brix fournit un backoffice pour administrer tous les composants, les pages et le templates utilisés (tel un vrai CMS). Des efforts ont aussi été faits sur la gestion d’urls, gros point faible de Wicket pour le référencement : Avec Brix, nous avons une application pouvant être administrée par un backoffice et surtout qui sera optimisée pour le référencement.

Brix offre également la possibilité de gérer les menus, ainsi qu’un ensemble de variables pour paramètrer les templates.

En résumé, c’st un outil d’aide à la génération d ‘une ossature pour son projet Wicket, où l’on définit une structure de nos pages à afficher (avec une configuration pour savoir comment elle réagit), avec la définition des différents menus et de ressources. A noter la compatibilité de Brix avec WebDav.

Les composants de Sven Meier

Sven Meier, codeur Wicket depuis maintenant cinq ans, est venu nous parler de trois projets qu’il mène de front :

• Wicket-Tree
• Wicket-DnD
• Wicketer

Wicket-Tree est un projet nous proposant d’insérer dans nos applications Wicket un composant de type TreeView. Celui-ci a pour but de remplacer le TreeView de Wicket-extension, qui est relativement lourd, compliqué et aussi utilisant bizarrement le TreeModel de Swing.

Wicket-DnD propose de pouvoir utiliser les composants Wicket via des Drag & Drop.

Enfin, Wicketer est un projet offrant la possibilité d’intéger dans son application un file manager.

Wicket 1.5

Martej Knopp nous a parlé des principales modifications de la prochaine mouture de Wicket : Wicket 1.5. Il semblerait que les commiters de Wicket ont la volonté forte de faire une refonte profonde de leur framework, notamment sur deux points majeurs : le RequestCycle (responsable du processus des requêtes) et de la gestion des urls.

La refonte du RequestCycle car celui-ci est jugé par les commiters comme étant beaucoup trop volumineux, beaucoup trop compliqué et extrêmement dur à appréhender. La nouvelle version sera (est) beaucoup plus légere et simple, avec un gain de traitement notable.

De même, la refonte de la gestion des urls était jugé nécessaire car également très compliqué, énormément de code dédié, beaucoup d’abstractions mais la plupart agissant sur un mauvais niveau et une hiérarchie très complexe. Le nouveau gestionnaire offrira des urls plus simple, ainsi qu’une possibilité de personnaliser ce gestionnaire grâce à un système de délégation. Ceci permettra de résoudre une attente des développeurs afin de faciliter le référencement de leurs applications Wicket.

De plus, ces deux refontes permettront de définir une nouvelle version de WicketTester.

Un autre point intéressant : l’évolution de l’API Javascript Ajax de Wicket. Les commiters souhaiteraient se baser sur un framework Javascript externe tel que YUI ou encore jQuery. Des expérimentations sont en cours afin de tester les différentes implémentations et d’envisager les différentes possibilités de migration.

En bref

Cette conférence nous a permis de découvrir quelles techniques pour améliorer nos applications Wicket, mais surtout de découvrir des frameworks permettant d’enrichir ou de faciliter la conception de nos sites Web, et enfin de découvrir les évolutions ambitieuses de Wicket 1.5.

A suivre !!

A son tour Novell se lance dans la convergence numérique en présentant une plateforme de réseau social et de collaboration sur documents en temps réel qui supporte le protocole Google Wave Federation.

Les utilisateurs de Novell Pulse (ainsi se nomme le nouvel outil), et ceux de Google Wave pourront ainsi travailler ensemble en toute transparence.

En savoir plus : le communiqué de presse de Novell et la page du produit sur le site de Novell.

Si comme moi vous ne disposez pas d’une table Microsoft Surface chez vous mais que vous avez envie de découvrir les possibilités offertes par ce Framework, c’est désormais possible !

D’abord réservé aux possesseurs de tables Surface, puis rendu disponible aux partenaires et aux étudiants, le SDK est désormais librement téléchargeable par le grand public à l’adresse suivante : Microsoft Surface SDK 1.0 SP1 Workstation Edition

Cette édition inclue un simulateur qui réplique l’interface utilisateur Surface sur votre PC, ainsi qu’un template de projet pour Visual Studio.

Vous pouvez également trouver de la documentation sur la page MSDN de Microsoft Surface ainsi que sur le site officiel de Microsoft Surface.

Si vous avez suivi mes billets sur le sujet, vous devez probablement vous demander quelle pile utiliser pour exposer un service en .NET: WCF ? .NET Ria services ? ADO.NET Data Services ?

Et bien Microsoft va unifier ces piles dans le framework 4 en proposant des extensions de WCF. Au passage, un renommage s’impose :

• ADO.NET Data Services (anciennement Astoria) devient WCF Data Services
• .NET RIA Services devient WCF RIA Services

Voici l’annonce de Mike Flasko.

Après Noop, Google annonce un nouveau langage de programmation : Go. Go reprend les points forts de C/C++ (efficacité, sécurité) et de Python (langage dynamique) voire de Java (Garbage collector).

A son habitude, Google a lancé un site dédié à ce langage avec de nombreuses documentations, pour amener le plus de développeurs possibles à l’utiliser.

En quelques mots, Go se veut un langage :

• simple
• rapide
• sur
• adapté aux multi-coeurs
• amusant
• et bien sur open-source.

Après 2 ans de développement, Google publie le code pour permettre de compléter ce langage open-source des bibliothèques qui augmenteront sa popularité. Pour autant, Google ne l’utilise pas encore, semble-t-il, pour ses développements internes.

Alors, Go ?

Plus d’info : l’annonce lue sur Zorgloob

Visual Studio 2010 Ultimate, le remplaçant de la suite Visual Studio Team System intègrera la suite TeamPrise client. Cette suite permet notamment d’accéder aux fonctionnalités d’ALM (Application lifecycle management) de Team Foundation Server depuis un environnement Eclipse: gestion des sources, gestion des tickets, gestion des builds et reporting.

Quelques détails sur l’acquisition de Microsoft.

Mais elle était si longue cette soirée ??? Pas assez malheureusement, beaucoup d’infos diffusées en très peu de temps, voici donc la dernière partie de notre compte-rendu …

Google Wave

Cette présentation, faite par Didier Girard et Salvador Diaz, fut une succession de démos Wave, M. Girard préférant nous montrer du concret … et il n’a pas eu tort. Juste pour rappel, Wave est une plateforme de collaboration web, qui essaie de réunir tous les moyens de communications actuels et de les regrouper dans une vague, une ‘wave’. Ainsi une wave est un flot de communication qui peut contenir toutes sortes de choses : du chat, des fichiers, des mails, des images. Une wave est une succession de ‘Blips’ : chaque composant qui s’ajoute dans une wave est donc un blip. Le langage Google Wave est maintenant défini !

Voyons maintenant comment développer sous Wave … une Wave peut contenir deux choses intéressantes :

• des gadgets : comme des gadgets iGoogle, sauf qu’il y a une notion multi utilisateur et shared context
• des robots (rien à voir avec Goldorak comme nous l’a subtilement fait remarquer Didier !) : participant automatique d’une wave

Comment développer un gadget ? Il suffit pour cela d’écrire une classe qui étends Gadget, d’écrire son comportement, et attention, de le déployer sous GAE !!! On parle là de la méthode Girard, on n’est pas obligé d’utiliser GAE, mais il semble clair qu’on aurait tort de s’en priver ! Ce fut l’objet de la première démo : Qui se cache derrière le coq ? Ce gadget anime la mascotte du jug, et lorsqu’on parvient à cliquer dessus, surprise : le visage d’Antonio Goncalves (co-fondateur du jug) apparait ! Forcément, ça a fait réagir positivement la salle, qui était pleine à craquer !

Comment développer un robot ? Il s’agit en fait d’une servlet, qui a pour mission d’écouter une wave, et qui est bindée à une appli sur GAE (par exemple). Un robot peut modifier le contenu d’une wave et communiquer à l’extérieur de la wave (autres waves, applis externes, persistence BD etc…). Pour développer un robot il faut étendre la classe AbstractRobotServlet pour définir le comportement du robot après avoir défini le scope de ses events dans le fichier capabilities.xml. Ceci fut l’objet de la deuxième démo où les membres de l’auditoire envoient des sms sur un numéro indiqué au début, et le robot réceptionne les sms et les affiche dans la wave … impressionnant et très interactif. Les intervenants ont même eu la bonne idée de créer un sondage sms pour savoir combien de personnes étaient intéressés par le prochain JUG. Ce fut l’occasion de se délecter des réponses de certains participants !

Pour en savoir plus sur le développement de gadgets, allez voir ici, et pour le développement des robots, allez voir là.

Lors d’une troisième démonstration, nous a été présentée une ébauche d’application de gestion hébergée sur une wave : une gestion de demandes de congés, avec la mise en place d’un workflow de validation. Bien qu’on n’ait pas pu bien voir le code, tout a été dit avec cette dernière démo : Google Wave peut être le théâtre d’un nouveau modèle de développement informatique, qui, associé à GAE (forcément me direz-vous), permet à Didier Girard de nous laisser entrevoir ce monde idéal où le développeur est au centre de l’innovation (développeur=innovateur selon ses propres termes).

Voilà donc que se termine cette soirée Google, somme toute assez riche, bien qu’inégale, et trop courte, on aurait pu parler pendant des heures de toutes ces technologies, et même d’autres (GWT 2.0 par exemple !), mais il ne s’agissait pas de refaire le Google I/O !… (ni un Google User Group d’ailleurs

Vous pouvez retrouver les slides de toutes les présentations (sauf de GoogleWave) ici (déjà linkés au fil des précédents posts).

N’oubliez la soirée Java EE 6 et Spring 3.0 qui aura lieu le 8 Décembre.

On se retrouve au prochain jug ?

Et la soirée Google continue … voici donc la suite de cette histoire.

APP Engine

Cette présentation fut menée par Guillaume Laforge, créateur de Groovy. On pouvait donc se douter de la coloration que pourrait prendre cette présentation GAE, qui tourna rapidement en présentation GAELyk, sucre Groovy pour exploiter sereinement les APIs GAE. Un bref résumé de ce qu’est le cloud computing, ou XaaS, soit :

• SaaS : Software as a Service
• PaaS : Platform as a Service <– positionnement Google avec GAE
• IaaS : Infrastructure as a Service

L’intérêt soudain de la communauté Java pour GAE s’est produit lors de l’annonce du support Java (JVM Sandbox, serveur Jetty) par GAE l’an dernier. L’intérêt est de faire héberger sur les plateformes Google une application web, donc un war, ce qui permet d’utiliser nos frameworks web préférés (GWT, Dojo, et même Flex !), et de ne pas se soucier des problématiques d’installation, de scaling …En plus de cela, il y a des services offerts par les APIs GAE très intéressants : gestion de la mémoire CPU ou de la persistance DB, l’url fetching (liens vers sites externes), mails, librairies de manipulation d’images, support XMPP (Gtalk), support de login Google, et pour finir, gestion des CRON et Task Queues.

Que du bonheur, sauf que voilà, rien n’est gratuit en ce bas monde, il y a des limitations :

• quotas : assez hauts, il faut générer beaucoup de traffic, mais il y a des quotas sur tous les services GAE : CPU, la mémoire , l’espace disque, les mails, les url fetch, xmpp … bref sur tout !
• pas une ‘vraie’ DB relationnelle : il s’agit de BigTable, sorte de Map (key/value), qu’on peut attaquer via JDO ou JPA (ouf !), mais il ne s’agit pas vraiment de SQL
• requêtes > 30sec interdites
• nombre de fichiers, ainsi que leur taille, limité

Voilà donc pour la présentation GAE, en ce qui concerne l’intégration Groovy avec Gaelyk, cela semble très sympathique, je vous invite à regarder la présentation de Guillaume et ses compères ici.

Le mardi 10 Novembre 2009 a eu lieu le JUG parisien sur Google, JUG qui s’est temporairement transformé en GUG !

Trois thèmes abordés lors de cette soirée : Androïd, GAE et Wave. Les présentations furent intéressantes bien qu’inégales, mais globalement toutes étaient trop courtes (environ 40 minutes pour chaque sujet, c’est peu).

Androïd

Je ne reprendrai pas l’historique d’Androïd, seulement la partie dév. Il faut savoir qu’Androïd est basé sur un noyau Linux 2.6 et un environnement Java, sauf que ce n’est pas du vrai Linux et qu’il n’embarque pas une JVM, mais une Dalvik VM, allégée et spécifique à des processeurs et unités mémoire de téléphone portable. De ce fait quand on veut développer une appli, on utilise un simili Java SE (AndroïdSDK, en v3 pour Androïd 2.0). Google livre donc un outillage spécifique : l’Androïd Development Toolkit (ADT) qui s’intègre sous Eclipse, qui offre un joli émulateur/debugger de Google Phone (Androïd Virtual Device) qui permet de visualiser le rendu de notre appli. L’environnement de développement offre une interface WYSIWYG (on peut sinon faire du declarativeUI, ou encore du programmaticUI), et manipule essentiellement 4 types de composants :

• les activités : composants graphiques, comparables à des widgets (une activité correspond à un écran)
• les services : comme son nom l’indique, il s’agit de services (fonctionnement comparable aux threads)
• les broadcast receivers : réception de message broadcast (exemple : message de batterie faible)
• les content providers : fournisseurs d’accès aux données publiques

On voit donc apparaître une notion de message, qui semble être une notion capitale dans le dév Androïd : on parle alors d’ « Intent ». Un intent, peut être soit explicite (cible un composant au sein d’une application) ou implicite; il s’agit alors d’un message qui circule entre toutes les applis Androïd (pas de couplage fort entre les applis ). Par manque de temps, la présentation s’est arrêtée ici, mais vous pouvez voir le support complet là.

La suite dans le prochain billet !

Mardi 10 Novembre dernier, dans les locaux d’Adobe au Trocadero, Christophe Coenraets (un évangéliste d’Adobe) nous a présenté trois nouveautés Flex 4, à savoir l’intégration de BlazeDS avec le framework Spring, le Model Driven Development avec LiceCycle Data Services 3, et enfin l’outil LiveCycle Mozaïc.

Voici donc un petit retour sur ce séminaire de 2h mené d’une main de maître par Christophe.

Adobe a récemment travaillé avec SpringSource pour faciliter l’intégration de BlazeDS (un framework pour la communication Flex/Java J2EE) avec le framework Spring. Christophe a réalisé plusieurs démos en live sur la différence avec/sans l’intégration Spring de BlazeDS. Différence nettement visible, puisqu’il s’agit de supprimer les fichiers de configuration de BlazeDS et d’allouer cette configuration à Spring, soit via la déclaration classique en XML, soit via les annotations Java5 directement dans les fichiers à exposer au client Flex (solution conseillée). La gestion de la sécurité d’accès à ces objets/méthodes passe également par Spring.

Deuxième sujet, le plus intéressant pour nous: le Model Driven Development grâce au serveur payant LiveCycle Data Services 3 (sortie officielle dans les prochains jours). Il sera maintenant possible de générer des interfaces Flex à partir du modèle, depuis une nouvelle perspective Eclipse, ou même de modifier ce modèle objet, poser des propriétés conditionnelles, des validations automatiques, des filtres, rendre des relations bidirectionnelles, etc.

L’outil génère ainsi la couche service à partir du modèle objet défini sous Eclipse, le déploie sur le serveur LiveCycle, et le connecte à l’interface Flex, tout cela en quelques clics. Pour vous faire une idée des possibilités, une vidéo de démonstration (la même qu’au séminaire):  http://coenraets.org/blog/2009/09/flex4mdd/

Enfin, dernier sujet abordé, LiveCycle Mozaïc, en cours de développement. Outil totalement inconnu pour moi, Christophe nous a présenté son intérêt, sans entrer dans les détails techniques (malheureusement). Mozaïc permet de connecter plusieurs applications Flex ou Web entre elles, sans qu’elles ne se « connaissent » auparavant. Chaque application est en fait une tuile, et l’ensemble des tuiles est affiché sur un dashboard interactif, et communique via Mozaïc.

Exemple: une tuile Flex permet de lister nos parts en bourse, une seconde tuile affiche le site salesforce avec le détail de l’action sélectionnée sur la première tuile. L’utilisateur choisit les tuiles qu’il souhaite faire collaborer. Techniquement, Mozaïc permet d’exposer certaines propriétés d’une application aux autres, et « d’écouter » (au sens « être prévenu de ») tout changement de valeur sur la propriété d’une autre application externe.

En résumé, la grande nouveauté est bien sûr le Model Driven Development, très prometteur. L’intégration BlazeDS/Spring est maintenant grandement facilitée, et Mozaïc permettra à l’avenir de faire collaborer plusieurs applications Flex/web entre elles.

Si vous avez des questions, n’hésitez pas !