Forums : Xul, Xbl, JS...

Ok... je vois. Je garderais ma BDD comme source et à partir de là, je génère (soit à chaque démarrage, soit manuellement) un fichier RDF contenant mes 3000 cartes avec le strict minimum : à savoir les ID de chaque propriété... Ainsi je peuple un tree avec mon RDF.

Maintenant, je ne maitrise pas trop le filtrage de RDF : Est-il possible de faire la même chose que ce que je fais déjà ?

• Recherche depuis le nom de la carte
• Recherche depuis une égalité numérique
• Recherche depuis une inégalité numérique

Je peux faire ça rien qu'avec RDF et le peuplage d'un tree ? Ou bien je suis obligé de passer par une recherche et une régénération de RDF ? Mais dans ce cas, je vois pas trop où j'y gagne non ?

Pour l'instant, je suis en train de recoder tout le coeur de mon code pour ne plus utiliser mon parcours de tableau de 3000 lignes, mais plutôt la répétition de requête SQL et l'affichage direct du résultat, histoire de voir ce que ça change... Ensuite, il faudra que je teste la 3° méthode, celle que tu évoques avec l'utilisation de RDF.

Bon, après modification de mon code, il apparait effectivement un gain de réactivité. Une requête SQL exécutée à chaque frappe ou changement d'état de formulaire, c'est pas mal... Même avec 2000 enregistrements, la recherche et l'affichage ne prennent pas plus de 3/4 secondes, c'est largement mieux que mes temps de réponse concernant le parcours de mon tableau cards, qui eux étaient de 15 secondes au moins. Je gagne aussi en RAM : de 91 Mo, je passe à seulement 15 Mo !

Bref, c'est pas mal... mais pas encore parfait, 3/4 secondes, c'est sympa mais pas encore au top... Effectivement, comme à chaque frappe de clavier, je fais une requête, à la 1ère frappe généralement je perds le controle de l'interface 1 ou 2 secondes donc ça fait un effet de "bug/ralentissement" sur mon interface alors que je voudrais un filtrage tout en douceur... Pour des recherches plus précises, aucun souci, ça coule tout seul... Mais comme je fais du temps réel, forcément, avant de pouvoir bien préciser mes critères, faut bien cliquer sur mon formulaire, un critère après l'autre, et généralement, pour les 1 ou 2 premiers, j'ai encore plus de 500 résultats, ce qui me fait perdre le controle de l'interface, c'est dommage... Evidemment, je résoudrais le problème en mettant un bouton "Recherche", mais j'aimerais vraiment rester avec du filtre en temps réel car c'est super ergonomique je trouve !

Devrais-je vraiment tenter l'expérience RDF pour avoir un filtrage/affichage fluide avec des temps de réactions encore meilleur ?

Je préfère demander avant car autant modifier mon code sen requête SQL, c'était pas trop long, autant tout passer en RDF, c'est un peu plus compliqué, surtout que je ne maitrise pas trop la technologie...

Merci pour vos conseils.

EDIT : Après étude du cas RDF, il semble que mon filtrage ne soit pas possible avec RDF en l'état actuel non ? Mais apparemment, ça le sera avec XULRunner 1.9 et FF3 d'après ces liens :

• http://xulfr.org/forums/read.php?8,6429,(..)
• http://wiki.mozilla.org/XUL:Template_Fea(..)

Apparemment, jusque-là, impossible de chercher une chaine de caractères dans le filtrage de mon RDF, ni même une comparaison numérique... =/

Mais du coup, tant qu'à attendre les nouvelles fonctionnalités de XR 1.9... n'était-il pas question de pouvoir réaliser des templates à partir de sources non-RDF comme SQLite3 par exemple ? Car si c'est le cas, me suffit donc juste d'attendre que les fonctionnalités soient développées (quelques semaines/mois) pour utiliser directement ma base SQlite3 pour générer des templates avec un filtrage correct (recherche de chaines, comparaisons,...) non ?

Alors la les future spec.... Neanmoins pour ton cas, le PB de latence entre chaque frappe, sont due au fonction DOM que tu utillses pour parcourir et modifié ta liste. Voila comment je vois la chose :

dèja utilise un tree et non une listbox, le tree est plus performant pour les listes importantes.

ensuite tu rempli ton tree avec un RDF. dans ton textbox ou tu rentre le filtre, tu gere l'evt onkeyup pour regenerer un nouveau RDF que tu affecte à ton tree. Le RDF se rempli en asynchrone. Si neanmoins lors d'une frappe rapide, tu remarque du lag, fais plutot un xbl pour ton textbox de recherche qui ne declenche le onchange que si la frappe de touche est passé d'un certain tps. En gros si tu tape super vite plusieur lettre il attend que tu arrete de taper pour declencher le onchange.

Voila pour moi de toute facon c'est tjs RDF qui prime. Pense en plus que si tu utilise cette techno, tu n'aura auqu'un PB pour passé en remoteXul. Ce qui pourait etre sympa non ? une Base mysql, un apache, un parser php... un firefox, et tu accede à ton appli de n'importe ou dans le MONDE....

Allez bon courage

Tu veux donc dire qu'à chaque frappe... Je dois :

• Faire une requête SQL et générer un RDF
• Recharger mon RDF dans mon tree

C'est ça ? Et c'est plus rapide de générer un fichier RDF et de le charger que de "simplement" utiliser le DOM pour ajouter des éléments dans mon tree ? Alors ça je m'en serais pas douté... la génération d'un RDF de 3000 enregistrements est-elle instantanné ainsi que son peuplage dans un tree ?

Je viens de penser à un truc en relisant quelques posts sur le forum : En fait, l'utilisateur ne lira jamais les 3000 lignes, mais affinera plutôt sa recherche, alors est-ce que je ne devrais pas plutôt me concentrer sur le nombre de retours à afficher ? Genre une requête avec "LIMIT 200" ? C'est sûr que c'est moins la classe qu'un filtre sur la totalité de la base mais bon, ça pourrait résoudre le problème de lenteur d'affichage du DOM... Y aurait-il une astuce pour faire comme des recherches sur le net avec plusieurs pages de résultats ? Genre avec un bouton "+ de résultats", on voit les 200 résultats suivants et ainsi de suite... ou bien on verrait carrément le nombre de pages avec un lien vers ces pages ?

Sinon tu m'intéresses avec ton textbox dont le "on change" ne se déclencherait qu'à la fin de la frappe... ce serait compliqué à faire ?

Sinon j'avoue ne pas comprendre ni connaitre ce que tu appelles une application en remoteXUL ?

En tous cas merci pour toutes ces infos, c'est très intéressant =)

EDIT : J'ai généré un RDF... mais je ne sais comment peupler mon tree en local... tous les tutos que je lis ont des adresses web avec des liens http pour définir les infos... et je ne trouve pas comment ça marche pour un fichier local ?

pour le onchange (moi j'utilise oninput), tu peux

• annuler une éventuelle et précédente requête (cancelTimeOut)
• programmer une éxécution décalée d'une demi-seconde de ta requête (setTimeOut)

comme ça pas besoin de xbl...

Pas bête teddyber, merci du conseil.

Sinon plus j'y pense, plus je me dis que le système de requête plus légère peut être pas mal genre : 0-100, 100-200,... avec des boutons pour passer aux "pages suivantes" à créer avec le DOM... suffit de retourner le nombre total de results, on divise par le nombre de result à afficher par "page" de listbox, et paf on créé un filtre rapide et pouvant afficher toutes les réponses !

Si j'arrive à développer ça, du coup je n'aurai pas besoin de m'occuper de RDF car l'affichage via le DOM d'une centaine de lignes dans un listbox est instantannée ! A partir de 200/300, on le sent un peu... Est-ce que la supériorité en vitesse du tree sur le listbox marche aussi pour un contenur généré via DOM ou bien c'est juste plus rapide quand on utilise RDF comme source ?

Raphael a écrit:

Tu veux donc dire qu'à chaque frappe... Je dois :
- Faire une requête SQL et générer un RDF
- Recharger mon RDF dans mon tree
C'est ça ? Et c'est plus rapide de générer un
fichier RDF et de le charger que de "simplement"
utiliser le DOM pour ajouter des éléments dans mon
tree ? Alors ça je m'en serais pas douté... la
génération d'un RDF de 3000 enregistrements
est-elle instantanné ainsi que son peuplage dans
un tree ?

Clairement non, bien sur tu crées ton RDF avec tes 3000 entree d'abord, puis tu fais de un filtre il est probable que le nombre va violement chuter non ?

Pour info, un pote genere un RDF de 37000 entree, ca met 8 secondes sur le server (il est en remoteXUL), mais au bout de 3 secondes il commence à avoir des noeud dans son tree. Donc a mon avis 3000 c'est rien.

Je viens de penser à un truc en relisant quelques
posts sur le forum : En fait, l'utilisateur ne
lira jamais les 3000 lignes, mais affinera plutôt
sa recherche, alors est-ce que je ne devrais pas
plutôt me concentrer sur le nombre de retours à
afficher ? Genre une requête avec "LIMIT 200" ?
C'est sûr que c'est moins la classe qu'un filtre
sur la totalité de la base mais bon, ça pourrait
résoudre le problème de lenteur d'affichage du
DOM... Y aurait-il une astuce pour faire comme des
recherches sur le net avec plusieurs pages de
résultats ? Genre avec un bouton "+ de résultats",
on voit les 200 résultats suivants et ainsi de
suite... ou bien on verrait carrément le nombre de
pages avec un lien vers ces pages ?

Sinon tu m'intéresses avec ton textbox dont le "on
change" ne se déclencherait qu'à la fin de la
frappe... ce serait compliqué à faire ?

Pas trop , tu peux t'inspirer d'un XBL que j'ai fais et qui est sur le Wiki, le spinbutton ou plus tu click plus l'incrementation accelere. Sinon voir avec le oninput, je n'est pas experimenté.

Sinon j'avoue ne pas comprendre ni connaitre ce
que tu appelles une application en remoteXUL ?

En remoteXUL, ca veut dire en client distant. un serveur HTTP un parseur php, une base mySQL, et ton appli est accessible de partout dans le monde. Via internet par exemple si tu va sur www.sudoxul.com tu verras une appli XUL en remote, rien à installer sur le client.

En tous cas merci pour toutes ces infos, c'est
très intéressant =)

EDIT : J'ai généré un RDF... mais je ne sais
comment peupler mon tree en local... tous les
tutos que je lis ont des adresses web avec des
liens http pour définir les infos... et je ne
trouve pas comment ça marche pour un fichier local
?

Oui, les exemple sont pas tjs facile voila la forme que ton xulfile et ton RDF doit avoir en esperant ne pas faire de fautes :

tree.xul

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<window xmlns:html="http://www.w3.org/1999/xhtml" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
	<tree flex="1" datasources="cards.rdf" ref="urn:cards" multiple="false" flags="dont-build-content">
		<treecols>
			<treecol label="Liste des cartes" primary="true" flex="1"/>
		</treecols>
		<treechildren/>
		<template>
			<treechildren flex="1">
				<treeitem uri="rdf:*">
					<treerow>
						<treecell value="rdf:urn:cards:rdf#id" label="rdf:urn:cards:rdf#name"/>
					</treerow>
				</treeitem>
			</treechildren>
		</template>
	</tree>
</window>

cards.rdf

<?xml version="1.0" encoding="UTF-8"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:NC="http://home.netscape.com/NC-rdf#" xmlns:CD="urn:cards:rdf#">
	<RDF:Seq RDF:about="urn:cards">
		<RDF:li><RDF:Description CD:name="carte x" CD:id="idcard"/></RDF:li>
		<RDF:li><RDF:Description CD:name="carte x" CD:id="idcard"/></RDF:li>
		<RDF:li><RDF:Description CD:name="carte x" CD:id="idcard"/></RDF:li>
		<RDF:li><RDF:Description CD:name="carte x" CD:id="idcard"/></RDF:li>
		<RDF:li><RDF:Description CD:name="carte x" CD:id="idcard"/></RDF:li>
		<RDF:li><RDF:Description CD:name="carte x" CD:id="idcard"/></RDF:li>
		<RDF:li><RDF:Description CD:name="carte x" CD:id="idcard"/></RDF:li>
	</RDF:Seq>
</RDF:RDF>

Voila, les truc urn:.... quelque chose, sont totalement arbitraire, c'est juste pour designer les "entité" de facon unique d'ou URN pour "unique resource name" si je ne me trompe.

   xmlns:CD="urn:cards:rdf#"

signifie que tu definie l'espac de nom "CD" la aussi tu met se que tu veux, dans la mesure ou apres tu remet la meme chose dans le fichier xul au moment ou tu designe la resource que tu veux ici :

  label="rdf:urn:cards:rdf#name"

A savoir, que la c'est un exemple tres simple. mais dans ton cas ca doit suffire.

Le flags="dont-build-content" sur le tree est tres important (pour les grandes listes) il te permettra moyenant quelque attributs en plus de trier la liste d'un simple click sur les entetes du tree. Mais surtout d'accelerer le traitement en interne des noeuds. Par contre la recuperation d'un treeitem selectionné devient moins trivial qu'avec le DOM, il y a des tutos pour ca sur le site.

Voila, je crois que tu as deja a faire pour ce soir... lol

Pour le tree je conseillerais d'utiliser un treeView pour controler le peuplement de l'arbre, c'est beaucoup plus rapide que de peupler du DOM et cela évite de passer par du RDF dans ce cas précis.

Pour info: http://www.xulfr.org/xulplanet/xulqa/q_t(..)

David Marteau a écrit:

Pour le tree je conseillerais d'utiliser un
treeView pour controler le peuplement de l'arbre,
c'est beaucoup plus rapide que de peupler du DOM
et cela évite de passer par du RDF dans ce cas
précis.

Pour info:
[http://www.xulfr.org/xulplanet/xulqa/q_treebview.
html]

Tu parle d'un merdié.... LOL C'est qd mm plus simple un RDF....

Ouah, c'est pas un peu lourd ce Treeview ? C'est quoi en fait ? c'est une espèce de fonction qui facilite le peuplement d'un tree mais sans passer par le DOM ? Et c'est plus rapide ça ?

Bon, je suis en train de recoder mon filtrage de cette manière :

• A chaque changement d'état du filtre, je fais une requête SQL que je limite aux XXX premiers résultats et je peuple un listbox via le DOM.
• Je créé des boutons pour les pages suivantes de résultats.

Si ça passe bien je laisserai ça, c'est quand même le plus simple et le plus logique pour moi... Et si je n'ai pas d'assez bonnes performances, j'essaierai la génération de RDF via requête SQL, et peuplement d'un tree via template RDF pour voir si c'est plus réactif comme ça. Et si ça non plus ça marche pas, ben j'essaierai treeView =)

Merci pour votre aide à tous... maintenant, je me retrousse les manches et je fonce droit dans le coeur du code, je vous tiens au courant ;)

Désolé si je réponds de travers j'ai pas tout lu le fil...

Ouah, c'est pas un peu lourd ce Treeview ? C'est quoi en fait ? c'est une espèce de fonction qui facilite le peuplement d'un tree mais sans passer par le DOM ? Et c'est plus rapide ça ?

C'est tout simplement monstrueusement plus rapide. J'ai remplacé DOM par une vue personnalisée (implémentation de nsITreeView) dans mon SQLite Manager et c'est vraiment rapide. Ca à l'air compliqué mais on peut faire plus simple car il n'y a que 2 méthodes à implémenter vraiment.

Perso, n'étant pas encore au fait de toutes ces possibilités, j'avais utilisé pour une application un tree alimenté par un RDF. C'est rapide et simple mais effectivement, ça lague quand il y a pas mal de résultats. Donc à l'époque, j'avais utilisé un stack contenant une <html:div> avec une image gif de chargement. Du coup, avec un Observer, je masquais mon tree le temps de l'alimenter et je masquais ensuite ma div.

Un jeu de cache cache certainement pas très propre, je vous l'accorde.

Tout ça pour dire que le treeview me semble bien adapté à ton projet. Seulement, tu devras t'amuser (et certainement t'arracher les cheveux) si tu cherche un rendu du genre http://www.ycd-project.org/portail/img/(..)

Sinon bon courage ;) moi j'ai déjà 12300 cartes dans ma base donc prévoit large. 3000, ça me semble un peu juste...

Merci pour vos conseils...

En fait, j'ai résolu tous ces problèmes en faisant :

• Requête SQL avec LIMIT XXX paramétrable, à chaque changement de filtre
• Remplissage Listbox via DOM

A priori c'est instantanné pour XXX < 150 et pour une base de 2000 enregistrements... mais je ne pense pas que la recherche SQL soi beaucoup plus lourde avec 10000 enregistrements non ? C'est surtout le remplissage/effaçage via le DOM qui prend du temps.

Cette technique me convient bien car de toutes façons quand on recherche une carte, si jamais on a plus de 100 résultats, on va tous les lire mais plutôt affiner la recherche... et au pire l'utilisateur peut augmenter le nombre de results dans ses options. Et au pire de chez pire, je pourrais faire un affichage "par pages" si vraiment y a besoin.

Sinon c'est quoi ton projet ? un jeu de cartes également ? =)

<mode:HS> Une gestion de collection de cartes Magic en ligne http://www.magic-collection.info/FREUD . Mais par la suite, quand j'aurais plus de facilité avec le XUL (surtout le DOM en fait), je ferais peut-être une petite appli autonome pour gérer la collection off-line et la synchroniser avec le site. </mode:HS>

Je vais peut-être dire une connerie (ce sera pas la première et certainement pas la dernière) mais l'utilisation d'un treeview me parait plus simple et plus rapide à mettre en place et à l'utilisation, je pense que le treeview serait plus rapide et plus pratique, d'autant qu'il permet notamment de laisser la possibilité de trier rapidement les infos sur les différentes colonnes affichées, de ne plus avoir à te préoccuper de scinder tes résultats "par pages"... En ma qualité de newb, le treeview s'est avéré bien plus pratique (un treeview, un ondblclick ou un popup contextuel et l'affaire est dans le sac)

Mais bon, c'est toi qui gère. Si tu avais le temps de tester les deux, ça te permettrait de te faire un avis sur les gains.

Je confirme, le treeview *est* la manière la plus rapide pour gérer un arbre avec beaucoup d'enregistrements.