Forums : Xul, Xbl, JS...

Le fait de separer les ecrans est une bonne chose, mais si ces derniers doivent communiquer entre eux optes plutot pour des overlays. De plus dès que tu as un objet un peu compexe que tu imagine quasi autonomne, pense XBL, meme si tu ne t'en servira qu'une fois. Le code sera plus facile à maintenir. Maintenant si les fonctionnalité sont vraiment pas connexe, alors les iframes sont une bonne solution. De mon experience, un peu des 2 est necessaire. surtout sépare bien l'interface des données, quitte à faire 10 requetes AJAX a l'initialisation de ton appli.

Merci pour tes conseils.

Mais, est-ce normal que XUL n'ai pas d'élément pouvant être (re)charger par une page sans être une (i)frame. Et ainsi avoir une continuité de la page.

Chaque écran est bien différent l'un de l'autre, se sont chacun des écrans d'encodages.

Mais l'utilisation d'une iframe pose un problème de taille. Les raccourcis clavier défini dans la page principale ne sont pas accessible dans la page d'encodage. Même activer le menu par clavier ne fonctionne pas.

Donc, l'utilisation d'une iframe ne résout pas le problème. Vaux t'il mieux charger des écran complet (plus lourd à charger) avec des includes ou des overlays partout.

merci

ben c'est le principe de l'iframe, le document est independant du reste, tu imagine les probleme si tu avais un element comme l'overlays, mais que tu puisses charger et recharger à ta convenance, le merdier au niveau des instances de variables etc....

Pour en revenir a ton truc, si tu separe correctement et completement ton interface de tes données, tu verras que se sera pas lourd. ton interface fichiers xul et les données fichiers php ou jsp pas de données dans ton interface. J'insiste bien la dessus. donc overlays. si tu as un systeme d'onglet, tu peux tjs charger les données afferante a l'ecran idoine en cliquant sur le tab. mais attention à toujours t'assurer de la coherence entre les données coté cliente et coté server. Sinon à chaque selection d'onglet tu perds les datas modifiées par le users.

Qd tu cites les includes, si c'est au includes comme dans les jsp auquels tu fais allusion ca veux dire que tu ne separes pas l'interface des données. ton interface ne devrais pas etre dynamique mais des fichiers static extention *.xul. je sais j'insiste.

Bonjour, Hhf dit :

tu imagine les probleme si tu avais un element comme l'overlays, mais que tu puisses charger et recharger à ta convenance, le merdier au niveau des instances de variables etc....

Mais tu PEUX charger et recharger un overlay à ta convenance ! Et sans pour autant générer un merdier noir dans les variables :

document.loadOverlay()

est là pour ça et, hormis un bug qui complique le (re)chargement de plusieurs overlays dans une même séquence de code, c'est très pratique et efficace.

oups, d'accord, effectivement on peut visiblement, mais je pense que c'est uniquequement dans le chrome non ? d'ou le fait que j'ai jamais essayé. Mais si ca marche alors je trouve ca super dangereux : si cet overlay charge un script, qui lui meme instantie des variables. au reload, bing tout est ecrasé ... non ? ou pire dans ta page principale, si tu fait ref a un ID style :

tools = {
  _elt : null,
  get elt_de _mon_overlay() {
     if(this._elt==null) this._elt =    document.getElementById("id_ds_overlay");
     return this._elt;
  }
}

J'ai pas testé mais si tu recharge l'overlays, tools._elt pointe tjs sur un element qui n'existe plus dans la page (garbage collector ne peut pas faire grd chose), mais surtout quand tu essayeras d'y accéder, ben ca ne pointera pas sur le bon element.

Enfin je peux me tromper sur toute la ligne, ya peut etre un interet dont j'ai jamais eu besoin, si ya un exemple pertinent, je veux bien que tu m'expliques. Sinon, je vois pas de raison de recharger un overlay.

Voila on devrait peut etre ouvrir un nouveau sujet pour diserter de ca... je sens que ca va etre un sujet houleux.