Forums : Xul, Xbl, JS...

Salut,

Dans le fichier .js de ton application il faut créer le code suivant :

Création de la fonction que tu va appeler au chargement

function ta_fonction() {
 ...
 ...
 alert("blabla");
}

Et à la fin de ton fichier .js, tu appelle ta fonction à l'aide de la fonction setTimeout. Cette fonction permet d'attendre que l'appli soit chargée et que tous les composants soient disponibles.

setTimeout("ta_fonction()",250);

Cela me semble être une bonne idée mais cela ne fait que déplacer mon Pb.

Il faudrait que je puisse déclencher cette fonction dans l'overlay et non dans le javascript lié à l'overlay.

Pourquoi ? parce que dans mon_overlay.php je fais une requète et que l'ouverture de la boite ne dois avoir lieu que selon le résultat de cette requète et je ne veux pas transformer mon .js en .php (bien que cela serait possible).

j'ai bien une idée, par exemple en affectant une value dans un champ caché de cet overlay (une value dynamique donc) et dans la fonction.

function ta_fonction() {
 if (document.GetElementById('login')== "vrai")
 alert("blabla");
} 

le setTimeout sera bien activé mais ne fera rien A moins qu'une autre bonne idée fuse ;-)

Pourquoi ne pas créer un fichier .js dédié à cette fonction, de cette façon tu pourrais l'appeler ou non via php !

if (....) echo '<script type="application/x-javascript" src="chrome://tonappli/content/fonctionload.js"/>';

Et dans le fichier .js tu appelle ta fonction comme je te l'ai décris dans le message précédent

Juste une petite précision, je viens de trouver cette commande qui remplace le setTimeout d'une façon plus "propre" :

dans le fichier .js dédié à ta fonction de chargement tu écris :

window.addEventListener("load", ta_fonction, false); // Appel de la fonction de chargement

function ta_fonction() {
 ...
 ...
 alert("blabla");
} 

micro : je ne ferais pas du tout comme ça. Je ne trouve pas ta façon de faire trés propre.

En premier lieu, ton script php devrait construire l'overlay en fonction des droits/authentification. Donc si pas authentifié, tu renvoi un overlay avec le strict minimum (voir vide). Ce script renvoi du contenu, et n'a pas à gérer les problèmes de droits coté client.

En deuxième lieu, je ferais un service web, qui permettrait de savoir si l'utilisateur est authentifié ou pas. Ainsi, sur le onload de l'application, j'appellerai une fonction qui fait un xmlhttprequest sur le serveur pour appeler ce service web. En fonction de la réponse, tu affiche ou pas un message d'alerte de non authentification.

L'avantage de cette solution : tu n'as pas besoin d'attendre que tout les overlays &co soient chargés, et tu peux appeler ton service web dans d'autres contextes. Il faut éviter de mélanger ce qui est propre à l'interface utilisateur, et ce qui est propre aux traitements métiers.

En tout cas, le coup du settimeout est foireux. Car si le serveur met du temps à répondre, ça va bugger. Faut vraiment éviter d'utiliser settimeout pour attendre qu'un truc soit chargé. C'est une erreur de conception.

Je ne connaissais pas cette possibilité. très interessant

J'ai la même préoccupation, et dans un premier temps je renvoyais un overlay avec les champ de login et je masquais les autres conteneurs (disgracieux qd ils sont vides) C'est pour eviter cela et parce qu'il me semble qu'une fen^tre indépendante (et réutilisable) de login est plus adaptée que je cherche dans cette direction.

Désolé mais le contenu est dépendant des droits donc je le gère coté serveur et l'intérêt du xul et des overlays (outre la re-utilisabilité) est bien de fournir de l'interface adaptée au contenu (et des méthodes associées) en plus du contenu .

Ce contenu et son interface spécifique font bien partie du traitement métier. C'est pour cela que je l'ai mis dans un overlay. l'autre partie de l'appli est en chrome sur le poste utilisateur.

Au sujet de ta remarque sur le timeout, celui-ci etant déclenché par l'overlay, il n'y a aucune raison qu'il soit activé avant que celui soit chargé. (il faudra que j'essai en mettant le delai à 0) mais la syntaxe addEventListener est nettement plus propre.

Dans tous les cas un grand merci à vous deux.

Désolé mais le contenu est dépendant des droits donc je le gère coté serveur et l'intérêt du xul et des overlays (outre la re-utilisabilité) est bien de fournir de l'interface adaptée au contenu

Je n'ai pas dit le contraire. Mais ce n'est pas à ton overlay d'afficher une boite d'alerte/de login si en dehors de ça est d'afficher l'interface de ton appli. Ton overlay est là pour compléter la fenêtre courante, pas pour afficher des nouvelles fenêtres, ou pour agir sur autre chose.

Si ton code coté serveur est bien foutu, tu utilises alors des sessions. Que tu demande un overlay ou appel xmlhttprequest, le navigateur envoi les cookies de sessions. Donc que ce soit lors de la génération de l'overlay, d'un script js, d'un rdf ou d'un service web, tu sera dans la session correspondant à l'utilisateur.

Pour moi, dans l'overlay, en fonction des infos de sessions, donc en fonction des droits de l'utilisateur, tu génères ton interface. On est bien d'accord là dessus.

Mais si tu veux savoir coté client si il est authentifié, le mieux est vraiment de faire appel à un service web. Et en fonction du résultat, tu affiche une boite de login ou autre. (et tu appelera un autre service web pour executer l'authentification, et tu rechargera ton fichier xul)

À mon avis faut éviter le "bricolage" que tu fais dans ton overlay (l'histoire du timeout, cacher des trucs ou pas et tout le toutim)

laurentj a écrit:

Mais si tu veux savoir coté client si il est authentifié, le mieux est vraiment de faire appel à un service web. Et en fonction du résultat, tu affiche une boite de login ou autre. (et tu appelera un autre service web pour executer l'authentification, et tu rechargera ton fichier xul)

et à chaque nouvelle fenètre ouverte par l'appli je re-interroge le service Wb pour savoir si la session est bien en cours et quels sont les droits du user.?

C'est à mon avis une surcharge réseau et serveur inutile. Le bricolage comme tu dis, est de mon point de vue une façon beaucoup plus logique et lègère de gérer cela, puisque utilisant les sessions je sais au moment de constituer mon overlay dans quelle situation est le user. A moi de lui fournir l'interface qui correspond à cet état et si je ne le connais pas , de lui demander de se logger.

D'ailleur dans une appli web traditionnelle c'est comme cela que c'est géré, le script vérifie les variables de session et en cas d'echec par un header location redirige vers la page de login.

Pourquoi tant de haine (joke) envers l'association de ce mécanisme et de Xul.

Ce débat m'interesse au plus haut point

et à chaque nouvelle fenètre ouverte par l'appli je re-interroge le service Wb pour savoir si la session est bien en cours et quels sont les droits du user ?

Pourquoi à chaque fenêtre ouverte ? une fois que tu es loggé, tu es loggé. Ta session est en place. C'est vrai qu'aprés tu as la gestion du timeout si il y en a un. Mais elle doit être séparée de ton overlay, car le timeout peut survenir à n'importe quel moment (lorsque tu charges un rdf distant, que tu appels un service web etc..), et pas seulement au moment où tu charges un overlay.

C'est à mon avis une surcharge réseau et serveur inutile.

Pas sûr. faire une requete http vers un SW pour savoir si il est loggé, puis recevoir quelques caractère "oui/non", je doute que cela soit plus pénalisant qu'embarquer quelques lignes de script js/balise xul supplementaires dans un overlay ;-)

puisque utilisant les sessions je sais au moment de constituer mon overlay dans quelle situation est le user. A moi de lui fournir l'interface qui correspond à cet état

Tout à fait d'accord. J'ai pas dis le contraire.

et si je ne le connais pas , de lui demander de se logger.

Oui, mais c'est pas top je trouve de tout faire en même temps. voir plus bas mes explications.

D'ailleur dans une appli web traditionnelle c'est comme cela que c'est géré,

Oui mais là, tu n'es pas dans le contexte d'appli web. Tu es dans un contexte client-serveur web. C'est une trés grosse différence, et cela implique d'avoir une architecture différente dans ton code de celle d'une appli web traditionnelle.

Pourquoi tant de haine (joke) envers l'association de ce mécanisme et de Xul.

Séparation du code en couche, qui permet une meilleure maintenance, une évolution plus facile etc.. Tous les frameworks modernes font cette séparation : processus d'affichage, processus métier, processus de coordination etc... Tout est séparé. D'ailleurs, même dans Mozilla tu as cette séparation au niveau technique : le XUL pour l'interface, le JS pour la glue avec la logique métier qui doit se trouver dans les XPCOM (ou les services web) etc...

Toujours aussi dans l'optique : une fonction fait une seule chose, mais elle le fait bien. Concept qu'on retrouve dans Unix d'ailleurs.

Donc ton overlay, il devrait faire une seule chose : ajouter des élements d'interface, en fonction des droits en cours. Point. Mais il n'a pas à lancer une demande de login, à mettre le grille pain en route et faire le café

La gestion de l'authentification doit être séparé à mon avis.

Bon maintenant, rassures toi, il n'y a aucune haine dans mes propos Tu fais comme tu le sens, c'est toi le master de ton code surtout que mon avis n'est basé que sur les quelques élements déscriptifs de ton appli que tu m'as donné, et peut etre que si j'avais toute l'appli sous les yeux, mon avis serait différent (mais pas sûr ;-) ). Mais pour ce que j'en sais maintenant, je ne procéderais pas comme toi

laurentj a écrit:

et à chaque nouvelle fenètre ouverte par l'appli je re-interroge le service Wb pour savoir si la session est bien en cours et quels sont les droits du user ?

Pourquoi à chaque fenêtre ouverte ? une fois que tu es loggé, tu es loggé. Ta session est en place.

Oui, mais dans ta proposition, à chaque overlay que j'invoque, c.à.d pour chaque fenètre de mon appli, je me retrouve dans la même situation ce qui implique que je devrais invoquer le WS à chaque fois.

C'est vrai qu'aprés tu as la gestion du timeout si il y en a un. Mais elle doit être séparée de ton overlay, car le timeout peut survenir à n'importe quel moment (lorsque tu charges un rdf distant, que tu appels un service web etc..), et pas seulement au moment où tu charges un overlay.

C'est à mon avis une surcharge réseau et serveur inutile.

Pas sûr. faire une requete http vers un SW pour savoir si il est loggé, puis recevoir quelques caractère "oui/non", je doute que cela soit plus pénalisant qu'embarquer quelques lignes de script js/balise xul supplementaires dans un overlay ;-)

Moi je suis sur du contraire puisque une fois mes variables de sessions positionnées les qq lignes de script js/balise n'ont plus aucune raison d'être inclus dans mon overlay puisque je le créé dynamiquement en php.

puisque utilisant les sessions je sais au moment de constituer mon overlay dans quelle situation est le user. A moi de lui fournir l'interface qui correspond à cet état

Tout à fait d'accord. J'ai pas dis le contraire.

et si je ne le connais pas , de lui demander de se logger.

Oui, mais c'est pas top je trouve de tout faire en même temps. voir plus bas mes explications.

je ne fais pas tous en même temps, 1) je vérifie les drois et suivant les droits j'envoie l'interface ad hoc, le formulaire qui contiendra les données ou bien le formulaire qui servira à se logger.

conceptuellement, c'est la même chose.

D'ailleur dans une appli web traditionnelle c'est comme cela que c'est géré,

Oui mais là, tu n'es pas dans le contexte d'appli web. Tu es dans un contexte client-serveur web. C'est une trés grosse différence, et cela implique d'avoir une architecture différente dans ton code de celle d'une appli web traditionnelle.

Pourquoi tant de haine (joke) envers l'association de ce mécanisme et de Xul.

Séparation du code en couche, qui permet une meilleure maintenance, une évolution plus facile etc.. Tous les frameworks modernes font cette séparation : processus d'affichage, processus métier, processus de coordination etc... Tout est séparé. D'ailleurs, même dans Mozilla tu as cette séparation au niveau technique : le XUL pour l'interface, le JS pour la glue avec la logique métier qui doit se trouver dans les XPCOM (ou les services web) etc...


Toujours aussi dans l'optique : une fonction fait une seule chose, mais elle le fait bien. Concept qu'on retrouve dans Unix d'ailleurs.


Donc ton overlay, il devrait faire une seule chose : ajouter des élements d'interface, en fonction des droits en cours. Point. Mais il n'a pas à lancer une demande de login, à mettre le grille pain en route et faire le café

Mon overlay (une fois créé) ne fait qu'une seule chose.

<?php
header("Content-type: application/vnd.mozilla.xul+xml");
if(true){
   //contenu de l'overlay
}else{
   // je ne fais qu'ajouter window.addEventListener("load",...
   // la fenetre de login, et le js sont déjà dans la fenètre principale chrome
}
?>

pour ce qui est du café, c'est une bonne idée ;-)

La gestion de l'authentification doit être séparé à mon avis.

c'est aussi mon avis, dans ta proposition l'overlay doit aussi faire la même chose que dans le mien, il vérifie les droits.
la seule différence est-que j'adapte la réponse directement en déclenchant l'affichage de la boite de login, mais est-ce que cela n'est pas de l'interface après tout ?