Archive

Archives pour la catégorie ‘RIA’

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: , , ,

Framework GWT : GXT vs SmartGWT

Si Google Web Toolkit est un excellent framework Web, il souffre d’un manque flagrant d’éléments graphiques et, bien qu’il existe des bibliothèques comme gwt-incubator, il est parfois très intéressant d’utiliser des frameworks bien plus complets se basant sur GWT. Suite au changement de licence de ExtJS et la fin de GWT Ext, on retrouve maintenant deux frameworks au dessus de GWT 2.0 : SmartGWT et GXT. SmartGWT est un wrapper de la librairie Javascript SmartClient vers GWT alors que GXT est une réelle surcouche à GWT.

La démo de GXT

La démo de GXT

La démo de SmartGWT

La démo de SmartGWT

J’ai l’occasion en ce moment de travailler sur GXT qui a été choisi par le client pour la migration de son application de GWT 1.5 + GWT Ext (devenu donc obsolète et non maintenu) vers GWT 2.0 et GXT. J’ai donc pu découvrir le code et l’architecture de GXT. A coté de ça, je suis allé comment fonctionnait SmartGWT et parcouru les différentes discussions sur internet.

Le choix entre ces deux frameworks est une étape cruciale et assez difficile. Les deux ont leurs détracteurs et leurs défenseurs.

Certaines personnes défendent même l’utilisation seule de GWT 2. Ces deux frameworks se marient d’ailleurs très mal avec le nouveau UIBinder. Cependant, comme le fait remarquer très justement un des contributeurs de SmartGWT, il faudrait plusieurs mois pour recréer les widgets qu’ils offrent.

La principale différence entre ces deux framework GWT est que GXT est purement Java et donc rentre dans la logique complète de compilation java en javascript de GWT alors que SmartGWT est un wrapper. C’est d’ailleurs cet élément qui amène le plus de détracteurs à celui-ci : lenteur, lourdeur du chargement initial, quid d’un changement de licence chez SmartClient – la librairie Javascript encapsulée, difficulté à étendre les classes pour répondre à des besoins particuliers… Google Web Toolkit ne peut pas optimiser le code javascript. Les contributeurs de SmartGWT plutôt actifs se défendent avec vigueur sur ces points :)

GXT serait lui moins complet et moins configurable sur l’apparence. D’après ce que j’ai pu voir en parcourant leurs exemples, je pense que c’est configurable avec l’utilisation de Template ()voir un très bon exemple ici)qui est un mécanisme très intéressant. En parcourant les exemples j’ai vu qu’il était possible de « templater » le rendu par exemple une liste pour créer un browser d’image. Je trouve le principe simple et bien flexible ! GXT est écrit en Java/GWT contrairement aux nombreux wrapper Javascript (SmartGWT en tête). Ainsi la compilation n’inoculera que les ressources nécessaires, le débogage se fait en java y compris dans les composants, l’extension de composant est beaucoup plus naturelle et se fait en java.
Cependant tout n’est pas rose sur GXT. D’abord le framework souffre d’un énorme problème au niveau de sa documentation. Si rentrer dans la logique de l’architecture n’est pas d’une complexité insurmontable, il va falloir se débrouiller avec la Javadoc et les exemples finalement pas si nombreux et complets. Pour moi, c’est clairement le point noir de GXT. Ensuite il existe des bugs (JSONLoader dont le templating ne sert à rien) et petites choses à savoir (mettre une taille dans une ColumnConfig pour la voir réellement apparaître !) qui font parfois perdre beaucoup de temps.
Ensuite de façon plus idéologique, GXT ne suit pas entièrement la logique de GWT. GXT utilise une logique MVC et non MVP préconisé par les ingénieurs de Google ainsi que des listener et non des handlers qui sont la norme depuis GWT 1.6.
GXT propose comme GWT Ext un manager central des composants graphiques lorsqu’ils sont référencés par un ID. Cependant c’est parfois difficile à utiliser car ils ne sont réellement référencés dans le manager que lorsqu’ils ont été rendu graphiquement (et pas simplement ajouté dans le constructeur). Par exemple les tabs items ne sont rendus que lorsque l’utilisateur clique sur les onglets correspondant.

Il faut aussi évoquer les problèmes de licences. Si SmartGWT se base sur SmartClient est donc hérite d’une licence LGPL. GXT est lui sous licence GNU GPL V3. Il faudra payer une licence si vous voulez utilisez GXT pour vendre un produit propriétaire ou si vous voulez un support actif de Sencha (l’entreprise derrière GXT).

Dans tous les cas, ces deux frameworks sont impressionnants et confirme l’intérêt porté à GWT ainsi que ces possibilités. La logique programmation en fait des frameworks relativement facile à appréhender (widget, layout, event) et le full Java permet d’être très productif. C’est encore plus vrai pour une personne ayant déjà une bonne expérience des clients lourds type Swing.

N’ayant pu creuser SmartGWT, je ne ferais pas de conseils définitifs. Cependant GXT est sûrement le meilleur choix pour des projets étant toujours sur GWT Ext.

Remarques additionnelle :
- SmartGWT est développé par le développeur de feu GWT Ext
- Il existe une autre librairie très intéressante : gwt-mosaic. Elle aussi en full Gwt.
- Il existe aussi la librairie Vaadin, qui prend aussi en charge la partie serveur.

Categories: RIA Tags: ,

Résumé – Conférence sur HTML 5

Mercredi dernier avait lieu à la Cantine Paris, une conférence pour thème « The next open web platform » présenté par Daniel Glazman, Dominique Hazael-Massieux et Philippe le Hégaret.

Après une présentation du W3C, c’est un rapide retour sur les différentes “versions” du web : Web 1.0 avec html, url, http, pas d’opportunité d’interaction réelle avec le document puis Web 2.0 avec javascript, CSS, flash, bureau et mobile et maintenant Web 5.0 qui met en avant les parties données et interactions.

L’idée est d’abord d’améliorer HTML en intégrant pus naturellement les secondes générations de langage web (CSS, SVG, MathML….) mais il y a aussi de nombreux standards et nouveaux outils en préparation (WebSockets, CSS 3, WebGL, ECMAScript 5 …).

Le présentateur revient sur la fin de XHTML 2 et le fait qu’HTML 5 permettra la sérialisation aussi bien en html que xhtml.Il fait une présentation rapide de la très attendu nouvelle balise <video>.

Il présente quelques évolutions liés à CSS comme CSS Media queries qui permet d’adapter et choisir la feuille de style en fonction de la vue coté client (Bureau ou mobile par exemple), CSS Transition qui permet des transitions de style douces ou encore CSS Selector qui permet de sélectionner des éléments HTML directement sans être référencé dans le HTML (très utile pour les tables).
Il y a ensuite un état de SVG qui va enfin être supporté par Microsoft. Son intégration plus poussée permet par exemple avec l’utilisation d’HTML 5 d’intéragir avec une video (sous titre!).

La technique Gaussian blur permet l’affichage des formules mathématiques ou mettre des effets sur une image déjà présente.
Un nouveau présentateur décrit les futurs APIs permettant d’accéder au matériel (géolocalisation, caméra, calendrier, carnet d’adresses..). L’idée est vraiment d’améliorer l’expérience web et d’intégrer la réalité augmentée.

Un des projets est aussi de rendre les applications Web téléchargeables, signables, sellables, avec une interface utilisateur dédiée type widgets.

En conclusion, cette conférence présentée par des membres du W3C permet de se rendre compte de l’étendu des objectifs autour d’HTML 5 et de l’ampleur de la tache qui reste à effectuer. Il va falloir attendre la finalisation des APIs et leur implémentation dans les navigateurs. L’ensemble est à surveiller de près vu les possibilités et les simplifications que ces APIs apportent.
La présentation est disponible ici : www.w3.org/2010/Talks/0407-next-web-cantine

Categories: Divers, RIA Tags:

Statistiques RIA

Le site RIAstats fournit des statistiques « temps réel » sur le déploiement des plugs-ins RIA (Rich Internet Application): Adobe Flash/Flex Player, Microsoft Silverlight Player et Sun Java.

Les filtres possibles par OS, browser et pays, en font un outil utile à consulter de temps en temps pour se rendre de compte des évolutions de part de marché.

Categories: RIA 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: , , ,

Charger une association dans WCF RIA Services

Je l’avais annoncé ici : .NET RIA services est devenu WCF RIA Services.

Rappels

L’objectif de ce projet est de simplifier le développement d’applications RIA.

Le principe général est assez simple :
Je développe des services de domaine (CRUD + Queries) en utilisant des conventions de nommage côté serveur.

Par exemple, la méthode Sprint LoadSprint(int sprintId) renvoie un sprint d’une application Scrum à partir de son identifiant.

WCF RIA Services projette ce code côté client dans des classes de type DomainContext.

Dans notre exemple, j’obtiens une classe ScrumDomainContext avec une méthode EntityQuery<Sprint> LoadSprintQuery(int sprintId)

Projection de code

Projection de code

Les associations

La version beta est disponible depuis le mois de Novembre. On trouve sur le Web quelques introductions, notamment celles de Brad Abrams. En revanche, on trouve très peu de choses sur comment charger une association dans notre application cliente Silverlight.

Dans mon exemple, je veux afficher une vue Master/Details qui présente un sprint et la liste de ses tâches.

Le modèle

Sprint association

Sprint association

La déclaration de l’association

Je dois ensuite décrire à WCF Ria services les associations entre mes entités. Pour cela, je décore les propriétés Tasks de la classe Sprint, et Sprint de la classe Task avec l’annotation AssociationAttribute. Il faut indiquer un nom pour cette association, par exemple Sprint_Tasks et préciser les clés étrangères de chacune de ses relations. Dans le sens Sprint -> Task, la clé c’est le champ Id de la classe Sprint et la clé étrangère c’est le champ SprintId de la classe Task.


public class Sprint{
[Key]
public virtual int Id { get; set; }

[Association("Sprint_Task", "Id", "SprintId")]
public virtual ICollection Tasks { get; set; }
}

Quelques remarques :

  1. Les habitués de NHibernate vont déplorer le fait d’avoir à décrire l’association à l’aide des clés étrangères. Cela nécessite par ailleurs d’avoir une propriété SprintId dans la classe Task en plus de la propriété Sprint :(
  2. La décoration est automatique avec l’utilisation de LinqToSql ou d’Entities Framework

Le chargement explicite

Il reste enfin à indiquer explicitement que l’on souhaite sérialiser les tâches avec le sprint. Pour cela, nous devons définir une classe de méta données relative à la classe métier. Dans notre exemple, ce sera une classe SprintMetaData définissant un champ Tasks que l’on décore avec l’annotation IncludeAttribute.


public class SprintMetaData {
[Include]
public EntitySet Tasks;
}

Je vous laisse regarder le blog de Brad Adams ou un ancien billet pour les détails de la classe de méta données.

Personnellement je trouve dommage d’avoir à définir une stratégie de chargement dans un fichier de méta données. L’idée générale n’est pas mauvaise, mais présente un inconvénient majeur : la stratégie est valable pour tous les cas d’utilisation. Or il est probable que l’application ne nécessite à la fois le sprint et ses tâches que dans certains écrans …

Outils de mapping objet/relationnel

Si vous utilisez un ORM, n’oubliez pas de récupérer la collection de tâches dans votre requête.

Avec LinqToEntities, ça donne :


public Sprint LoadSprint(int sprintId){
return this.Context.Sprints
.Include("Tasks")
.Where(sprint=>sprint.Id == sprintId);
}

Avec LinqToNhibernate, ça donne:


public Sprint LoadSprint(int sprintId)
{
var result = this.Session.Linq().Expand("Tasks")
.Where(x => x.Id == sprintId)
.ToList().First();
return result;
}

Conclusion

Nous avons vu en détail comment charger une association entre deux entités dans une application WCF Ria Services. Une partie de ces détails est masquée par l’outillage fourni par Microsoft et nous ferait presque oublier la complexité qui ne manquera pas de ressortir si vous souhaitez utiliser cette pile en association avec des outils tel que NHibernate

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: , , , ,

Quelques nouveautés Adobe

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

Objet Direct au séminaire jWeekend

jweekendjWeekend (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.

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

Site .NET RIA Services

Microsoft vient publier un nouveau site communautaire dédié à la technologie .NET RIA Services. Ce site regroupe les ressources, discussions et informations indispensables pour bien utiliser ce framework.

http://silverlight.net/riaservices/

RIA Services : The Official Microsoft Silverlight Site

RIA Services : The Official Microsoft Silverlight Site

Categories: .NET, RIA Tags: ,