continuations on the web : managing back and next in Struts

Hier, j’ai lu avec beaucoup d’intérêt l’article de DeveloperWorks Use continuations to develop complex Web applications.

J’ai été illuminé par le concept des continuations et son utilisation pour stocker l’état d’une application web. Cependant, ces continuations soulèvent des questions importantes pour moi comme : comment pourrais-je implémenter facilement une application basée sur les continuations s’intégrant bien dans, par exemple, Struts.

Je réalise maintenant que toute mon illumination pour résoudre le problème « complexe » du précédent/suivant n’est qu’un jeu de l’esprit. En fait, la solution est triviale, quand on (en l’occurence moi), se souvient qu’une application web n’est jamais MVC, mais conversationnelle. Mais, pour m’en souvenir, la solution est simplement, pour un formulaire, de mettre dans la session de l’utilisateur, dans une clé nommée d’après le formulaire une valeur, qui sera détruite lors du traitement de ce formulaire. Si la clé n’est pas présente, aucun traitement de formulaire ne sera fait. Le principal avantage est que ce traitement peut être fait dans une paire d’actions abstraites, permettant un traitement facilité des formulaires, avec par exemple une AbsstractFormDisplayAction, et une AbstractFormReceiveAction. Le truc est de rendre ces classes non visibles, ou non impactantes, sur les sous-classes. Pour ça, la AbsstractFormDisplayAction doit passer la clé utilisée à la JSP, qui pourra la placer dans un champ bien connu du formulaire. Cela permettra à la AbstractFormReceiveAction de lire cette valeur du formulaire, et ainsi de vérifier si la clé existe dans la session. Cependant, quand plusieurs fenêtres du navigateur partagent la même session, les choses deviennent encore un peu plus complexes (pensez aux deadlocks). Heureusement sur le web les choses sont simples : la AbsstractFormDisplayAction va associer à la clé, si ça n’est pas encore fait, une List, et créer dans cette liste un ID. Cet ID sera également passé à la JSP, et inséré dans le formulaire avec un bon nom. Ainsi, la AbstractFormReceiveAction pourra vérifier dans la liste si cet ID est présent, et sinon …. Quoi ? Afin de rendre cette implémentation efficace, les actions de formulaires devraient avoir toutes un forward, par exemple « formNotSubmitted », que la AbstractFormReceiveAction pourrait utiliser.

Devrais-je désinstaller mes outils de documentation ?

Sur le Software documentation weblog,on peut lire

If you are a software developer and if you are writing documentation: read Bob McWhirter’s Developers Don’t Write Documentation and stop writing documentation.

Je trouve ça dur à avaler. En effet, le logiciel, du point de vue documentaire, se divise en deux groupes :

  1. Il y a un documentaliste dans l’équipe de développement, qui fournit une grosse valeur ajoutée en écrivant une documentation accessible et lisible.
  2. La documentation ne peut être écrite que par les développeurs ou les utilisateurs.

Le premier groupe peut être considéré comme chanceux. Mais, dans le second, pouvez-vous, en tant que « père » du logiciel, accepter que les utilisateurs décrivent son fonctionnement ? Personnellement, je n’y arrive pas. Donc j’ai toujours décidé qu’il vallait mieux leur fournir un brouillon. Si il y a un documentaliste souhaitant la corriger ou l’améliorer, tant mieux. Autrement, il y a au moins une documentation. Mais aucun développeur ne devrait pouvoir esquiver l’importante tâche qu’est l’écriture d’une documentation. Cette tâche a en fait plus d’un but. Bien sûr elle fournit à l’utilisateur des moyens de comprendre des logiciels parfois complexes, mais elle pousse aussi les développeurs à avoir de leur création une vue d’ensemble, afin de permettre aux débutants de mieux le comprendre. Et pour ça, cette étape est importante (même si elle ne vaut pas un essai du logiciel par un utilisateur de test).

Quand la chine s’est éveillée

Jean-Michel Billaut nous explique qu’il est temps de passer au chinois :

Un conseil, faites apprendre à vos enfants le chinois… En ce qui me concerne je vais peut-être m’y mettre… (je sais déjà dire merci… mais je ne sais pas encore l’écrire)…

Clairement, on est à deux pas d’une mutation fondamentale : le passage d’une domination américaine à une domination chinoise. Déja, tous nos objets physiques sont chinois. Notre distributeur de parfum aussi. Bientôt, grâce aux devises accumulées, le mode de pensée chinois va pouvoir avoir plus d’impact médiatique. Et, dans moins cinquante ans, à l’image des Etats-Unis isolationnistes d’avant la seconde guerre mondiale, le monde se réveillera, surpris, en constatant la dominationb chinoise. Heureusement, du fait d’une politique démographique plutôt spéciale, la Chine risque de s’effondrer sur elle-même, comme la France va le faire dans cinq ou dix ans.

sauvergarder del.icio.us

Comme beaucoup de monde, j’utilise {del.icio.us}. Et, comme beaucoup de monde, je me demande ce qui arrivera le jour où {del.icio.us} s’arrêtera Grâce à ce site, je peux au moins limiter les pertes en faisant des sauvegardes régulièes de cette manière. A part ça, blogger depuis un portable (PC, pas un gadget téléphonique), c’est vraiment tranquille. Je me vois bien gérer {BloNomic} comme ça.

Pour trouver de nouvelles musiques

Ou plus exactement, pour explorer des groupes « proches » de ceux que vous appréciez, vous pouvez demander à musicplasma. Si il a très bien marché pour mes groupes de hard-rock préférés (Manowar, Iron Maiden, Nightwish), un artiste complètement inclassable comme Ben Harper le met aux fraises. Mais c’est assez normal, de la part d’un héritier spirituel de Bob Marley, Jimi Hendrix et Marvin Gaye (oui, on peut hériter de ces trois-là sans s’emmêler les pinceaux).

Le javascrip

On dit souvent que le Javascript est un langage très limité, comme ici :

In general, pushing the UI to Javascript makes it hard to develop and debug. There are limited tools, the language is too lenient (no objects, weak typing), and testing involves cycling through webpages over and over again.

Ca m’énerve vraiment. Le Javascript a des objets (en guise de preuve, que faites vous avec votre document.write, node.childNodes, etc, …), et le typage faible n’a jamais été un manque (les langages interprétés modernes comme le Perl, le Python ou Groovy l’ont assez montré). A mon avis, javascript est vraiment mal compris. C’est un langage incroyablement puissant et rapide. Oui, rapide. Ce qui est lent en Javascript n’est pas le calcul, mais l’intégration au navigateur. Ce qui peut être facile à comprendre : imaginez que vous deviez redessiner une page entière quand vous insérez un simple DIV. Ca doit bien être lent. En guise de pense-bête, voici quelques spécificités du Javascript :

  • Les Closures comme dans ce puissant exemple, qui génère à la volée un tri sur une colonne d’une table :

https://gist.github.com/265975

C’est en javascript une manière facile de générer un tri multi critères.

Et, quand on essaye de banir le Javascript, il ne faut pas oublier que des sociétés comme Google l’utilisent intensivement (par exemple, GMail).