jy[B]log

Après les améliorations qui viennent d'être apportées sur le moteur Javascript qui fait repasser Gecko 1.9.1 devant Webkit au niveau des performances de l'execution des scripts JS, voici que Neil Deakin (développeur Mozilla de son état), vient de terminer l'implémentation de l'API drag and drop de HTML5.

On peut donc apporter des fonctions de drag'n'drop dans une page web, tout aussi facilement que ce que l'on peut faire avec des bibliothèques comme jQuery. Sauf qu'il n'y a plus besoin de charger des kilos de scripts JS :-)

Ça y est, mon patch est dans le trunk de Mozilla. On pourra donc faire dans Firefox 3 des templates XUL avec des données issues d'une base sqlite.

Bon, l'intégration du patch ne s'est pas super bien passé. Voici ce qui peut arriver quand on oublie de tester une compilation en mode optimisé, et donc avec un include manquant :

Oui,c'est moi qui ai mis le feu aux tinderboxs^[1] :-) Et là on ne voit que celles pour firefox, il y a aussi celles pour xulrunner, sunbird, seamonkey...

M'enfin, ça a été vite corrigé, tout est bien qui fini bien.

PS: les possibilités apportées par mon patch ne sont pas présentes dans Firefox 3.0 beta 1, mais le seront dans les versions suivantes.

Après presque un mois d'attente, j'ai pu enfin avoir une superreview sur mon patch. Hélas, il n'est pas passé :-) En effet, il est possible de modifier la requête en y injectant des valeurs non vérifiée, ce qui peut entrainer des problèmes de sécurité. Il m'a donc été demandé d'améliorer ça, en permettant de pouvoir déclarer des requêtes paramétrées. Cela n'empêche pas le développeur de trafiquer la requête à la main, mais au moins il a un moyen pour faire des modifications de façon simple et sûre, évitant les problèmes d'injection SQL.

J'ai fait la modif, et voici donc maintenant ce qu'on peut faire :

   <grid>
       <columns>  <column flex="1"/> <column flex="3"/>  <column flex="2"/> <column flex="1"/>  </columns>
       <rows datasources="tests.sqlite" querytype="storage" id="rows" ref="?">
       <template>
           <query>
               select product_id, label, price, cat_id from products where price > :price
               <param id="price-param" name=":price" type="int32"/>
           </query>
           <action>
               <row uri="?">  <label value="?product_id"/>  <label value="?label"/>  <label value="?price"/>   <label value="?cat_id"/>   </row>
           </action>
       </template>
       </rows>
   </grid>

La nouveauté c'est la balise param, dont le contenu doit être la valeur du paramêtre. Ici il s'agit d'un paramètre nommé, c'est pourquoi il a un attribut name. On peut indiquer le type de la donnée avec l'attribut type. Et bien sûr, on peut avoir autant de paramètres que l'on veut.

Et ensuite, avec un petit bout de script, on indique la valeur du paramètre et on régénère le contenu du template :

   document.getElementById("price-param").textContent = "270";
   document.getElementById("rows").builder.rebuild();

Il s'affichera tous les produits dont le prix est supérieur à 270. Si on ne veut pas que le contenu du template s'affiche dès le départ, il suffit de ne pas mettre l'attribut ref tout de suite, mais seulement après que l'on ait fini de mettre les valeurs dans les paramètres.

Je n'ai pas encore mis à jour le patch sur le bug, j'ai encore 2-3 choses à vérifier, mais ça se fera au plus tard demain. En espérant que la superreview soit enfin positive :-)

J'ai pu avancer sur l'implémentation de l'usage de SQLite dans les templates XUL (pour rappel, il s'agit du bug 321172). Après quelques reviews qui m'ont permis de corriger et d'améliorer certaines choses, je viens de demander une "superreview", ultime étape avant que le patch soit inclus dans le trunk de Mozilla.

Bien que l'ajout de fonctionnalité/nouveauté dans Gecko soit gelée en ce moment, pour cause de sortie "imminente" (dans quelques mois) de Firefox 3, on m'a tout de même expliqué qu'il y avait des chances que le patch soit intégré, vu qu'il ne modifiait pas le comportement de Gecko, et qu'il pourrait être utile pour des interfaces de Firefox 3 (vu que SQLite/MozStorage est de plus en plus utilisé dans le navigateur). Si toutefois par malchance il n'était pas intégré, je pense que je livrerais une extension provisoirement. Cela ne devrait pas me faire beaucoup de travail grâce au niveau système de template qui est "évolutif" : il suffirait d'en faire un composant XPCOM.

Après avoir travaillé sur le bug 321170, j'ai pu avancé sur le bug 321172 (voir les explications sur un vieux billet). Je viens donc de finir un premier patch qui fonctionne (adapté d'un précédent travail de Neil Deakin), permettant d'ajouter la prise en charge d'un nouveau type de source de données pour les templates XUL : SQLite. Avec ce patch, on peut donc maintenant faire ça en XUL :

 <vbox   datasources="file:///home/laurent/mabase.sqlite"  ref="?" querytype="storage">
   <template>
       <query>select name, firstname from users</query>
       <action>
           <hbox uri="?">
               <label value="?name"/>
               <label value="?firstname"/>
           </hbox>
       </action>
   </template>
 </vbox>

J'ai aussi ajouté la prise en charge d'un type d'url spécial, qui permet d'indiquer facilement une base sqlite qui est dans le profile de l'utilisateur :

  datasources="profile:places.sqlite"

Ici on utilise la base du nouveau système de bookmarks de Firefox 3 ;-) Je ne sais pas encore si ce type d'url sera accepté, on verra.

En attendant, faut que je fasse une petite série de tests unitaires pour en vérifier tout le bon fonctionnement.

Neil Deakin avait amélioré il y a plusieurs mois déjà le moteur de template XUL : il permet ainsi de pouvoir utiliser des sources de données autre que RDF. Il suffit de réaliser un composant qui sert de "plugin", respectant une interface précise, pour pouvoir fournir au template des données en provenance d'une base de donnée, d'un fichier xml etc..

Le seul souci, c'est que ce n'est pas encore très opérationnel, à cause du bug 321170 : le comportement de l'attribut datasources, qui permettait d'indiquer l'url du fichier RDF, n'a pas été modifié et de ce fait, on ne peut pas y indiquer l'url d'un autre type de source de donnée. Et comme c'est lors de l'analyse de cet attribut que le moteur de template déclenche la génération du contenu, et donc appel les composants "plugins", le nouveau système est en fait inutilisable en dehors de RDF.

Je m'en suis rendu compte quand j'ai voulu m'occuper du plugin pour Storage/Sqlite (bug 321172). Donc en plus de ce bug 321172, je me suis attelé au bug 321170. J'espère résoudre ces bug assez rapidement. Ce serait dommage qu'on n'ait pas tout ça dans Gecko 1.9/Firefox 3.0. Sachant que j'ai aussi sur le feu, entre autres choses, la gestion des formulaires dans Jelix, le nouveau validateur dans Etna... ;-)

Suite à des commentaires sur mon dernier coup de gueule, et à divers lectures sur d'autres sites web, j'ai remarqué qu'il y avait une confusion entre XulRunner et XUL. Je tiens donc à préciser :

XUL n'est pas XulRunner

et

XulRunner n'est pas XUL

XUL est un langage. XulRunner est un lanceur d'application (ces applications devant être faites avec les technos mozilla, en particulier en XUL).

Autrement dit, l'avenir de XUL n'est pas lié à XulRunner. Aussi, quoiqu'il advienne au projet XulRunner, XUL et toutes les autres technologies inclusent dans Gecko continueront d'évoluer, à s'améliorer, à devenir toujours plus innovantes. Une simple raison : elles sont utilisées par les deux projets phares de Mozilla, Firefox et Thunderbird, et elles sont utilisées par les centaines d'extensions disponibles pour ces deux produits ;-)

Donc pas d'inquiétude à avoir pour la langage XUL, pour le langage XBL^[1] et tout autre technologie de Mozilla (SVG, Javascript2, XPCom...).

Pour ce qui est de l'avenir de XulRunner, il n'est pas aussi sombre que mon précédent billet pourrait laisser croire, même pas du tout. Je vous en parlerai dans un prochain billet ;-) .

Apparement, notre première xulfr party samedi dernier, a plu. Mandriva nous avait laissé une grande salle à notre disposition. Il y a eu presque une vingtaine de personnes qui sont venues, du développeur freelance à des développeurs de grosses boîtes comme Renault F1 ou tf1.

Chacun a pu discuté, découvrir des applis XUL, découvrir XUL, poser des questions, partager son expérience.

Cela s'est bien passé et donc on recommencera :-)

Dans le cadre d'un dossier sur le client riche qui vient de sortir sur le journal du net, j'ai été interviewé sur XUL :-)

• Quelques balises XUL pour l'interface, histoire d'éviter de se trainer des tonnes de scripts JS pour faire des widgets et éviter donc d'avoir des widgets, pauvrement accessible, qui ressemblent de loin par temps de brouillard à ce que l'utilisateur à l'habitude d'utiliser dans des applications "normales".
• un peu de xmlhttprequest pour envoyer ou reçevoir le document édité à partir du serveur
• quelques scripts coté serveur pour réaliser la convertion du document que vous voulez éditer vers HTML (ou à partir de HTML pour la sauvegarde)
• un peu de javascript pour programmer les quelques traitements sur les actions de l'utilisateur

Et vous obtenez un traitement de texte en ligne : AjaxWrite.

Certains y verront un éditeur simpliste mais ce n'est qu'un début.

Et n'en doutez pas, on va voir débarquer de plus en plus d'applications online en XUL. Pour les développeurs, XUL facilite beaucoup les choses pour la réalisation d'interface utilisateur.

Et cela apporte aussi énormément de souplesse !

Un exemple : imaginez que dans AjaxWrite, on puisse indiquer l'url d'un overlay XUL (url qui serait stockée dans un cookie). (Pour rappel, un overlay est un fichier XUL qui indique des éléments XUL à ajouter à une interface déjà définie. C'est le coeur même du système d'extension de Firefox.)

Bref, on indiquerait cet overlay, et hop : vous rajoutez ainsi vos propres fonctionnalités à une application distante, sans avoir à modifier les sources sur le serveur ! (et sans rien à installer en local). Si c'est pas du "Web 2.0" ça ...

Bref, XUL, c'est TOTALEMENT DEMONIAQUE !!

Les applis en HTML, ce n'est pas l'avenir. Moi j'vous l'dit ! (Surtout quand XUL sera normalisé par le W3C).

PS: ah ! On me souffle dans mon oreillette que l'auteur de AjaxWrite trouve trés bonne mon idée de pouvoir indiquer ses overlays dans l'application...

PS2: Tiens, et pourquoi pas réaliser une extension pour Firefox, qui permettrait d'indiquer les overlays à ajouter à telle ou telle application web quand on les utilise, même quand cette fonctionnalité n'est pas explicitement prévue par leurs auteurs ? À étudier...