Archive

Articles taggués ‘jquery’

On aime, on partage #3

Bienvenue dans la série « On aime, on partage » d’Objet Direct ! Chaque semaine retrouvez les meilleurs articles du web issues de notre veille technologique.

Java 8: Secure the train

Mark Reinhold, responsable du développement de Java SE chez Oracle, a annoncé la semaine dernière que la sortie Java serait repoussée au premier trimestre 2014. Initialement prévue pour septembre de cette année, il explique que ce choix est dû à une réorganisation des priorités. En effet, le plugin Java pour les navigateurs a beaucoup fait parler de lui ces derniers temps, à cause de failles de sécurité. Ils ont donc décidé de mettre l’accent sur la sécurité et de retarder de quelques mois la livraison de Java 8.


Sur le net, certains développeurs ont exprimé leur déception et se demandent s’il ne faudrait pas plutôt abandonner le support des technologies client (applets Java et Web Start). En effet, ces dernières sont les sources principales de failles de sécurité, tout en étant de moins en moins populaires et beaucoup moins utilisées que leur équivalent côté serveur.


L’annonce de Mark Reinhold : http://mreinhold.org/blog/secure-the-train

Commentaires de la communauté Java sur Twitter : https://twitter.com/mreinhold/status/325464368143794176

Sortie de jQuery 2.0

jQuery 2.0 est sorti ce 18 avril après 10 mois de développement. jQuery 2.0  ne supporte plus les versions 6,7 et 8 d’IE permettant ainsi de régler des problèmes d’incompatibilités et de performances. Deux branches distinctes sont donc développées actuellement:

  • une branche jQuery 1.X où les anciens navigateurs sont supportés

  • une branche jQuery 2.X

Vous trouverez plus de détails sur les changements apportés sur le blog de jQuery.

http://blog.jquery.com/2013/04/18/jquery-2-0-released/

Coding, Fast and Slow: Developers and the Psychology of Overconfidence

Dan Milstein, ingénieur chez Hut 8 Labs, se demande pourquoi sommes-nous si mauvais quand il s’agit d’estimer le coût de développement d’un logiciel.

Il met en avant deux causes : la première est que, pour pouvoir être précis, il faut avoir une connaissance totale de ce qu’il faut faire, et donc avoir des spécifications précises. Le problème est que, pour que ça marche, la spécification doit tellement être précise que cela revient à écrire le logiciel lui-même. L’autre source d’erreur est selon lui l’excès de confiance en soi, qui fait qu’un expert dans un domaine précis aura tendance à toujours croire à ses propres estimations, même si les échecs successifs lui montrent qu’il se trompe à chaque fois (voir aussi notre article sur l’art d’avoir tort).

En conclusion, il suggère que nous nous fassions à l’idée qu’il est impossible de faire des estimations précises sur plusieurs mois de travail, mais que nous pouvons contourner le problème grâce aux méthodes agiles. Il détaillera ce dernier point dans un prochain article.

http://blog.hut8labs.com/coding-fast-and-slow.html


What Makes Code Readable: Not What You Think

John Sonmez se propose de nous expliquer ce qui, selon lui, rend un code plus lisible. Dans un premier temps, il explique que ce qui est lisible pour un programmeur expérimenté l’est beaucoup moins pour un novice. Il prend comme exemple l’apprentissage de la lecture ou de la musique.

Il explique ensuite que plus une grammaire de langage est riche, plus il sera facile d’exprimer des concepts avancés de manière lisible et concise. La contrepartie sera un effort plus important pour maîtriser cette grammaire, ce qui peut faire le succès de langages plus simples donc plus facile à appréhender.

Il conclut que la lisibilité du code sera de plus en plus aisée au fur et à mesure que les lecteurs seront formés à ces langages.

http://java.dzone.com/articles/what-makes-code-readable-not

Merci à nos contributeurs de la semaine : Clément Plantier, Benoît Parmentier et Benjamin Marron

Nouveau plugin Bootstrap: Paginate

Bonjour,

Un petit message pour vous prévenir de la présence d’un nouveau plugin pour Bootstrap sur notre Github: bootstrap-paginate. Il a pour but de vous faciliter la tâche sur l’élément de pagination. Voici un exemple tout simple d’utilisation:

$("#paginate").paginate({
    pages: 5,
    pageChange: function(index) {
        $("table tbody").load("/user/paginate/" + index);
    }
});

Je vous invite à aller voir le lien suivant pour plus de détails sur son utilisation: https://github.com/ObjetDirect/javascript/tree/master/Bootstrap/bootstrap-paginate

En espérant que cela puisse vous être utile

Cordialement

Categories: Divers Tags: , , ,

Nouveau plugin Bootstrap: Wizard

Bonjour,

Un petit message pour vous prévenir de la présence d’un nouveau plugin pour Bootstrap sur notre Github: bootstrap-wizard.

Je vous invite à aller voir le lien suivant pour plus de détails sur son utilisation: https://github.com/ObjetDirect/javascript/tree/master/Bootstrap/bootstrap-wizard

En espérant que cela puisse vous être utile

Cordialement

Categories: Actualités, Divers Tags: , , ,

Objet Direct sur Github

Depuis quelques semaines déjà, Objet Direct est présent sur Github, dans le but de publier des plugins / frameworks OpenSource.

Au cours de développements en interne, lors de réalisations de prototypes, ou plus simplement lors de besoins sur nos projets, nous réaliserons des frameworks ou des plugins qui nous seront utiles par la suite, et que nous réutilisons.

Au sein d’Objet Direct, nous promouvons les solutions et les projets OpenSource. De part ce constat, nous avons décidé de publier ces frameworks / plugins afin de les rendre accessibles au plus grand nombre.

Si vous vous rendez sur notre repository Github (https://github.com/ObjetDirect), vous aurez à l’heure actuelle trois plugins:

Nous vous tiendrons informé des futures évolutions et ajouts.

Bien cordialement.

Categories: Divers, Mobile Tags: , , , ,

Sexy, le développement Web Mobile ?

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:

Son service sur mobile sans passer par une application native

Avoir son service sur mobile est devenu presque obligatoire vu le nombre en constante augmentation de personnes ayant un smartphone.

Le premier réflexe est de se lancer dans une application native. Cependant vu la disparité des plateformes (Iphone, Android, BlackBerry, Windows Mobile …), ce choix est actuellement extrêmement coûteux si vous voulez atteindre le plus grand panel de clients.

Or je pense que la plupart des applications natives sont souvent un portage simple de services en ligne. Il existe d’ailleurs des moyens d’afficher une page web dans un simple conteneur natif (c’était la logique des tous premiers iPhone). A coté de ça, les navigateurs embarqués sur les smartphones sont souvent très avancés et gèrent aussi bien Javascript que le standard W3C qui monte, c’est à dire HTML 5 !

De nombreux projets commerciaux ou open source, se sont d’ailleurs lancés sur le sujet afin d’offrir des solutions portables sur n’importe quel navigateur embarqué.

Certains sont simplement une librairie Javascript permettant de gérer les évènements tactiles (http://xuijs.com/docs/event par exemple). D’autres se chargent de donner un large accès aux API natives du framework (http://www.phonegap.com/about par exemple).
Suivant la nature du besoin, vous ferez glisser votre choix entre ces deux types.

Pour le service que je comptais faire passer en version mobile, le choix s’est porté sur des frameworks situés au milieu en particulier Sencha Touch et JQuery Mobile. Tous les deux se basent sur HTML 5 pour faciliter la version mobile.

Sencha Touch est assez avancé dans ses possibilités (surtout qu’il est possible de le combiner avec PhoneGap) mais c’est un framework nécessitant une réelle prise en main. Au contraire, JQuery Mobile permet de facilement passer son site en version mobile. De plus la réputation de la librairie JQuery et sa connaissance répandue permettent de travailler rapidement avec JQuery Mobile.

Voila le résultat d’un prototype obtenu en quelques jours. Le design est encore perfectible mais nous avions le cœur du service largement utilisable sur un mobile.

Pour moi, c’est vraiment une solution efficace pour un coût tout à fait raisonnable afin de porter son service sur mobile.

Pleins d’autres exemples concrets sur ce site : http://www.jqmgallery.com/

Categories: Mobile Tags: ,

wiQuery en 1.1 !!

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

Categories: Java EE, RIA, Wiquery Tags: , , , ,

Nouvelles versions de wiQuery !!

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

Categories: Wiquery Tags: , , ,

Présentation de wiQuery

odlabs-logoAu 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

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).

quelquescomposantjqueryui

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.

structurewiquery

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 :

wiQueryCode1

Il nous suffit de taper le code wiQuery suivant :

wiQueryCode2

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 :

wiQueryCode3

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 :

wiQueryCode4

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

wiQueryCode5

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.

wiQueryCode6

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 :

wiQueryCode7

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 :

wiQueryCode8

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 :

wiQueryCode9

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é.

Categories: Java EE, Wiquery Tags: , , ,

Retour sur le séminaire jWeekend

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.

jweekendDes 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 ThomersonJeremy 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 :

jweekend_code_1

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.

jweekend_code_2

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

Lionel ArmanetLors 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 KnoppMatej 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 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 !!

Categories: Java EE, Wiquery Tags: , , , ,