Forums : Xul, Xbl, JS...

Si t'es modules sont réutilisables et indepandant, je te conseille vivement de regarder plutot du coté du XBL.

Grosso modo ce sont des "binding" personnalisé, qui te permette de definier de nouveaux modules (justement)

Par exemple tu pourrais avoir un Xbl pour <MonCalendar>.

Si tu continue dans cette voie (et meme sans continuer en fait, mais ça simplifie) tu pourras via JS ajouter tes modules où tu le souhaite avec les methode DOM.

un exemple de ce que je fais pour une appli xul basée sur le framework jelix, dont la démo est là http://demo.jelix.org (login/pass : admin/admin)

Il y a un template principal, qui contient la structure générale de l'interface en XUL, en particulier une toolbar, une menubarre, et une zone principale, qui est une iframe.

L'appli est modulaire et chaque module apporte donc, via un overlay sur l'interface principale, les éléments additionnels à ajouter dans le menu, la toolbar etc.. Par contre, pour la partie de l'interface trés spécifique au module, c'est affiché dans l'iframe (pour éviter un chargement trop long et important des overlays). Sachant que les instructions xml-overlay dans le template principale sont générées dynamiquement en fonction de la présence/activation ou non des modules.

Pour ta question sur l'organisation de ton code, regarde le framework jelix ;-)

Merci pour vos conseils... Laurentj, ça m'a l'air intéressant ce framework Jelix. Si j'ai bien compris, c'est un sorte de SDK pour développer une nouvelle génération de sites webs, façon "web 2.0" ? Quelque chose pour minorer au maximum l'échange de données entre l'internaute et le serveur, en servant de PHP/JS/XUL ? Faudra que j'y jette un oeil quand j'aurai le temps...

Sinon pour mon problème, je pense que le plus simple pour moi à mettre en place est de jouer avec du hidden et du collapse sur tous mes box contenant mes modules. Ainsi je pourrais avoir un controle total sur tous mes modules. L'avantage, c'est qu'une fois chargé, a priori tout va très vite pour les changements d'interface...

Sinon, j'ai une autre question sur l'affichage et le filtre de données par rapport au temps de traitement. Voici la situation. J'ai un fichier SQLite3 qui contient plusieurs milliers d'enregistrements que je voudrais parcourir avec un tree et filtrer avec des menulist... J'envisage plusieurs approches :

• Utilisation de SQLite3 nativement + Filtre temps réel

Pour moi, le plus simple serait d'utiliser directement ma base de données SQLite3 pour remplir mes tree grâce à Mozstorage... et que le contenu soit filtré en temps réél... mais j'ai peur que les performances ne soient pas au rendez-vous. =/

• Utilisation de SQLite3 nativement + Filtre par recherche

Est-ce qu'un bouton Recherche pour filtrer réduirait le temps d'affichage ? Cela permettrait d'afficher moins de résultats par requête ?

• Transformation SQLite3 en RDF + Filtre temps réel

Là, je générerais des fichier RDF pour remplir mes tree avec un filtre en temps réel...

• Transformation SQLite3 en RDF + Filtre par recherche

Je transforme ma bdd en RDF et je fais des recherches manuellement.

Voilà, j'aimerais connaitre vos avis concernant les performances de ces différentes solutions, et s'il en existe d'autres que je ne connais pas encore ? Genre, tout mettre en mémoire pour un accès instantanné ? etc...

Merci =)

iFrame ?
... il me semble avoir lu que les enfants étaient ignorés ...

<iframe>
  <box> <-- Les enfants ici sont ignorés
</iframe>

Tu peux tester ta base SQLite3 avec SQLite Manager pour voir si tu as des temps d'accès raisonnables.

Pour infos j'effectue la requête SQL avec mozStorage et je remplis le tree avec DOM (createElement, appendChild).

Bonjour thefab, j'utilise très fortement SQlite Manager car d'une part il m'aide à vérifier la base que je construis via une appli en PHP + PDO_SQLITE, et d'autre part, c'est l'une des 2 seules applications XUL que je connaisse avec TexTree utilisant SQLite3. En fait, je passe mon temps à explorer le code pour tenter de comprendre comment tout ça peut bien marcher.

D'ailleurs, j'adore ta dernière version qui réussit enfin à écrire sur mes bdd créées avec PHP + PDO_SQLITE, ce qui n'était pas le cas avec la 1ère version ^^

Mais je ne comprends pas vraiment comment je peux me servir de SQLite Manager pour vérifier mes temps d'accès ? Une grande partie de ce temps d'accès n'est-il pas influencé par mon code JS/XUL ? Selon que je fasse un filtre temps réel ou une recherche ? Est-ce un système D qu'il faille réaliser ? genre un SELECT sur quelques milliers d'enregistrements pour voir le temps de réponse ? Ou me conseilles-tu une méthode plus rigoureuse ?

Si j'ai bien compris, c'est un sorte de SDK pour développer une nouvelle génération de sites webs, façon "web 2.0" ?

Façon web 2.O, euuuh, non...Développer des applis web tout court. (des concepts dans jelix datent de quelques années déjà...)

Quelque chose pour minorer au maximum l'échange de données entre l'internaute et le serveur, en servant de PHP/JS/XUL ? Faudra que j'y jette un oeil quand j'aurai le temps...

Non, pas du tout. un framework, ça sert à structurer ton appli, fournir des libs pour développer plus rapidement. Jelix fournit donc tout ça.

Sinon pour mon problème, je pense que le plus simple pour moi à mettre en place est de jouer avec du hidden et du collapse sur tous mes box contenant mes modules. Ainsi je pourrais avoir un controle total sur tous mes modules. L'avantage, c'est qu'une fois chargé, a priori tout va très vite pour les changements d'interface...

Oui, mais si tu as à la base une archi modulaire, il est fortement conseillé d'utiliser les overlays.

Sinon, j'ai une autre question sur l'affichage et le filtre de données par rapport au temps de traitement...

La meilleure solution : générer du rdf coté serveur et faire un template dans le tree dans ton xul. L'affichage sera beaucoup plus rapide, et surtout, tu n'a pas à recharger toute l'interface si les données changent : juste à recharger le rdf.

Et comme c'est une page php qui génère ton rdf, comme à toute page php tu peux passer des paramètres qui te serviront de critère pour ta requète SQL.

en schematisant/simplifiant au maximum donc, tu as une page php ou xul pour afficher l'interface, et un autre pour générer du rdf

voir /wiki/ApplisWeb/ExemplePhpRdf (dans l'exemple, tu remplace mysql par sqlite, le principe reste le même)

Merci bien pour tes conseils Laurent =)

Mais mon appli. est destiné à s'exécuter localement, on dit une application riche dans ce cas c'est ça ? Enfin c'est une application dont la base de données se situe chez l'utilisateur, donc le serveur ben c'est sa machine, et je ne pense pas lui installer Apache pour générer du RDF avec PHP non ?

Est-ce possible de générer du RDF avec JS en local ? Je vais me pencher sur le problème...

En tous cas, merci pour ton conseil d'utiliser RDF pour plus de rapidité, ça m'enlève déjà une question existentielle de la tête ;)

Je voulais plutôt parler de temps de construction que de temps d'accès en fait, le moteur DOM est rapide et afficher en construisant les éléments prend peu de temps. C'est dans ce sens la que je te disais de tester tes requête avec SQLite Manager car les éléments XUL sont générés. L'inverse serait, comme le dit Laurent, de travailler avec des templates, mais en local je te conseille SQLite3 pour stocker tes données et surtout pas RDF qui est absolument inutilisable pour stocker des milliers d'enregistrements.

Ben en fait, mes données sont déjà stockées, mon logiciel ne ferait que les lire et les afficher... donc faut voir le plus rapide : Afficher les données provenant de SQLite3 ou de RDF ?

Sinon, concernant mon interface, je vous mets ci-dessous le genre de code que j'ai mis en place mais qui me parait un peu "Mac Gyver" à base de Toolbar (parce que je trouve ça plus joli que des Tabs) et de Groupbox hidden ou pas :

prefs.xul

<?xml version="1.0" encoding="utf-8" ?>
<?xml-stylesheet href="chrome://global/skin" type="text/css"?>
<?xml-stylesheet href="chrome://ydm/skin/default.css"  type="text/css"?>

<!DOCTYPE window SYSTEM "chrome://ydm/locale/ydm.dtd">

<window
id="prefs"
title="&prefs.title;"
orient="vertical"
 xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

<script src="chrome://ydm/content/prefs.js" />

<toolbox>
	<toolbar id="prefs-toolbar">
		<toolbarbutton id="prefs-tb-main" oncommand="viewPrefsMain();" label="&prefs.main;" orient="vertical" />
		<spacer width="10" />
		<toolbarbutton id="prefs-tb-users" oncommand="viewPrefsUsers();" label="&prefs.users;" orient="vertical" />
		<spacer width="10" />
		<toolbarbutton id="prefs-tb-languages" oncommand="viewPrefsLanguages();" label="&prefs.languages;" orient="vertical" />
		<spacer width="10" />
		<toolbarbutton id="prefs-tb-skins" oncommand="viewPrefsSkins();" label="&prefs.skins;" orient="vertical" />
	</toolbar>
</toolbox>
<groupbox id="prefs-gbox-main" hidden="false" flex="1">
	<caption label="&prefs.main;" />
</groupbox>
<groupbox id="prefs-gbox-users" hidden="true" flex="1">
	<caption label="&prefs.users;" />
</groupbox>
<groupbox id="prefs-gbox-languages" hidden="true" flex="1">
	<caption label="&prefs.languages;" />
	<button label="Mettre en US" oncommand="changeLanguage();"/>
</groupbox>
<groupbox id="prefs-gbox-skins" hidden="true" flex="1">
	<caption label="&prefs.skins;" />
</groupbox>

</window>

prefs.js

...
function viewPrefsSkins()
{
document.getElementById('prefs-tb-main').removeAttribute('disabled');
document.getElementById('prefs-tb-users').removeAttribute('disabled');
document.getElementById('prefs-tb-languages').removeAttribute('disabled');
document.getElementById('prefs-tb-skins').setAttribute('disabled','true');

document.getElementById('prefs-gbox-main').setAttribute('hidden','true');
document.getElementById('prefs-gbox-users').setAttribute('hidden','true');
document.getElementById('prefs-gbox-languages').setAttribute('hidden','true');
document.getElementById('prefs-gbox-skins').removeAttribute('hidden');
}

Voilà, en gros, je me contente d'afficher/cacher mes Groupbox selon le bouton pressé en y mettant un attribut disabled... A mon avis, vous devez être en train de bondir sur vos chaises en lisant cela non ?

Est-ce que quelqu'un aurait une meilleure méthode à me conseiller ? Plus rigoureuse, plus pro ? Car j'ai peur d'avoir des soucis avec celle-là : En effet, ma fenêtre se dessine selon mon 1er groupbox, et si les autres sont plus grands, elle ne change pas du coup, ça me coupe les autres pages quand je vais sur Languages, ou Skins...

Merci pour vos conseils.

oh désolé, j'ai lu trop rapidement ton message. tu veux donc faire une appli locale.

Donc là, effectivement, l'utilisation de mozstorage peut être envisagé. Mais aussi rdf pourquoi pas ! Tout dépend du volume de donnée etc..

Par exemple, tu peux peut-être envisager de stocker en rdf toutes les valeurs de références (categories par exemple...), cela permettra d'utiliser les templates.

Je ne suis pas d'accord avec thefab sur le fait que rdf n'est pas fait pour stocker des milliers de données. En tout cas, à l'affichage, avec les templates, ce sera beaucoup plus rapide que si tu extrait toi même tes données de sqlite et tu génères des élements via le dom. Aprés, derrière, si tu fais beaucoup de manipulation de données compliquées, c'est vrai que l'api rdf n'est pas aisée. Mais cela peut être caché par une API de plus haut niveau (que tu realiserais)

En tout cas, la façon de réaliser ton interface d'appli est différente de celle de html où tout est généré à chaque action. Il faut que tu ait un maximum de chose statique, et que tu essaie d'utiliser au maximum les treeview, les templates etc.. Et pour le reste, manipuler le dom xul de ton interface pour modifier dynamiquement son contenu. Si le contenu xul de ton interface est énorme, tu peux l'éclater dans des overlays, soit utiliser des iframes. Tout dépend si par exemple, l'écran de gestion de news a beaucoup d'interaction avec les éléments d'interfaces communs (donc utilisation d'overlay), ou pas (donc iframe).

Pour ton exemple "simple", ta façon de faire n'est pas trés bonne : tu aurais pu utiliser un deck ! tu n'aurais alors pas à manipuler tous ces attributs. Ou alors utiliser un iframe..

Ok... il faudrait donc que je change d'optique ? En fait, dès que je vois iframe, j'esquive un peu car à l'époque de mon apprentissage web, les iframe étaient alors complètement abandonnées pour ses gros défauts d'indexation et tout... c'est un vieux réflexe.

Mais bon, je vais donc essayer approfondir mes recherches sur le deck et sur les iframe, merci beaucoup.

Et pour Mozstorage, je pensais justement qu'il apportait un système de templates pour l'utiliser de manière similaire à du RDF, ce n'est donc pas le cas ?

En fait, je vais avoir plusieurs filtres : Pays, Langue, Extension, Type, Sous-type,... et ensuite des milliers d'enregistrements à filtrer selon ces critères. Il serait donc peut-être intéressant de regarder du côté de RDF dans mon cas non ? Mais j'avoue avoir un peu de mal à me faire à ce format. Je sais créer des scripts PHP pour sortir un flux RSS 1.0 (donc du RDF) mais un fichier RDF "pur" avec des données plus complexes, ça m'a l'air plus difficile, enfin... je vais chercher =)

EDIT : Après des recherches sur deck il s'avère que c'est exactement ce qu'il me fallait, MERCI BEAUCOUP, mon code a gagné en lignes, en rapidité et en simplicité :

function viewPrefs(id)
{
document.getElementById('prefs-deck').setAttribute('selectedIndex',id);
}

<toolbar id="prefs-toolbar">
<toolbarbutton id="prefs-tb-main" oncommand="viewPrefs(0);" label="&prefs.main;" orient="vertical" />
<spacer width="10" />
<toolbarbutton id="prefs-tb-users" oncommand="viewPrefs(1);" label="&prefs.users;" orient="vertical" />
<spacer width="10" />
<toolbarbutton id="prefs-tb-languages" oncommand="viewPrefs(2);" label="&prefs.languages;" orient="vertical" />
<spacer width="10" />
<toolbarbutton id="prefs-tb-skins" oncommand="viewPrefs(3);" label="&prefs.skins;" orient="vertical" />
</toolbar>

Bref, merci beaucoup Laurent, comme ça, je vais partir sur des bases plus saines ^^

En fait, dès que je vois iframe, j'esquive un peu car à l'époque de mon apprentissage web, les iframe étaient alors complètement abandonnées pour ses gros défauts d'indexation et tout... c'est un vieux réflexe.

Oui mais là tu ne fais pas un document, mais une interface utilisateur ! La logique est tout autre

Et sinon, c'est quoi tout ces spacers !!! beurk.. Utilise CSS plutôt (margin par ex) !

Ah oui, c'est vrai, c'est un oubli... Je fais beaucoup de petits tests de codes pour prendre XUL/JS en main sans trop perdre de temps à faire le CSS, et parfois j'oublie d'effacer ces bouts de test. Merci de me l'avoir fait remarquer =)