Discussion :

[piotrowski-s]

Votre code javascript est inline c'est à dire qu'il est inclus dans les lignes de votre html, ce qui est une mauvaise pratique.

Vous placez votre code js dans un fichier et vous faites un include du fichier js dans le header de votre page html, laquelle est gérée dans un template au niveau PHP.

non?

oui je comprends

mais la c'est exceptionnel,

en fait mon site est compartimenté en plusieurs sections toutes autonomes mais interdépendantes avec des scripts propres a chaque section de même pour le design, template et css.

du coup exceptionnellement pour l'include et comme il n'y en a qu'une commune a toutes les sections (4 modules) contenant environ 500 pages chacune, j'ai donc mis le code "en liberté", oui c'est une mauvaise pratique je le reconnais dans la seule page contenant l'include.

[tse_jc]

C'est une mauvaise pratique de façon générale, c'est certain. Néanmoins si cela peut vous rassurer, il est parfois justifié de le faire et c'est dans ce cas une bonne pratique.

Faites le en include js pour gérer cette persistance, c'est le meilleur conseil que je puisse vous donner.


++

[piotrowski-s]

parfait, je vais faire ainsi, et m'intéresser on ne peut plus sur le HTML5 apparament pas d'impasse possible.

Merci pour votre collaboration.

[tse_jc]

Oh j'avais pas vu cela

Une variable en localStorage est valable pour un domaine et non une page. Donc pas de gros volume, juste une variable pour toutes les pages.

??? vous pouvez développer, car là j'ai rien compris ???

[djibxav]

Oh j'avais pas vu cela


??? vous pouvez développer, car là j'ai rien compris ???

Quand j'ai lu ça:

sur chacune des pages?

ca représente un volume de plusieurs milliers de page.

Ah non c'est pas gérable, je préfère rester avec des variables de session.

J'ai pensé qu'il avait peur de créer une variable en localStorage par page, ce qui en effet aurait été ingerable, le fait que le problème soulevé soit de dupliquer du code sur 500 pages ne m'était pas venu à l'esprit tellement c'est une pratique enfouie dans la préhistoire du dev web.

Je me pose encore souvent la question de la portée d'une donnée, surtout quand j'appréhende de nouvelles pratiques comme celle-ci introduite avec html5, je ne me pose plus naturellement celle de dupliquer du code.

Les variable en loacalStorage ayant pour portée le domaine et non l'url, la portée n'était donc pas un problème avec un nombre de page volumineux.

[tse_jc]

J'ai pensé qu'il avait peur de créer une variable en localStorage par page, ce qui en effet aurait été ingerable, le fait que le problème soulevé soit de dupliquer du code sur 500 pages ne m'était pas venu à l'esprit tellement c'est une pratique enfouie dans la préhistoire du dev web.

En effet cette peur n'a pas de raison d'être car ce n'est pas ainsi que fonctionnent le sessionStorage et le localStorage.

Le sessionStorage / localStorage est un espace de stockage global géré au niveau navigateur compris entre 5 et 10Mo (selon les navigateurs) et qui est indépendant du contenu affiché. Il est du type clé/valeur et la valeur est de type string uniquement.

par conséquent

Les variable en loacalStorage ayant pour portée le domaine et non l'url, la portée n'était donc pas un problème avec un nombre de page volumineux.

est faux/incorrect.


++