Blog Objet Direct

Le jeudi 19 Avril 2012, j’ai eu la chance de pouvoir présenter un « quickie » (présentation qui dure environ une quinzaine de minutes) à la première édition de Devoxx France, qui a lieu au Mariott Hotel à Paris.

Je vous propose ci-dessous une synthèse de ma présentation « Sexy, le développement Web mobile ? »

Commençons par un constat :

On estime que la moitié des connexions à l’Internet se feront à travers nos smartphones d’ici 2014. En début d’année, Twitter a déclaré que 30% des tweets se font à travers les smartphones, et 18% uniquement via le site Web Mobile.

Ainsi, il est devenu important, et même vital, d’être visible et présent sur le monde de la mobilité. On ne peut s’y tromper : 70% des entreprises ont soit une application mobile, soit une application en cours de développement ou envisage d’en avoir une.

A l’heure actuelle, les entreprises ont le choix principalement entre

• le développement d’applications natives (pour iOS, Android, Blackberry),
• le développement Web Mobile (se basant sur les technologies Web modernes comme HTML5 et CSS3)
• ou encore le développement Web Mobile hybride (qui fait le pont entre les deux univers précédents, le framework phare étant Cordova, le nouveau nom de PhoneGap).

Il existe d’autres approches, mais elles restent « exotiques ».

Quels sont les avantages du natif ?

Le développement natif permet tout d’abord, l’accès aux couches basses  du smartphone (SMS, répertoire, etc.) ce que ne permettent pas les autres approches.

Chaque plateforme (iOs, Android, …) propose ensuite un ensemble d’outils / environnements de développement propre facilitant la conception et la réalisation d’applications très performantes.

Enfin l’approche native offre la possibilité de publication de son application au travers des « markets » (Apple store, android market) permettant ainsi sa diffusion à large échelle.

Par contre cela implique de développer la même application pour chaque plateforme cible, soit à minima 3 versions différentes (Android, iOs et BBY) afin d’adresser 95% du marché des smartphones et tablettes, ce qui coûte bien évidemment du temps et de l’argent, et amène le problème des ressources.

En effet, pour le monde Android et Blackberry, un profil de développement avec des compétences Java pourra prendre en main rapidement ces environnements, tandis que poir iOS, les compétences restent rares, et la montée en compétence est reconnue comme longue et douloureuse.

            

Le web mobile

Premier avantage : plusieurs plateformes sont ciblées ce qui permet une réduction des coûts. Il y aura cependant des adaptations à faire, notamment en ce qui concerne les IHM et le code. Mais étant donné qu’on est dans le monde du Web, on est habitué à faire des adaptions, pour les différents navigateurs et leurs différentes versions. Ainsi, on peut toujours espérer avoir un code commun à plus de 95%.

Les performances du Web Mobile sont vraiment correctes. Quand j’ai écrit ma première application il y a de cela 2 ans, j’ai été bluffé par la vélocité (je m’attendais à ce que ce soit très lent, car j’avais un très grand nombre de fichiers JavaScipts). Grâce à HTML5 et CSS3, l’interaction avec le smartphone et l’utilisateur est plutôt bonne, avec une IHM professionnelle (je peux citer le site du New York Times, qui est fait en CSS3 et qui est bluffant).

En revanche, il n’est pas possible de créer des applications nécessitant de hautes performances, comme pour la réalité augmentée. On ne peut pas accéder à toutes les couches basses. Et l’ergonomie n’est pas à 100% en adéquation avec la plateforme (ce qui est normal vu que nous faisons une application pivot).

Pourquoi alors je considère que le développement Web Mobile est sexy ? D’une part, on trouve des moteurs Web modernes et performants (pour être plus précis, on trouve Webkit !). Pour rappel, le premier moteur Web HTML5 se trouvait sur un smartphone, et plus précisément sur un iPhone … en 2007 !! Alors qu’il faudra attendre plusieurs mois encore avant de voir en apparaitre un sur Desktop. La compatibilité HTML5 et CSS3 est très bonne. Il faut juste s’assurer que les fonctionnalités ont été activées. Par exemple, WebSocket n’est pas accessible sous Android alors qu’il l’est sur iOS et Blackberry.

Une communauté de plus en plus forte s’est formée ces dernières années, autour de nombreux sites dédiés à ce sujet, comme html5rocks.com, qui fût le premier site à expliquer HTML5 et à donner des tutoriaux. Je regarde régulièrement ce site qui reste pour moi une bible.

Et tout cela s’articule autour de technologies adaptées et en évolution que sont HTML5 et CSS3. Le terme « évolution » est important ici, car si on va voir sur le site du W3C, ces deux technologiess sont encore en état de brouillon. Pour CSS3, c’est quasi-finalisée. Pour HTML5, de nombreuses fonctionnalités sont proposées de mois en mois. Par exemple, courant 2011, une API a été proposée pour accéder à la liste des contacts du téléphone. Début 2012, une autre proposait de faire vibrer le téléphone. Ainsi, le Web Mobile mute de plus en plus afin de pouvoir mieux s’intégrer à nos smartphones.

          

De plus, il est possible de faire du Web Mobile hybride ! Cela consiste à embarquer nos fichiers HTML5, CSS3 et JavaScript au sein d’un wrapper natif. Cela permet non seulement d’être présent sur les markets, mais aussi de faire un pont entre nos pages Web et le natif. On peut imaginer de pouvoir lister nos SMS sur une page Web en communiquant via JSON au natif qui lui va s’occuper de chercher les dits SMS.

Techniquement, que devons-nous utiliser ?

Pour commencer, on aura besoin d’HTML5, de CSS3 et de JavaScript. Mais il ne faut pas perdre de vue que le W3C propose des fondations ! Ainsi, on ne trouvera pas de base des widgets fancy ou sexy. On va donc utiliser des frameworks JavaScripts adaptés, comme jQuery Mobile de « The Filament Group » (que j’utilise massivement) ou encore la solution payante qu’est SenchaTouch de Sencha Labs.

          

Il existe deux frameworks assez récents qui sont prometteurs, et les deux se basant sur jQuery. Le premier est KendoUI (solution payante) qui propose des widgets assez puissant, basé sur HTML5/CSS3, qui rivalisent vraiment avec ceux de jQuery UI. Il s’adapte également pour le Web Mobile, notamment sur le style d’affichage très proche de la plateforme où le site s’affiche. Ensuite, on trouve Bootstrap, par l’équipe de Github, qui propose un framework léger, simple à utiliser et surtout Design Responsive. Un framework vraiment prometteur.

           

Si on souhaite faire du Web Mobile hybride, on va utiliser un framework comme Apache Cordova (anciennement, PhoneGap), qui propose des enveloppes natives pour de nombreuses plateformes (comme iOS, Android, Blackberry, Windows Phone 7, Bada …) et aussi une API JavaScript permettant d’accéder à une partie des couches basses. Cette API va être fortement enrichie dans sa version 2.0, et il est à noter que ce framework propose un système de plugin. Personnellement, j’ai écrit un petit plugin Android pour dialoguer avec l’application native Twitter, et j’ai pu le faire simplement grâce à cela.

     

Néanmoins, il faut faire attention lorsqu’on utilise le Web Mobile. D’une part, il faut se forger une expérience Web Mobile. Il faut évidemment apprendre de nouvelles technos/frameworks, mais également prendre en compte des problèmes qu’on a l’habitude mettre de côté, comme la taille de l’écran, bien plus petite que nos écrans de bureau (la norme maintenant est 1024 par 768, mais on estime que la prochaine norme sera la taille d’une tablette, voire d’un smartphone), ainsi que le débit du réseau (la 3G ne rivalisant pas avec la fibre d’entreprise).

De plus, il faut s’assurer de l’adéquation entre le besoin et la solution. Si votre client souhaite une ergonomie parfaitement en adéquation avec la plateforme, ou de hautes performances, le Web Mobile n’est pas fait pour vous.

Néanmoins, celui-ci peut répondre à plus de 85% des besoins qu’on peut rencontrer. Ainsi, selon moi, il ne faut pas hésiter à sauter le pas car le Web Mobile à mes yeux a un avenir prometteur et va dans le bon sens. Et je n’hésite pas dire que le développement Web Mobile est sexy !

Vous pouvez consulter les slides de ma présentation sur le lien suivant:

Afin de cibler un public plus large – généralement iOS et Android – nombre d’entre nous avons décidé de nous lancer dans la création d’applications Web mobile.

L’outillage est souvent vu par les développeurs comme un point faible du Web Mobile par rapport à des approches de développement plus traditionnelles : Objective C ou Java. Comment par exemple déboguer et analyser une application qui s’exécute sur le mobile ?

En effet, bien que les smartphones et les tablettes utilisent très massivement le moteur de rendu Webkit (à l’exception de Windows Phone), ces derniers le configurent de manière différente. Ainsi, certaines fonctionnalités de HTML5/CSS3 sont désactivées, ou encore le comportement des pages peut varier.

Pour ma part, avant d’utiliser Weinre, je commençais par tester mon application dans Google Chrome en mode non sécurisé (désactivation de la sécurité cross-domain, accès aux fichiers locaux) et  en exploitant les nombreux outils et plugins de Chrome. Pour avoir la sensation d’être sur un mobile, j’incorporais mon application dans un template représentant un smartphone.

Enfin, je terminais mes tests en lançant l’application sur les différents émulateurs et simulateurs. Néanmoins, quand l’affichage n’était pas satisfaisant, j’étais obligé de modifier HTML, CSS et JavaScript souvent en tâtonnant et de recommencer les tests jusqu’à trouver la solution : ce qui était long et fastidieux.

Heureusement pour nous, un outil vient nous aider : Weinre !

Cet outil est intégré dans la solution Cloud de PhoneGap. Il permet d’analyser son application Web à distance ! Et cela très facilement ! Pour cela, rien de plus simple, télécharger le projet puis taper la commande suivante :

java -jar "DIRECTORY_PATH\weinre.jar" -httpPort 8081 -boundHost -all-

A partir de là, vous pouvez ouvrir sur votre navigateur de bureau deux liens :

• http://127.0.0.1:8081/
  • Lien principal détaillant la marche à suivre

• http://127.0.0.1:8081/client/
• Lien permettant de voir vos pages actuellements utilisées sur les smartphones et tablettes

Ensuite, il suffit d’ajouter ce bout de script en bas de votre page HTML (dans le tag BODY, évidemment) :

<!– —————————————————————— –>

<!– ————————– Weinre Part ————————— –>

<!– ——————— For debugging —————————— –>

<script type= »text/javascript » src= »http://youripaddress:8081/target/target-script-min.js#anonymous »></script>

<!– —————————————————————— –>

Et voilà ! Désormais, c’est à vous de jouer !

En vous rendant sur le lien http://127.0.0.1:8081/client/, vous ferez alors une liste de liens. Elle correspond aux pages qui se sont connectés sur notre serveur Weinre.

Nous pouvons cliquer sur l’un des liens et alors nous pourronsons naviguer dans l’explorateur de DOM et de CSS, le gestionnaire de ressources et la console JavaScript.

Et ce qui est pas mal, c’est que lorsque nous inspectons un élément DOM, l’élément est en surbrillance sur la page à distance !

Voilà comment installer et utiliser un outil tout simple qui va nous faciliter la vie.

Petit article sur une série de conférences qui a lieu sur Londres du 9 au 12 Mars 2011 : la QCon London.  Pour rappel, la QCon est organisée par InfoQ, une communauté indépendante sur l’Internet axée sur la veille, l’innovation technologique et l’agilité..

Les conférences révèlent les grandes tendances dans le monde, à savoir le Cloud, la mobilité, les bases de données NoSQL, HTML5 et enfin les nouvelles méthodes de gestion de projets  telles que Lean et Kanban. D’ailleurs, la première journée s’est ouverte par une excellente conférence de Craig Larman. Il  nous a exposé ses retours d’expériences, ses points de vue et les bonnes pratiques à adopter vis-à-vis de Lean et de son utilisation dans des gros projets nécessitant de nombreuses équipes réparties dans le monde. Grosso modo, il faut monter des petites équipes (d’environ 10 personnes) polyvalentes avec une personne par site qui orientera les personnes des autres sites vers le bon interlocuteur, et surtout utiliser la visioconférence, car « voir, c’est croire ».

Nous avons pu également avoir un aperçu du futur de Java. Ce dernier se repose sur deux dates : fin 2011 et fin 2012. Nous devrions voir arriver d’ici la fin de l’année le très attendu Java 7, dont le numéro pourrait refléter le nombre d’années de retard. Celui-ci s’orientera principalement sur une modification de la JVM afin qu’elle puisse supporter plus facilement des langages pur objet tel que Ruby, et aussi sur une meilleure gestion du traitement en parallèle, grâce à l’api java.util.concurrency. Fin 2012 verra la naissance de Java 8 qui apportera plus de nouveautés dans le langage avec les très attendues lambda fonctions, quelques nouveaux sucres syntaxiques pour facilité l’écriture, et aussi un mécanisme intéressant pour enrichir les interfaces sans impacter les implémentations (en proposant une implémentation par défaut, un peu comme les valeurs par défaut dans les annotations).

Nous avons pu également apprendre sur les futures orientations choisies pour JEE7. Celui-ci s’oriente naturellement vers le cloud (privé ?) avec la virtualisation du serveur d’application. Un exemple nous a été donné avec le serveur GlassFish 3.1 où avec un simple fichier déclaratif « cloud.xml », nous pouvions spécifier le nombre minimum d’instances de GlassFish sur lesquelles déployer l’application. Nous avons assisté au déploiement de l’application sur les 3 serveurs d’application et au monitoring de leur activité. A noter que chacune des instances était placée dans une machine virtuelle (certainement gérée par VirtualBox de Oracle).JEE7 améliorera aussi l’isolation des applications, gèrera la coexistence de versions différentes d’une même application. Un support d’HTML5 est prévu, comme le support du JSON, des WebSockets (déjà planifié pour JSF 2.2), des nouveaux types de champs pour les formulaires.

Ses conférences ont aussi été l’occasion de rencontrer des gens de FaceBook. Ils nous ont parlé de l’utilisation d’HTML5 pour la version mobile de leur site (et de la création de la communauté WURFL pour référencer les spécificités de chaque mobile sur l’HTML). Les gens de Twitter nous ont parlé de la gestion de leurs données et de leurs volumétries extrêmes (près d’un milliard de tweets sont enregistrés par mois, ce qui représente pas loin de 300 Go de données). Nous avons pu aussi compter sur Google qui nous a expliqué leurs démarches par rapport à l’innovation avec la mise en avant du « pretotyping ». Son but  : voir si l’intérêt des gens par rapport à une idée se maintient dans la durée Cela consiste à « créer » une maquette très simpliste. Le cas plus célèbre est celui du créateur du Palm qui avant de créer le 1^er appareil avait fait des fiches sur un carnet pour représenter son interface et tester son idée en simulant les actions courantes.

Nous avons aussi assisté à une conférence de Netflix expliquant la stratégie retenue pour migrer des données d’une base Oracle vers une base NoSQL. L’infrastructure retenue fut celle d’Amazon. La migration a pris environ 2 ans. Ils ont du redévelopper un certain nombre de services de base comme la sauvegarde / restauration. Ils ont commencé avec SimpleDB et continué avec Cassandra. La conférence a été l’occasion d’un retour d’expérience très riche au travers de la présentation de nombreuses bonnes pratiques. La présentation est disponible ici : http://qconlondon.com/london-2011/file?path=/qcon-london-2011/slides/SiddharthAnand_NoSQLNetflix.pdf

Les slides peuvent être téléchargés sur le site de la QCon (http://qconlondon.com) et sur le site d’InfoQ, vous pourrez voir dans les semaines qui arrivent les vidéos prisent lors des conférences.

Julien Roche & Philippe Guédez

Bonjour à tous,

Désormais, vous pourrez trouver sur le dépôt maven de wiQuery deux nouvelles versions (encore une fois !): la 1.0.3 and surtout la 1.1 !! Celle-ci se base sur jQuery UI 1.8.5 et offre de nouveaux composants. Mais surtout, un gros travail de refonte et d’actualisation a été apporté vis-à-vis des nouveautés qu’apporte Wicket (nous nous basons désormais sur la version 1.4.12 où nous pouvons trouver un tout nouveau listener depuis la 1.4.9:  IComponentOnBeforeRenderListener).

Désormais, et vu que le nombre de committers officiels a augmenté, nous allons essayer de publier tous les deux mois une nouvelle version de wiQuery.

La prochaine version, la 1.2, est donc prévu pour courant Janvier. Elle proposera aux utilisateurs des composants de bases plus poussés et aussi la possibilité d’utiliser les modèles Wicket. Également, de nombreux axes de travail sont prévus:

• Création d’un site dédié à wiQuery
• Documentation renforcée
• Exemples / démonstrations renforcés
• Étude de faisabilité pour un wiQuery-mobile (avec jQuery mobile)
• Création d’une extension avec prévision d’insertion dans le cœur de wiQuery qui utilisera les widgets Wijmo !! Ce sont des widgets avancées qui se basent sur jQuery UI !! Petits exemples: http://wijmo.com/Wijmo-Complete/samples/

Pour plus d’informations, rendez-vous sur le site officiel du projet: http://code.google.com/p/wiquery/

De grands remerciements aux membres de jWeekend, de Wicket et aux committers officiels qui ont permis la sortie de cette 1.1.

Bon weekend à tous !!

Bonjour,

Après 6 mois d’attente, l’équipe wiQuery est fière de sortir non pas une mais deux versions de son framework: la version 1.0.2 et la version 1.1-alpha.

La version 1.0.2 corrige de nombreux bugs (certains majeurs) et propose enfin des options de configurations pour le framework wiQuery. Également, il n’y a plus besoin de s’embêter pour l’initialisation de wiQuery.: grâce à la mécanique Wicket, cela se fait tout seul !! (il suffit d’importer le jar dans son projet, et voilà !).

La version 1.1-alpha est une pré-version où nous avons basculé sur jQuery UI 1.8.4 et proposons ainsi de nouveaux composants, tels que Button, AutoComplete ou encore InlineDatePicker.

Pour plus d’informations, rendez-vous sur le site officiel du projet: http://code.google.com/p/wiquery/

De grands remerciements aux membres de jWeekend, aux commiters officiels (Lionel Armanet, Ernesto Reinaldo Barreiro, Julien Roche et François Delalande) et aux simples contributeurs qui ont permis de faire avancer ce projet.

Bon weekend à tous !!

Au sein du groupe Objet Direct est né un laboratoire de nouvelles technologies : OD Labs. L’objectif de ce dernier est d’être un pôle d’innovation, mais aussi de soutenir des projets innovants dont l’un d’entre eux se nomme wiQuery.

wiQuery est un projet OpenSource (régi sous la licence MIT), qui se propose de coupler et de faciliter l’utilisation de Wicket avec jQuery afin d’obtenir des composants et des comportements riches, mais aussi d’offrir des composants Wicket couplés avec jQuery UI et de pouvoir insérer les plugins jQuery existant.

Introduction

Pourquoi jQuery ? Tout simplement parce que c’est un framework javascript qui est simple d’utilisation, performant, et aussi non intrusif. De plus, de très nombreux plugins sont issus de ce framework, notamment jQuery UI, qui propose des composants, des effets et des comportements très intéressants (encore plus dans la prochaine version).

Quelques composants riches

Si nous voulions intégrer un plugin jQuery dans Wicket, que nous faudrait-il faire ?

1. Importer les ressources javascripts et CSS liées à ce plugin
2. Générer / écrire du code javascript / jQuery afin de pouvoir exécuter le plugin
3. Ecrire le code Java / Wicket, ainsi que le fichier XHTML lié.

wiQuery se propose de s’occuper des deux premiers points, de faciliter l’écriture du code Wicket mais aussi de générer et d’injecter le code javascript au bon moment, à savoir soit au chargement de la page, soit lors d’une transaction Ajax.

Structure de wiQuery

La base de wiQuery se constitue d’un générateur de code jQuery, qui permet ainsi à la mécanique de plugin de les utiliser dans des composants ou des behaviors Wicket. Ce système de plugin a permis d’insérer tous les composants, effets et comportements actuels de jQuery UI et permet également d’intégrer n’importe quel plugin jQuery et d’y accéder via Wicket.

Le générateur de javascript / jQuery

Le générateur code se divise en trois grands types d’objets :

• JsStatement : C’est le type principal. Il a pour but de chainer des portions de code javascript et offre des méthodes afin d’écrire de manière simplifiée et guidée du code jQuery.
• JsQuery : Cet objet se base sur l’élément précédent afin de créer un sélecteur jQuery à qui nous pouvons chainer des méthodes et des arguments.
• JsScope : Cet objet a pour but de créer une fonction (closure) javascript.

Ainsi, pour générer le code jQuery suivant pour l’appliquer sur un composant Wicket :

Il nous suffit de taper le code wiQuery suivant :

Petite remarque tout de même : il est utile d’utiliser ce générateur dans le cas où nous voulons générer des petites portions de code Javascript / jQuery. Si votre objectif est d’intégrer un plugin de votre composition, il vaut mieux écrire le fichier .js et l’importer en tant que ressource wiQuery.

Comment intégrer wiQuery ?

Il existe deux moyens simples d’intégrer wiQuery à son application Wicket :

1. Hériter de la classe WiQueryWebApplication,
2. Si le point précédent ne vous est pas possible, il suffit dans la méthode init() de votre classe Application d’insérer le bout de code suivant, activant ainsi pleinement wiQuery :

Evénements Javascript

Le framework wiQuery vous permet de coupler vos composants Wicket à des événements Javascripts. Dans un premier temps, nous pouvons juste exécuter du code javascript simple, côté client :

Dans un second temps, l’événement javascript peut effectuer une transaction Ajax, afin de pouvoir exécuter un traitement côté serveur :

wiQuery UI

Comme dit plutôt dans cet article, wiQuery a intégré le framework javascript jQuery UI. Ainsi, nous pouvons disposer en Wicket des composants suivants :

• Un accordéon
• Une fenêtre de dialogue
• Un slider
• Une barre de progression
• Des onglets
• Un datepicker

Pour ce qui concerne les behaviors Wicket, nous avons les comportements suivants :

• Draggable
• Droppable
• Sortable
• Resizable
• Selectable

Il est à noter que ces derniers peuvent s’utiliser de deux manières : soit de manière classique, activant ainsi le comportement, soit de manière Ajax. Dans ce dernier cas, selon le comportement, des événements importants pourront être relevés et transmis via Ajax. Ces événements seront répercutés directement dans votre code Wicket. Par exemple sur le comportement « Droppable », nous aurons un événement levé et dans la méthode wiQuery « onDrop » (que vous aurez à déclarer), le composant Wicket qui aura été déposé dans la zone de drop sera fourni.

Créer ses plugins

wiQuery est un framework d’intégration. De ce fait, il permet d’élaborer des plugins wiQuery et de les intégrer / exécuter au sein du framework. C’est ainsi qu’a été intégré le plugin jQuery UI.

Pour cela, vous avez accès :

1. A l’interface IWiqueryPlugin qui vous demandera d’implémenter deux méthodes. L’une demandant de charger les ressources Javascript et CSS de votre plugin. L’autre demande de générer le code Javascript / jQuery pour faire fonctionner le plugin. La présence de cette interface permet de charger automatiquement le cœur de jQuery.
2. A l’annotation @WiqueryUIPlugin. Elle permet d’indiquer à wiQuery qu’il faut le cœur de jQuery UI ainsi que le thème jQuery UI.

De ce fait, si nous voulions écrire un plugin pour faire marcher le Slider jQuery UI (déjà présente dans l’API), il nous suffirait de taper le code suivant :

Appliquer des thèmes

Des thèmes (issues de jQuery UI) peuvent être appliqués sur les composants et behaviors wiQuery UI. Pour cela, rien de plus simple, il suffit d’implémenter sur votre classe d’application Wicket l’interface IThemableApplication :

De plus, il possible d’appliquer des parties de ces thèmes sur des composants Wicket non issus de wiQuery. Par exemple, vous avez un bouton, et vous voulez qu’il reprenne le style du thème en cours, il vous suffira de faire :

L’avenir de wiQuery

A l’heure actuelle, la version de wiQuery est la 1.0, et se base sur Wicket 1.4.3, jQuery 1.3.2 et sur jQuery UI 1.7.2. Tous les composants de jQuery UI ont été intégrés, une mécanique de génération de javascript a été mise en place et un système permet d’appliquer les thèmes. De plus, une petite communauté se forme, et sur le site de wiQuery, vous pourrez trouver des vidéos d’aide et une application de démonstration, où pour chaque exemple, vous avez le code Java / XHTML.

La prochaine mouture de wiQuery est la 1.1. Elle s’efforcera de monter les nouvelles versions des différents frameworks utilisés: jQuery 1.4, jQuery 1.8 (avec les nouveaux composants,) et Wicket 1.4.6. L’objectif sera également de renforcer la communauté wiQuery, de fournir plus de documentations, de vidéos, d’exemples, mais surtout de mettre en place une communauté de plugins wiQuery (dont certains seront développés par l’équipe de wiQuery)  que vous pourrez ainsi télécharger et utiliser au sein de vos applications Wicket.

La mouture wiQuery 1.2 quant à elle comprendra la possibilité d’utiliser les IModel de Wicket comme options aux composants wiQuery. Elle s’efforcera également de préserver l’état des composants côté serveur et aussi de proposer des composants wiQuery UI plus poussé.

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 !!

jWeekend (société spécialisée dans le développement, dans le consulting et dans la formation Wicket) organise régulièrement sur Londres (environ tous les deux mois) des séminaires Wicket: le London Wicket. Ces derniers ont pour objectif de discuter des évolutions et des idées pour enrichir ce framework, mais aussi de parler de tout projet se basant sur ce framework.

Le prochain séminaire aura lieu le samedi 21 Novembre, où Lionel Armanet présentera l’un des projets d’OD Labs qu’il a fondé : wiQuery (framework proposant l’élaboration de composants Wicket utilisant le framework javascript jQuery et jQuery UI). Il sera accompagné de François Delalande et de Julien Roche.

Egalement, nous aurons une intervention de Jeremy Thomerson qui viendra nous parler de l’intégration de javascript avec Wicket. Matej Knopp viendra nous parler de BRIX, framework proposant un gestionnaire de contenu basé sur Wicket et sur JCR (Java Content Repository). Et enfin, Alastair Maw (membre et un des leaders du projet Wicket)  nous exposera l’évolution et  l’état actuel de Wicket.

Nous ne manquerons pas de vous faire un compte rendu dans notre blog de tout ce qui s’est dit à ce séminaire.

A très bientôt.