Catégories: Langages, C++, CSS, Java, Javascript

C'est la première fois que j'assiste à une conférence Java sur 3 jours et même si je n'ai pas de critères de comparaison, j'ai trouvé cette expérience plutôt instructive et sympathique. En revanche, c'était plus fatiguant que je ne le pensai, ceci explique pourquoi je ne vous fait un retour que maintenant...

» Lire la suite!

Une discussion intéressante sur GWT à travers plusieurs blogs francophones :

1) Florent Garin : GWT est-il toujours pertinent ?
2) Sami Jaber : Oui, GWT est plus que jamais pertinent
3) Ludovic Borie : De la pertinence de GWT
4) Thomas Broyer : De la place de GWT

Vous connaissez surement le champ d'upload de fichier des navigateurs web.
Certains mettent le nom complet du fichier (avec son chemin),
d'autre le nom court du fichier pour des raisons de sécurité (Le serveur n'a pas besoin de savoir où se trouve le fichier sur le client).

Jusque là, tout va bien.

Mais il se trouve que des **** du W3C ont décidé dans la spécification HTML5 de préfixer le nom de fichier par "C:\fakepath\" !

Pourquoi cette résolution est mauvaise ? Comment la contourner ?

» Lire la suite!

Sur gwt-gae-book, le développeur Marius Andreiana a écrit une documentation illustrant le développement professionnel d'applications utilisant Google Web Toolkit et Google App Engine.

Le genre de ressource assez rare pour être signaler ...

Un GUI Builder ?

Pour ceux qui l'ignorent, je rappelle qu'un GUI Builder est un outil qui permet de construire une IHM par drag & drop de Widgets. Il est une belle illustration du pattern MVC, un modèle qui représente votre code et deux vues : la vue "code" et la vue "graphique".
Vous avez une zone d'édition, une table des propriétés et des palettes de composants pour construire vos vues.

Les GUI Builder existent depuis bien longtemps :

• pour la génération des "écrans" des applications desktop.
  On en trouve avec tous les langages classiques (Delphi, Visual C++, Java Swing, ...).
  Du code était généré et il fallait mieux ne pas trop y toucher.
• pour la génération de documents html des sites web statiques
  Pensez aux classiques Dreamweaver, Frontpage, ...
• pour la génération des "vues" des sites web dynamiques avec les technologies d'Adobe, de Microsoft, ...

Et GWT Designer, ça vous dit quelque chose ?

C'est un GUI Builder pour construire des IHM GWT, un produit commercial de la société Instantiations.
GWT Designer, c'est donc d'abord un GUI Builder qui opère sur du code Java (Le code Java GWT qui sera compilé en Javascript).
Et générer du code source Java, c'est à mon sens un peu moins facile que générer du code XML puisque les langages à balises se prétent mieux à la représentation de documents. C'est sans doute pour cela qu'Adobe avec Flex ou Microsoft avec WPF utilisent des langages XML pour représenter les vues des applications Web développées avec leurs technologies RIA respectives.
Faire un GUIBuilder qui génère du code objet, c'est peut être un poil plus compliqué (et moins manipulable après) mais ce n'est pas impossible comme le prouvent les GUI Builder Visaul C++ et cie ...
Forte de son expérience dans le développement de GUI Builder (SwingBuilder, SWTBuilder, ...), il n'est donc pas étonnant que la société Instantiations ait donnée naissance à GWTDesigner.

Evolution de GWT Designer avec GWT 2.0

GWT 2.0 a introduit avec UIBinder la possibilité de créer des IHM de manière déclarative (en XML) au lieu de le faire de manière procédurale. GWTDesigner pouvait donc tirer pleinement profit de cette nouvelle approche.
Dans les forums GWT, je lisais récemment un message d'un développeur d'Instanciation demandant à l'équipe de GWT d'ajouter du code pour mieux pouvoir intégrer leur outil.

Aujourd'hui, j'apprend sur leur site que la société Instantiations, éditrice de GWTDesigner, fait partie désormais de Google !
http://www.instantiations.com/

Si je ne suis pas très adepte de la construction de vues par cette méthode, je ne nie pas qu'elle présente des avantages certains.
Il faudra également que UIBinder gagne en maturité mais il ne fait aucun doute que ces nouveaux Googlers vont tout faire pour.

Bref, une bonne nouvelle pour GWT.
Et vous qu'en pensez vous ? Venez en discuter sur le forum.

Une petite présentation bien sympathique sur les servlets 3.0

http://beta.parleys.com/#sl=16&id=1011&st=5

Une présentation en français avec slides expliquant les motivations des nouveautés.

Suite à son dernier article, je suis tombé sur le blog de julien et en remontant le temps, j'ai eu envie de réagir à son premier billet.

Comme mes commentaires commençaient à s'allonger, j'ai préféré rédigé ce petit billet.

• Quand je faisais du Swing et du JDBC, j'aimai bien à partir de mes ResultSet remplir un objet métier qui implémentait une interface modèle de la vue (GridModel, ListLodel, ...) qui pouvait être présenté différemment par un Renderer. Cela évitait ainsi des recopies inutiles.

• En GXT, j'ai essayé de faire la même chose en remplissant avec Ibatis des Maps qui implémentent ModelData (l'interface des modèles de données dans GXT).

Dans les deux cas, il y a une "adhérence" aux interfaces "Model" d'une couche graphique (Swing, GXT).
Et si cela me dérangeait moins en Swing à l'époque, avec le web, ça me plaît pas trop.

Du coup, je me demande si deux objets ne sont pas nécessaires puisqu'ils ont deux responsabilités différentes :

• Un type d'objet MA qui sert de conteneur de données (POJO du modèle de l'application)

• Un type d'objet MV qui sert d'objet de rendu (Modèle de donnée d'un composant de la vue de l'application) qui représente directement des MA ou une vue consolidée de MA)

Et donc une recopie partielle des données d'un MA dans un MV ?

Ce qui illustre de plus en plus ce sentiment que j'ai que le MVC s'applique à plusieurs niveaux :

• Un MVC global au niveau de l'application métier : Des vues (Vue) qui permettent via des actions (Contrôleur) de traiter des données (Modèle)

• Un MVC local au niveau d'objets techniques : les composants graphiques d'une couche de présentation, ceux qui servent à construire les vues de l'application métier.

Et vous, qu'en pensez vous ?

Comme je vous l'annonçais ici, GWT 2.0 est sorti en RC1.

Cette version n'est pas encore la version finale mais son utilisation est facilitée dans la mesure où elle est accompagnée d'une mise à jour du plugin Eclipse.

Voici donc un petit retour de mes premiers essais avec cette nouvelle version.
Au menu :

1. Installation de GWT 2.0 RC1
2. Execution d'une application GWT 2.0 RC1
3. Installation des plugins GWT dans les navigateurs
   • Quand GWT 2.0 est incompatible avec Chrome 3.0 !
   • Et un nouveau plugin Firefox 3.6, un !
   • Uhmmm, le bon activeX pour IE !
4. Utilisation du mode de développement

» Lire la suite!

GWT 2.0 M1 est disponible ici !

Il n'y a désormais plus qu'une seule version indépendante de la plateforme (Windows/Linux/Mac).
Ceci est rendu possible par la nouvelle approche utilisée : Le nouveau mode de développement utilise des plugins par navigateurs qui sont téléchargés à la première exécution.

» Lire la suite!

Avec un titre pareil, toi, esprit perspicace, tu auras compris de qui je veux parler, n'est-ce pas ?

Et puisque que je ne t'apprendrai rien sur lui, je vais plutôt te parler de notre histoire à tous les deux, de notre rencontre, du temps qu'on a pensé ensemble, des infidélités, de notre séparation, de nos retrouvailles, etc...

» Lire la suite!

Dans un précédent billet, je faisais état des données membres que l'on veut exposer et je rappelai les avantages du principe d'encapsulation.

Bien entendu, de même qu'il n'est pas question de mettre tous les attributs en visibilité publique, il n'est pas question pour autant de créer des getters/setters pour tous les attributs. (J'aurai même tendance à penser qu'il ne faut les créer que si une classe cliente en a vraiment besoin.)

En poussant un peu plus loin la réflexion, je pense qu'on ne devrait même pas se poser les questions

• getter or not getter ?
• setter or not setter ?

» Lire la suite!

Chez les développeurs débutants, on peut observer deux attitudes opposées :

• Soit ils utilisent beaucoup trop de variables publiques
• Soit ils suivent aveuglément les conseils et utilisent des getters partout, même dans la classe d'origine.

Selon moi, ces deux cas extrêmes illustrent qu'ils n'ont pas compris l'intérêt du principe d'encapsulation des données.

Je me propose d'en faire le sujet de ce billet qui je l'espère sera propice à quelques réflexions.

» Lire la suite!