Utiliser des variables depuis un script distant

[Sephi-Chan]

Salut à tous,

Dans le cadre du développement de Bug Spirit, je développe une interface riche en Javascript.

Pour cela, chaque page instancie un objet Interface qui dispose de plusieurs contrôles (affiche/masquer la barre de Volonté, mettre un territoire en sélection active, etc.).

Cela fonctionne plutôt bien, mais voilà, mes appels Ajax (effectués avec jQuery) utilisent le type de retour script : c'est à dire que la page chargée à distance retourne du Javascript qui est exécuté. Mon problème, c'est que sur ce script n'est pas dans le même contexte que la page active, du coup quand je lui parle de mon objet Interface, il ne sait pas à quoi il à affaire.

Il s'agit en quelque sorte de créer un singleton (l'interface n'est instanciée qu'une fois) que je peux récupérer depuis un autre contexte de script.

Savez-vous comment gérer ce problème ? Je sais le contourner, dans le cas où il n'y a pas de solution directe.


Sephi-Chan

[Allwise]

Une petite question qui peut paraître débile, mais :
Le code javascript retour, il est bien exécuté par la fenêtre du navigateur qui lance la requête Ajax, et dans laquelle il y a ton objet Interface ?

J'ai déjà fait une RIA dans laquelle une vue = un fichier js. Mon application envoyait des requêtes Ajax, qui renvoyaient du code javascript, qui était exécuté dans un callback de la requête Ajax... Ça marchait au poil, j'avais aucun problème de contexte, puisque le code étant exécuté dans la même fenêtre, on était dans le même contexte ( je parle de contexte au sens large ). Pour interagir avec mon interface qui était un singleton, j'avais soit la façon singleton getInstance(), soit une variable "App" globale et donc accessible partout.

[Sephi-Chan]

En fait, j'ai commis une erreur lors de l'instanciation de mon objet Interface. Il était déclÇa va mieux maintenant.


Mon fichier application.js (c'est du code un peu bidon, pour tester) :

function Interface(){}



Interface.prototype.buildPlayerFrame = function(player){

  var e = $('<div />').text(player.name);

  $('#container').append(e);

};



$(document).ready(function(){

  

  $('.login-needed').click(function(event){

    $.get(this.href + '.js', {}, null, 'script');

    event.preventDefault();

  });

  

});

Dans le corps de ma page, j'instancie mon Interface (pour le moment, j'aurais pu le faire dans application.js, mais en pratique, l'interface prendra des arguments) :

<script type="text/javascript">

  var interface = new Interface();

</script>

Et la vue rendue par l'appel Ajax (le responseText, exécuté comme du script) :

interface.buildPlayerFrame({ name: "Sephi-Chan" });

Donc tout va bien.

J'ai posté en vitesse avant d'aller chez l'ophtalmo, et — sans mauvaise blague — j'y ai vu plus clair après.


Sephi-Chan

[Ter Rowan]

question qui ne se veut pas du tout polémique, mais pour comprendre

j'avais opté pour une architecture/utilisation d'ajax différente, à savoir un code javascript que je définirais comme événementiel à deux niveaux :

quand l'utilisateur interragit avec le navigateur, on capte l'événement et on lance un processus ajax
le serveur analyse et renvoie des données (des ordres et des paramètres)
Un gestionnaire générique interprête les ordres (des événements "techniques" finalement, d'où le deuxième niveau) et appelle des fonctions javascript que le "client" connait depuis le chargement de la page
du coup je n'échange que des informations, pas de "script" entre le client et le serveur

Tu fais sensiblement autrement.
Quel est l'intérêt ? Ma méthode est elle trop "débutante", trop lourde en ressource (pourtant je me dis mieux vaut charger une seule fois un script qu'autant de fois qu'il est appelé) ? etc ...

[Sephi-Chan]

L'approche que tu proposes est effectivement celle que je compte adopter une fois que mon interface sera conçue plus clairement. En ce moment, je change pas mal d'avis sur certains points et je préfère donc une approche plus naïve et agile (et aussi plus coûteuse, comme tu l'as dit).

Le but es à terme d'avoir un fichier interface.js qui contiendra tous les comportements "précodés". Un client lourd en Javascript, si l'on veut.


Sephi-Chan

[Roworll]

Sur ce point, l'objet Asset de Mootols peut se révéler intéressant.
Il permet de charger des images, des CSS mais aussi du JS à la volée.

Grace à ce genre d'objet, on peut découper le code principal en plusieurs modules qui sont alors chargés en fonction des actions de l'utilisateur, et non plus au démarrage.

Avantage : des fichiers JS plus spécifiques (donc moins gros) ce qui limite les chargements inutiles au démarrage.

[Sephi-Chan]

Intéressant.

Cela dit, je ne pense pas employer ça puisque mon objet Interface (et ses styles) sera probablement monolithique.
Il ne reste alors que les images pour lesquelles j'emploie un sprite CSS.
Je pense qu'il ne restera pas d'inutiles, même s'il est encore trop tôt pour le dire.
Merci pour la ressource, en tout cas !


Sephi-Chan

[Ter Rowan]

ca me fait penser Sephi, si tu développes encore un forum, alors développe la fonctionnalité "mes favoris" car typiquement ce post, j'en aurais besoin dans plusieurs mois, et je risque de le perdre ^^

[Sephi-Chan]

Ouais c'est prévu.
Ici, tu peux toujours t'abonner à la discussion, comme ça tu en gardes une trace dans les pages de ton profil et tu es notifié lors d'une réponse.


Sephi-Chan

[Allwise]

Découper l'application de sorte que des gros codes javascript qui contiennent des objets, classes, des instructions... soient échangées via Ajax est utile pour les raisons évoquées par Rowroll : - appli plus rapide à charger au démarrage, appli plus modulaire -, mais on peut aussi trouver une logique "d'encapsulation des données" ( pardonnez l'abus de langage ), je veux dire qu'en gérant des fichiers javascripts qui sont au final des vues côté serveur, on peut n'afficher que ce que les users ont le droit de voir en fonction de leurs privilèges.
C'est typiquement le cas que j'ai eu avec une appli utilisable par plusieurs profils différents, et qui avaient chacun accès à une partie de l'appli, non pas à sa totalité. Si j'avais géré l'intégralité du code Javascript côté client, toutes les parties de l'appli auraient pu être à la portée de tout le monde, ce qui n'est pas très logique d'une part, et peut constituer une faille de sécurité de l'autre.