Discussion :

[link_915]

Bonjour,

J'ai un problème de variables :

En fait j'ai un fichier JS (main.js) qui va avoir besoin de variables présentes dans d'autres fichiers .js (var1.js , var2.js, var3.js, etc ...)

exemple main.js :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
items: [login,
	                var1,
	                var2,
	                var3
	        ]

exemple var1. js :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var var1 = 3

voilà je sèche

merci d'avance,

link_915

[RomainVALERI]

voilà je sèche

A quel niveau ?

Aucun problème sur le principe d'accéder à des variables définies dans des fichiers séparés. Quel est le problème observé ?

[SpaceFrog]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
items: [login,
	                var1,
	                var2,
	                var3
	        ]

au depart c'est pas du js ...

[Bovino]

Mouais... tu pourrais essayer d'être un peu plus clair pour décrire ton problème...

Alors si je suppose que tu déclares items comme un tableau dans un objet, j'espère que tu n'espère pas que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var var1 = 3

va référencer la valeur du même nom dans le tableau...

En tout état de cause, item (qui est fort maladroit comme nom de propriété puisque c'est aussi un mot clé du langage) est très probablement erroné puisque dans un tableau, il faut passer des valeurs, or toi tu passes des noms inconnus de JavaScript.

[Watilin]

Moi je veux voir l'objet qui est autour de item.

item (qui est fort maladroit comme nom de propriété puisque c'est aussi un mot clé du langage)

item, un mot-clé de JS ? Tu dis ça parce que la balise code le colore en bleu ?

[RomainVALERI]

Moi je veux voir l'objet qui est autour de item.


item, un mot-clé de JS ? Tu dis ça parce que la balise code le colore en bleu ?

Bon, y'a bien NodeList.item ou plus généralement HTMLCollection.item, mais comme mot réservé, non, en effet D'ailleurs, pourquoi est-ce que la coloration le mentionne en bleu au fait, j'avais jamais remarqué ?

[Bovino]

item est une méthode native du DOM JavaScript (toutes les collections et le enumerables), ça en fait donc un mot clé du langage...
J'imagine que s'il était question d'une variable alert par exemple, il y aurait plus de consensus sur le fait que c'est maladroit, pourtant, alert est aussi une méthode de l'objet window.
Alors utiliser ce genre de nommage est maladroit, pas interdit. Maladroit parce que c'est potentiellement source de confusion, pour la maintenance du code bien sûr, mais aussi dans certains cas pour JavaScript.

@Romain : tu auras noté que j'ai bien dit : "qui est fort maladroit comme nom de propriété puisque c'est aussi un mot clé du langage" et non "qui est interdit comme nom car c'est un mot réservé du langage".

[NoSmoking]

Alors utiliser ce genre de nommage est maladroit, pas interdit. Maladroit parce que c'est potentiellement source de confusion, pour la maintenance du code bien sûr, mais aussi dans certains cas pour JavaScript.

d'autant que l'on peut souvent trouver un mot en français, c'est plus facile pour nous on possède un dictionnaire très riche, levant toute ambiguïté.

[RomainVALERI]

On est tous bien d'accord sur l'emploi maladroit de ce type de mots-clés ^^ pour ce qui est des "mots réservés", au temps pour moi, ce n'est pas la même chose

Et de toutes façons, comme dit NoSmoking, le vocabulaire francais permet d'éviter la plupart de ces conflits potentiels

[dukej]

item est une méthode native du DOM JavaScript (toutes les collections et le enumerables), ça en fait donc un mot clé du langage...

@Romain : tu auras noté que j'ai bien dit : "qui est fort maladroit comme nom de propriété puisque c'est aussi un mot clé du langage" et non "qui est interdit comme nom car c'est un mot réservé du langage".

Quand est-ce que tu comprendras que ce que tu dis n'a pas de sens, sépare un moment le DOM du Javascript, le JS peut-être utilisé sans DOM.
Et quand tu codes un objet en JS tu as le droit d"utiliser les noms de propriétés que tu veux sur un objet et ce n'est certainement pas maladroit.

si tu t'amuses à venir rajouter des propriétés sur un objet du DOM, alors que cette propriété est native du DOM, là oui c'est n'importe quoi. Mais venir rabacher à chaque fois que l'utilisation d'un nom de propriété dans un objet/classe purement js est maladroit parce qu'il existe dans un objet X ou Y du DOM, c'est aussi du grand n'importe quoi

[Bovino]

J'avoue que tes arguments sont impressionnants.

sépare un moment le DOM du Javascript

je veux bien, mais vu que la quasi totalité des questions posées sur ce forum sont liées au JavaScript coté navigateur, ça va devenir compliqué d'y répondre

le JS peut-être utilisé sans DOM

tu aurais un exemple concret dans le cadre d'une page Web ?

Quand est-ce que tu comprendras que ce que tu dis n'a pas de sens

Ben, quand tu arrêteras de sortir des fèves comme ça
Dans le cadre d'une page Web, l'interface DOM est pleinement du JavaScript, ne t'en déplaise, tout comme la gestion des bases de données en PHP est du PHP bien qu'il soit possible d'utiliser des bases de données sans PHP ou PHP sans extensions sur les bases de données !
JavaScript étant un langage de script, son vocabulaire est complété par l'interface que lui offre son environnement.

Ensuite, pour ce qui est du nommage, je peux bien comprendre que tu ne sois pas d'accord sur ce qui est maladroit ou non, mais si on suit ta logique, tout ce qui n'est pas interdit n'est pas maladroit, ce qui autorise des noms de propriétés comme "class" ou même "un nom de propriété bien pensé" qui, bien qu'autorisés, me semblent maladroits. Et comme j'ai tendance à appliquer les mêmes règles à tous les types de nommage (variables, fonctions, paramètres, propriétés), je considère un nom comme setTimeout ou alert maladroit (ce ne sont pourtant que des noms de méthodes de l'objet DOM window), je considère au même titre maladroit d'utiliser comme noms n'importe quel nom de propriété ou de méthode natif du langage dans le contexte d'exécution.

[RomainVALERI]

*facepalm*
[...] Mais venir rabacher à chaque fois que l'utilisation d'un nom de propriété dans un objet/classe purement js est maladroit parce qu'il existe dans un objet X ou Y du DOM, c'est aussi du grand n'importe quoi

Range ton flingue, cowboy, tu t'es gourré de cible

Ni dans ce post ni dans d'autres à ma connaissance Bovino ne s'est fait le censeur borné des pratiques des autres : il a bien dit "maladroit", et il a argumenté. Libre à chacun d'en tirer son propre jugement, de contre-argumenter, etc.

Et dis-moi au fait, quel est l'intérêt d'utiliser un des très très très rares mots déjà utilisés dans le DOM pour le choix d'un identificateur (DOM ou hors-DOM d'ailleurs) ?

[Watilin]

Moi ça m'arrive d'utiliser item comme nom de variable quand j'itère sur une nodeList. Ce n'est pas dérangeant dans le sens où la propriété item a un cadre bien précis. Il y a peu de risque de mauvaises surprises.

Dans le cas présent, je parie que c'est du JSON, et que donc ça vient d'un serveur qui a de fortes chances de ne pas tourner en JS. De plus, c'est possible que le code qui génère le JSON ait été écrit par quelqu'un d'autre que link_915, du coup ce serait pas lui qui décide…

[sekaijin]

bon après tout ça si nous revenions à la question de départ

si j'ai bien compris tu as 4 script dont 1 main.js utilise des variables des autres

il n'y a pas de pb à faire cela.
il suffit de s'assurer que les 3 premier script sont correctement exécuté avant d'exécuter le dernier main.js.

il faut donc s'assurer des cycles d'exécution.
si la variable est définie dans le script directement est que celui-ci n'a pas d'attribut defer alors la variable doit exister à la fin du script
si l'attribut defer est présent la variable n'existera qu'après le chargement complet du DOM et sa fermeture.
si la definition est dans un gestionnaire d'événement
il est nécessaire de s'assurer que l'événement aura lieu avant l'exécution du code de main.js.

Je n'aime pas les variables globales et généralement je n'en ai qu'une
dans ton cas tu peux créer le tableau d'abord
chaque script ajoute ensuite des valeurs dans le tableau

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

myNameSpace= {items: ['login']

var1.js

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

myNameSpace.items.push(3);

cela évite de créer des variables pour ensuite mettre leur valeur dans un tableau.
var1.js

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var1=3;

main.js

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
myNameSpace={items: [
  'login',
  var1
]

quant à l'utilisation des mots comme items je ne les utilise dans mes propres objets que s'il ont la même sémantiques que dans les objets standards. je ne mettrais l'attribut length à mon objet que s'il représente la longueur courante d'une collection. ce qui implique que l'attribut doit être maintenu correct par l'objet. si je ne peux atteindre cette spécification je n'utilise pas l'attribut length. s'il ne s'agit pas du nombre d'élément d'une collection je cherche un nom plus approprié, s'il s'agit bien de cette taille mais que je ne peux garantir qu'il est maintenue alors je préfère le calculer et je ne mets pas l'attribut length mais la méthode getLength
mon but est qu'il n'y ai aucune ambiguïté par rapport à ce qu'un développer js connais déjà dans le langage et les objets standards.

A+JYT

[dukej]

J'avoue que tes arguments sont impressionnants.

je veux bien, mais vu que la quasi totalité des questions posées sur ce forum sont liées au JavaScript coté navigateur, ça va devenir compliqué d'y répondre

tu aurais un exemple concret dans le cadre d'une page Web ?

Ben, quand tu arrêteras de sortir des fèves comme ça
Dans le cadre d'une page Web, l'interface DOM est pleinement du JavaScript, ne t'en déplaise, tout comme la gestion des bases de données en PHP est du PHP bien qu'il soit possible d'utiliser des bases de données sans PHP ou PHP sans extensions sur les bases de données !
JavaScript étant un langage de script, son vocabulaire est complété par l'interface que lui offre son environnement.

Ensuite, pour ce qui est du nommage, je peux bien comprendre que tu ne sois pas d'accord sur ce qui est maladroit ou non, mais si on suit ta logique, tout ce qui n'est pas interdit n'est pas maladroit, ce qui autorise des noms de propriétés comme "class" ou même "un nom de propriété bien pensé" qui, bien qu'autorisés, me semblent maladroits. Et comme j'ai tendance à appliquer les mêmes règles à tous les types de nommage (variables, fonctions, paramètres, propriétés), je considère un nom comme setTimeout ou alert maladroit (ce ne sont pourtant que des noms de méthodes de l'objet DOM window), je considère au même titre maladroit d'utiliser comme noms n'importe quel nom de propriété ou de méthode natif du langage dans le contexte d'exécution.

Décidément on ne sera jamais d'accord, mais tu fais fausse route en venant critiquer le terme "item" dans un objet JS et en disant qu'il est utilisé par le DOM dans une collection. Mais on s'en cogne puisqu'il sont totalement différents et que item n'est pas un mot clé.

Ce qui serait gênant serait de faire :
obj : {
'class' : 1,
'parseInt' : 2
}
etc...
Là oui tu utilises des mots clé du langage et ce n'est pas trop conseillé. Mais venir rabacher le même message pour 2 choses complètement différentes, c'est un peu déplacé.

[link_915]

Bonjour, merci de votre aide.

le problème est résolu, aucun problème pour utiliser des variables dans des fichiers séparés effectivement, mon problème venait de la génération de ces fichiers javascript en fin de compte (via java).

Du coup je comprenais vraiment pas pourquoi ça ne voulait pas fonctionner et voilà pourquoi je séchait.

merci encore,

link_915

[sekaijin]

je reviens sur les variables globales
pour faciliter la maintenance et améliorer les perfs

j'évite tout ce qui est global, et tous ce qui est js généré dynamiquement.

par principe (donc à ne pas suivre dans l'absolu mais à réfléchir avant d'agir) le javascript est dans un fichier statique est ne contient pas de données.

la partie dynamique du site génère des data et jamais de fonctions.

pour éviter les globales voilà comment je fais.
un premier script statique qui définit un objet (qui vas servir d'espace de nom) dans celui-ci je mais les éléments de base de mon appli.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
myApp={
  'name':'sampleApp',
  ...
}

ensuite un script dynamique vient ajouter les éléments dynamiques de l'application.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
myApp.user={
  'name':'<* echo userName *>',
  'lang':'<* echo userLanguage *>',
  ...
}

si je dois définir différement une fonction ou une méthode en fonction de ce que fait le serveur je ne créé pas la fonction dynamiquement avec le langage serveur mais je charge un script statique ou un autre qui qui chacun d'eux contient la définition des différents cas. cela m'arrive très rarement. j'ai souvent rencontré la génération dynamique de fonction dans le cadre de l'internationalisation.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

formatDate=function(...)

qui va formater la Date en fonction de la langue de l'utilisateur. dans ce genre de cas j'ai un fichier statique par langue et je charge le fichier de la langue. mieux je définit une seule fonction format qui prends en compte un pattern de format du coup la fonction n'est compilé qu'une fois par le poste client

depuis que je fais ainsi je n'ai plus de pb de conflit de nom avec des script extérieurs le seul objet de mon des étant myApp
les scripts statiques sont toujours mis dans les caches (Webcontener JEE, frontal HTTP, Proxy, navigateur, moteur JS)
question perf c'est incomparable. un js généré dynamiquement par le serveur suit le chemin complet ci dessus l'app du webcontener génère le js qui traverse tout et comme il est dynamique il n'est pas mis en cache seul le moteur JS garde la version compilé. à l'appel suivant du même JS comme il est dynamique il reprends complètement le même chemin. et ce pour tous les utilisateurs.

s'il est statique le premier utilisateur à l'utiliser suit le chemin complet. mais à chaque étape le script est mis en cache. un autre utilisateur du même sous réseau n'ira le chercher que dans le proxy local un utilisateur d'un autre réseau ira le chercher dans le cache du frontal et l'utilisateur local sur le même browser ira le chercher dans le cache du navigateur et s'il recharge la page le moteur JS ne le rechargera pas si ses dépendances n'ont pas changé.

A+JYT

[link_915]

Bonjour, je réouvre le thread car je me suis rendu compte que tout ne fonctionnait pas comme je le voulais

En fait, j'ai un fichier index.js que j'ai du éclater en plusieurs fichiers.js

Ces fichiers.js représentants chaque item à inserer dans le tableau si l'utilisateur les a choisis.

Le problème est tel que mon application se lance, avec mes variables entrées dans le tableau.

main.js :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
myNameSpace={items: [
  item1,
  item2,
  item3
]

En revanche, quand je souhaite faire dans item1.js

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

myNameSpace.setActiveItem(item2)

j'ai une erreur m'indiquant que item2 est indéfini. Si quelqu'un à une idée

merci.

[Bovino]

j'ai une erreur m'indiquant que item1 est indéfini. Si quelqu'un à une idée

Euh... j'imagine que tu parles de item2 plutôt
Si c'est le cas, c'est normal... item2 est une propriété de myNameSpace or tu l'utilises comme si c'était une variable...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

myNameSpace.setActiveItem(myNameSpace.item2)

[link_915]

Oui, je voulais dire item2 (j'ai édité mon précédent message).

J'ai réussi à résoudre mon problème en mettant onReady: devant l'appel.

merci.