Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - template

Fil des billets - Fil des commentaires

dimanche, avril 1 2012

jsDatasource, a component for XUL templates

I just released publicly a new version of a component : jsDatasource.

This component allows to use javascript objects as datasource for XUL templates. You can use it in your own extension or XUL applications. It becomes easy to use XUL templates with js datasources!

I started this component in 2009, for a software, ZoomCreator, when I worked for Zoomorama. Even if it was written under a free licence, I didn't release it at this time (well, I had so much work..). And for a recent customer project, I need it with some improvements, like the support of recursion or the support of sorting. So I improved it, and I just open a public repository :-)

I hope it will help some XUL developers :-)

mercredi, décembre 10 2008

Regression sur les templates sqlite, et l'importance des tests unitaires

En voulant utiliser les templates XUL avec sqlite dans BlueGriffon, Daniel a découvert un bug il y a quelques jours. Un méchant bug d'ailleurs, puisque les templates avec sqlite ne fonctionnaient quasiment plus ( je n'ai pas vérifié si ça l'est dans la dernière beta de Firefox ou si c'est juste dans le trunk).

C'est une régression qui est survenue suite à une "amélioration" dans le moteur principal de template, il y a... presque 2 mois !

Deux mois pendant lesquels les templates avec sqlite ne fonctionnaient plus. Et savez-vous pourquoi tant de temps ? Parce qu'il n'y avait pas de tests unitaires ! Donc aucun moyen de détecter automatiquement la régression.

Et à qui la faute ? En grande partie à moi : je n'avais pas développé de vrai tests unitaires lorsque j'avais implémenté le support de sqlite dans les templates XUL. Deux petites excuses tout de même :

  1. À l'époque, le framework de tests unitaires ne permettait pas de faire des tests dans le context chrome
  2. j'attendais en fait que Neil Deakin finisse son mini framework de tests sur les templates, pour y ajouter mes tests.

Mais bon, quand il eut terminé, ma tâche fut tombée dans l'oubli, noyé que je suis dans ma todo list.

Cependant, Neil m'a dévancé pour corriger le bug. Moi j'ai ajouté mes tests. Tout devrait être intégré dans le trunk dans les jours qui viennent, le temps que les reviews se fassent. Ouf.

dimanche, novembre 6 2005

Faire de l'Ajax sans le savoir

Dans un billet précédent, "Ajax est obsolète", j'expliquais que pour moi, Ajax n'est pas une solution d'avenir car trop complexe et trop bas niveau (le fameux xmlhttprequest).

J'avais alors émis l'idée d'avoir plutôt des balises spécialisées, interpretées directement par le navigateur, qui se chargeraient des opérations bas niveau et avec lesquelles on aurait juste à indiquer des informations minimales dans des attributs comme l'URL du service web à invoquer. Elles permettraient donc de faire de l'Ajax sans le savoir, sans avoir à taper des lignes de codes javascript complexes. Exactement en fait comme la balise HTML <a> ou <form>, qui utilisent finalement une forme d'Ajax sans que vous le sachiez : elles ont une url dans un attribut, elles envoient des données via xmlhttprequest à cette url, et elles modifient (ou plutôt remplacent) la page courante à partir du contenu de la réponse reçue.

J'avais donné alors l'exemple de la balise template en XUL qui est parfaitement dans cet esprit : on cache ce qui est bas niveau (xmlhttprequest), on permet d'éviter l'usage du javascript. Le résultat est alors une techno simple à utiliser pour développer, économe en temps de dev, de débuggage, et économe en bande passante ou en ressource système (il n'y a pas 50ko de scripts à executer puisque les balises sont directement interpretées par le navigateur).

Je voulais commencer à faire une bibliothèque JS qui permettrait de vous montrer concrétement mon idée. Mais en fait d'autres l'ont fait avant moi. Je suis en effet tombé, au hasard du surf, sur l'offre de backbase. Ce qui est intérressant sur ce site, c'est le code source de leur page. Que voit-on ? Des balises <include>, <event>, <buffer>, des attributs behavior, followstate etc.

On devine alors aisément à quoi elles servent : inclure des morceaux de pages à des endroits précis, qui sont éventuellement rechargés à l'apparition d'évènements particuliers, déclenchés par des actions spécifiques de l'utilisateur. En clair : vous avez le même résultat que ce que l'on fait en Ajax, mais sans avoir à écrire une seule ligne de code javascript. Quelques balises et quelques attributs bien placés, et vous voilà avec une interface utilisateur dynamique.

Exactement donc dans le même esprit que la balise html <a>, <form>, ou la balise XUL <template> : simplicité, efficacité. Bref, une techno accessible à tout développeur web, et pas seulement aux geeks.

Ce qu'a fait Backbase a toutefois un inconvénient : avoir une page utilisant leurs balises nécessite d'inclure leurs fichiers JS qui sont volumineux. Ce javascript sert à parser la page, et à interpreter les balises et attributs. On a donc une page lourde et longue à charger mais aussi longue à s'éxecuter.

Cependant, imaginez que le navigateur puisse interpreter nativement des balises du même style que celles de Backbase. Là je pense qu'on pourra vraiment parler de web 2.0 (ou 3.0 ?) ;-) (tout en résolvant une partie des problèmes d'accessibilité posés par Ajax).

jeudi, septembre 29 2005

Ajax est déjà obsolète

À coté du buzz web 2.0 qui ne veut rien dire et ne sert à rien sinon à vendre du vent, il y a le buzz Ajax qui lui est un peu plus concret. Il fait fureur en ce moment, tout le monde veut faire de l'Ajax, et tout le monde trouve cette technologie révolutionnaire, malgré qu'elle soit vieille de plusieurs années. Mais personnellement, je trouve que cela ne va pas vraiment dans le bon sens, et qu'il serait préférable de s'orienter vers d'autres techniques plus efficace et simple pour avoir du contenu dynamique.

Lire la suite...

mercredi, août 18 2004

jsTemplateBuilder

Imagine you have some javascript data. And imagine you need to generate some xul tags from this data. The traditionnal way is to use DOM objects, with document.createElement, and setAttribute, appendChild method etc... If you have many data, the amount of code to write could be high. Very high. And it becomes difficult to debug it, to have a general view of your xml tree that you generate etc.

Another way is to use the jsTemplateBuilder object.

Lire la suite...