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

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

Commentaires

1. Le vendredi, avril 20 2012, 12:36 par dev

j'ai vu que t'as désactivé les commentaires sur l'article non in_array n'est pas lent.
Je trouve cet article très pédant et je vais te dire pourquoi :
j'ai dix ans d'xp en développement C++, et java. j'utilise sporadiquement php, un langage que je ne trouve pas professionnel pour divers raisons, je ne m'étallerais pas sur la question.

Quand je vois la fonction in_array, je suppose qu'elle est optimisé. Mais comme j'ai l'habitude de l'amateurisme en php... je vais vérifier l'implémentation, et là je vois qu'un array est une hash table et que in_array se contente de parcourir le hash.

Alors comme tu le dis c'est à la portée de tous de connaitre la complexité. Mais tu vois ici : http://php.net/manual/fr/function.i... on ne spécifie pas la complexité, ni l'implémentation comme c'est le cas dans toutes les docs dignes de ce nom. Donc quand je dois coder deux lignes de php dans ce langage pourris, même avec toute l'expérience et ma connaissance des algos, je ne peux pas deviner l'implémentation interne de cette fonction pourrie, ni même immédiatement trouver la méthode la plus rapide.

Alors je fais une recherche sur google et je tombe sur ton article pédant. Je le lis parce que je ne sais pas que je viens de tomber sur le blog de quelqu'un de désagréable. qui ne m'apporte rien. ton article pollue le web.

Alors oui il est utile de dire que in_array est LENT et de dire pourquoi il est lent. Et par ailleurs, il y a beaucoup d'amateurs qui utilisent ce langage d'amateur et qui sont autodidactes alors il est encore plus utile de leur préciser que in_array est lent et pourquoi.

le fait est que même le développeur chevronné qui débute en PHP a besoin de savoir que c'est lent et pourquoi, et comment contourner. Bref PHP c'est un langage d'amateur, et on le voit bien au travers de la teneur de ce genre de billets. tu es un amateur.

2. Le mercredi, avril 25 2012, 10:51 par Laurentj

>j'ai dix ans d'xp en développement C++, et java

et moi plus de 20 ans en C/C++/Asm, et j'ai utilisé pas mal d'autres langages...

>et là je vois qu'un array est une hash table et que in_array se contente de parcourir le hash.

Oui, c'est une hash table, mais ce qui est hashé, ce sont les **clés** accédant aux valeurs, pas les valeurs elles-même.

>Donc quand je dois coder deux lignes de php dans ce langage pourris, même avec toute l'expérience et ma connaissance des algos

Oui enfin, quand on s'y connait vraiment en algorithmie, on se doute bien de la manière dont c'est implémenté. Il n'y a pas 50 manières de parcourir une liste de valeurs et de trouver celle que l'on veut.

>je tombe sur ton article pédant.

C'est marrant, j'en pense pareil de ton commentaire

> Je le lis parce que je ne sais pas que je viens de tomber sur le blog de quelqu'un de désagréable. qui ne m'apporte rien. ton article pollue le web.

De mon point de vue, c'est l'article que je critique qui pollue le web.

>Et par ailleurs, il y a beaucoup d'amateurs qui utilisent ce langage d'amateur

Ce langage d'amateur motorise les plus gros sites web de la planète.

Cependant

>tu es un amateur.

Tu as oublié de lire mon CV...