Forums : Xul, Xbl, JS...

Effectivement, je pense que ce n'est pas une bonne idée de passer des données via l'url comme ça.

Tu peux stocker cette information de session dans les prefs (que tu efface lorsque tu quitte l'appli par exemple).

Il y a aussi les objets properties ou persistentproperties qui permettent apparement de stocker des propriétés. Je n'ai jamais utilisé mais je pense que ça peut t'aider. Tu les appelles en getService (et non createInstance) pour avoir toujours la même instance.

Ou encore mieux, tu te fais ton propre composant XPCOM (en js ça suffit), appelé par getService, avec l'interface que tu veux (genre tu te fais des méthodes setSession, getSession etc...)

Le souci c'est qu'il n'y a pas que les sessions qui sont transmises via des paramètres... de manière générale, j'ai en réalité en moyenne 4-5 arguments et plus... :-(

je ne vois pas en quoi c'est un souci. au lieu de stocker juste la session dans les prefs ou l'objet properties, tu stockes aussi tes autres paramètres.

je viens de penser aussi à un truc, c'est que tu peux passer des paramètre à une fenêtre sans passer par l'url, en les mettant dans un objet :

  var parametres = { session:"123", foo:"bar",...}

  window.openDialog("chrome://...", "foo", "features ...", parametres);

et ensuite dans la fenêtre tu les recupère par

 window.arguments[0].session
 window.arguments[0].foo

oui effectivement, on pourrait faire comme ca, mais cela est valable pour des fenetres de dialogue, mais comment faire lorsqu'on change de page via une instruction "window.location=chrome...xul" ?

honnetement, je ne pense pas que ce soit une bonne idée de changer de page comme ça. Ce n'est pas une application web que tu fais. Je ne connais pas de logiciels qui décident d'un coup de modifier toute son interface utilisateur

M'enfin, si tu y tiens, il faut passer par les prefs ou les objets XPCOM comme je t'ai dis. Ainsi tu stocke tes données quelque part en mémoire.

j'avoue ne pas trés bien comprendre ta remarque ci-dessous,

je ne connais pas de logiciels qui décident d'un coup de modifier toute son interface utilisateur

apparemment il n'y a pas que moi qui utilise des url chrome avec paramètres, voici un bout de code tiré des cahiers du programmeur xul (de jonathan Protzenko) :

function passerPageSuivante() {
if (gConfig.url != null) {
	var url = "chrome://xulforum/content/index.xul?config="+gConfig.url+"&phpsessname="+gPhpSessName+"&phpsessid="+gPhpSessId+"&auteur="+document.getElementById("xf-ident-ident_nom").value;
	setTimeout(function() {
		document.location.href=encodeURI(url);
	}, 500);
	/* on délaie pour éviter que les résultats
	de la première recherche LDAP retombent 
	sur la page suivante, ça arrive */
} else {
	ajouterErreur(gStringBundle.getString("confInvalide"));
}
}

enfin du coup j'espere ne pas etre totalement dans l'erreur ;-) surtout aprés deux ans de programmation sur l'appli...

Que ce soit dans le livre ou pas, il en reste pas moins que je ne ferais pas comme ça. (et c'est pas comme ça que font les dev de Firefox ou de Thunderbird ;-) ). Jonathan a montré une façon de faire. Ça veut pas dire que ce soit la meilleure (il a peut être utilisé cette méthode pour que son tuto soit plus facilement appréhendable, pour pas avoir à expliquer les XPCOM en même temps etc.) Cette méthode, comme tu l'as toi même constaté, a ses limites.

Ce n'est pas une application web que tu fais. C'est un logiciel. Donc ne te restreint pas aux urls, utilise tous les moyens que tu as à ta disposition.

Les paramètres d'une fenêtre devraient se passer autrement comme je l'ai dit. D'ailleurs, parle-t-on bien ici de paramètre à une fenêtre ? Parce qu'un id de session, à priori, il est global à ton logiciel. Donc ce n'est pas un paramètre, c'est une variable globale à ton logiciel. Donc cette donnée doit être stockée dans un objet global à ton appli, dans un endroit accessible par toutes tes fenêtres. C'est plutôt lourdingue je trouve que de passer ces données à chaque écran via l'url. Surtout que par ce moyen, tu te limite au type chaine. Alors que si tu avais un objet "service" centralisant les données globales de ton appli :

• tu peux alors y stocker n'importe quoi (des tableaux, des objets, des entiers etc...) et autant que tu veux : c'est toi qui le défini !
• tu peux l'utiliser à n'importe quel moment dans ton appli (dans un script de fenetre ou dans un autre composant XPCOM, et toujours sans avoir à passer des paramètres dans tout les sens)
• c'est vraiment plus simple à utiliser (pas de parsing d'url à faire etc..)

 var DataService = Components.classes["ma_centrale_de_donnee"]
    .getService(Components.interfaces.nsIMaCentraleDeDonnee);

 var session = DataService.session;

 // stockage du login qui servira ailleurs
 DataService.login = document.getElementById("champsLogin").value

 // etc...

Pour finir, ce n''est pas vraiment difficile de faire un XPCom en javascript. C'est quasi du copier coller avec les tutos que tu peux trouver (dans notament le bouquin Creating Application With Mozilla). Et si ça te rebute d'en faire un, tu peux en utiliser un qui est tout pret, comme properties (même si au niveau type de donnée, tu es forcément limité)

je suis encore d'accord avec laurentj, (decidement, je suis un gros leche botte), pour ton application, tu devrais plutot faire des decks contenant tous tes ecrans, puis tu bascule les vues en fonction de l'affichage desiré, ca demande plus de rigueur au niveau du code javascript (car les pages ne sont jamais rechargées), mais au final tu y gagne. tu mutualises tes objets, ainsi partagé et accessible par toute tes pages en meme temps. tu peuples tes interfaces via des AJAXs ou des RDFs, tu separes ainsi totalement les données des interfaces. Souvenons nous que XUL est à l'interface ce que HTML est à la presentation, mais le shema J2E n'est pas adapté à un client riche, donc pas d'interface avec des données à l'interieur cas typique d'une JSP.