Conseils sur une méthode de stockage d'attributs

Version imprimable

Bonjour

Voilà mon site contient plusieurs DIV auxquelles j'aimerais stocker des informations sur l'action à mener en fonction d'un événement sur ce DIV.

il y a donc l'événement en lui même, l'action à effectuer et une condition et ces 3 éléments peuvent être multipliés par autant d'événement d'action ou de condition que je souhaite associer au DIV.

J'ai donc la possibilité de créer un tableau contenant plusieurs tableau associatifs lesquels contiendrait les 3 éléments "événement, action, condition" et bien sure l'identifiant du DIV pour pouvoir retrouver ces informations en fonction du DIV.

Cela m'oblige à boucler dans le tableau à chaque fois pour lire les informations stockées.

Autre possibilité

Celle de stocker les informations sous forme d'attributs dans mon DIV, certe je n'ai pas la possibilité de stocker un tableau dans un attribut mais je peux écrire quelque chose comme cela.
Code:

1 2 3 4 Div.setAttribute("Event", "mouseMove,mouseOut,mouseDown"); Div.setAttribute("Cond", "true,true,true"); Div.setAttribute("DIVID=DIV_LEFT:BackgroundColor=F0F0F0,DIVID=DIV_LEFT:BackgroundColor=FFFFF0,DIVID=DIV_LEFT:BackgroundColor=0F0F0F"
un split sur chaques attributs par la virgule me permettant de récupérer chaque éléments.

Quel solution vous semble la mieux ou y a t'il une autre approche possible (par exemple par le dataset ?), merci à vous pour vos avis.

tout cela est bien compliqué pourquoi ne pas simplement y placer les trois fonctions
ça prends pas plus de temps c'est lisible et ça ne demande pas du code à côté pour interpréter les attributs

Code:

1
2
3
Div.onmousemove = function() {if (true) getElementById('DIV_LEFT').style.BackgroundColor="#F0F0F0";};
Div.onmouseout  = function() {if (true) getElementById('DIV_LEFT').style.BackgroundColor="#FFFFF0";};
Div.onmousedown = function() {if (true) getElementById('DIV_LEFT').style.BackgroundColor="#0F0F0F";};

sinon simplement utiliser les membres des éléments

Code:

1
2
3
4
5
Div.events = [
  {event : "mouseMove", cond: true, divId: 'DIV_LEFT' , BackgroundColor :'F0F0F0'},
  {event : "mouseOut",  cond: true, divId: 'DIV_LEFT' , BackgroundColor :'FFFFF0'},
  {event : "mouseDown", cond: true, divId: 'DIV_LEFT' , BackgroundColor :'0F0F0F'}
];

tu y as accès avec

Code:

console.log(Div.events[0].event);

si tu tiens absolument à un attribut

Code:

1
2
3
4
5
Div.dataset.events = JSON.stringify([
  {event : "mouseMove", cond: true, divId: 'DIV_LEFT' , BackgroundColor :'F0F0F0'},
  {event : "mouseOut",  cond: true, divId: 'DIV_LEFT' , BackgroundColor :'FFFFF0'},
  {event : "mouseDown", cond: true, divId: 'DIV_LEFT' , BackgroundColor :'0F0F0F'}
]);

accès avec

Code:

1
2
var events = JSON.parse(Div.dataset.events);
console.log(events[0].divId);

A+JYT

18/07/2016, 21h05
Coocky10

Merci pour ces réponses.

Du côté des fonctions je ne suis pas chaud, car c'était juste un exemple il faudrait adapter mes fonctions pour tout les cas, et je ne tiens pas à créer une fonction pour chaque type d'événements non plus.

Par contre l'utilisation des membres des éléments tel que tu le présente me plais bien je ne savais pas qu'on pouvait faire ainsi, je vais le tester car cela correspond pleinement à ma vision de ce que je souhaite faire.

Merci encore.
18/07/2016, 21h20
SylvainPV

Citation:

Envoyé par Coocky10

je ne tiens pas à créer une fonction pour chaque type d'événements non plus.

C'est précisément le but d'une fonction que d'éviter ce genre de répétitions. En JavaScript, une fonction est une variable comme une autre, on peut la passer en argument de plusieurs event listeners et on peut créer des fonctions à la demande si nécessaire. Crois-en mon expérience, une bonne décomposition fonctionnelle est la solution à 99% des problèmes, et bien moins hasardeux que cette collection d'objets arbitraires censés représenter la logique applicative.

Pour ce qui est de stocker des informations sur des éléments, une combinaison de classes sur tes éléments HTML devrait suffire à décrire leur comportement respectif. Une fois identifiables et identifiés, ils n'ont pas pour vocation à stocker davantage d'informations, et encore moins des règles logiques.
18/07/2016, 21h28
sekaijin

Citation:

Envoyé par SylvainPV

C'est précisément le but d'une fonction que d'éviter ce genre de répétitions. En JavaScript, une fonction est une variable comme une autre, on peut la passer en argument de plusieurs event listeners et on peut créer des fonctions à la demande si nécessaire. Crois-en mon expérience, une bonne décomposition fonctionnelle est la solution à 99% des problèmes, et bien moins hasardeux que cette collection d'objets arbitraires censés représenter la logique applicative.

Pour ce qui est de stocker des informations sur des éléments, une combinaison de classes sur tes éléments HTML devrait suffire à décrire leur comportement respectif. Une fois identifiables et identifiés, ils n'ont pas pour vocation à stocker davantage d'informations, et encore moins des règles logiques.

+1
19/07/2016, 00h32
melka one
jour

il y a aussi l'attribut type de l'objet event qui renseigne su l’évènement déclencheur
Code:

1 2 3 4 function unefonction(evt){ alert(evt.type) }
19/07/2016, 16h21
Coocky10
Citation:

Envoyé par SylvainPV

C'est précisément le but d'une fonction que d'éviter ce genre de répétitions. En JavaScript, une fonction est une variable comme une autre, on peut la passer en argument de plusieurs event listeners et on peut créer des fonctions à la demande si nécessaire. Crois-en mon expérience, une bonne décomposition fonctionnelle est la solution à 99% des problèmes, et bien moins hasardeux que cette collection d'objets arbitraires censés représenter la logique applicative.

En fait je vais expliquer un peu plus en détail, tous mes événements sont gérer dans une seule fonction.
Code:

1 2 3 4 5 6 function Affect_Window() { window.addEventListener("click", SeqEvent); window.addEventListener("mouseover", SeqEvent); //etc sur tous les événements utiles à mon projet.
Code:

1 2 3 4 5 6 7 function SeqEvent(evt) { var _Target = evt.target; var _TypeEvt = evt.type; //etc..
Ainsi je récupère l'objet target si c'est un div je récupère les événements que j'ai liés ou stockés dans ce div (sujet de la discussion), si le type d'événement correspond je test ma condition et si cette condition est vrai j'exécute la ou les actions concernées.

Ainsi tous mes événements sont rattachés à chaque div sous forme de paramètres et je peut ainsi gérer une multitude d'action conditionnées et en fonction de tout type d'événement sans alourdir mon programme.

Code qui me parais assez simple à gérer, modulable et pas vraiment compliqué enfin pour moi.

De plus ces données d'événement viendront à terme d'une source extérieur, fichier XML ou base de données, d'ou le principe de paramètres associés à un objet DIV.
Toute le site sera gérer par une simple lecture d'une base de donnée ou d'un fichier XML et un code qui ne bougera pas.
19/07/2016, 19h05
SylvainPV

J'ai pas l'impression que ce soit une si bonne idée de faire une application dont les règles d'interaction seraient stockées dans une BDD. En fait je trouve ça même complètement barré. Mais bon, j'ignore ton besoin et après tout, tu fais ce que tu veux.

Par contre, si tu tiens à stocker les paramètres dans les éléments HTML eux-mêmes (je rappelle qu'ils ne sont pas faits pour ça), pourquoi utiliser des évènements délégués partout ? Le seul intérêt des évènements délégués est justement de se libérer des références aux éléments HTML, afin de ne pas réassigner manuellement les listeners.
19/07/2016, 19h29
Coocky10

Citation:

Envoyé par SylvainPV

J'ai pas l'impression que ce soit une si bonne idée de faire une application dont les règles d'interaction seraient stockées dans une BDD. En fait je trouve ça même complètement barré. Mais bon, j'ignore ton besoin et après tout, tu fais ce que tu veux.

En même temps tu n'explique pourquoi c'est complètement barré non plus. Donc je veux bien accepter les critiques argumentées surtout que mon projet n'est pas figé mais sinon je vois pas ce que je peux faire de ton point de vue, actuellement les règles d'interaction sont stockées dans une variable objet dans un fichier js à part et ca marche très bien, je penses faire des tests avec un fichier XML puis un base de données, ma seule inquiétude est le temps de lecture des informations, mais je ne penses pas avoir énormément d'informations a y stocker donc à voir.

Citation:

Envoyé par SylvainPV

Par contre, si tu tiens à stocker les paramètres dans les éléments HTML eux-mêmes (je rappelle qu'ils ne sont pas faits pour ça), pourquoi utiliser des évènements délégués partout ? Le seul intérêt des évènements délégués est justement de se libérer des références aux éléments HTML, afin de ne pas réassigner manuellement les listeners.

Suivant les conseils de sekaijin je suis passé par l'utilisation des membres des éléments ce qui me convient très bien et fonctionne aussi parfaitement.
J'avoue ne pas trop comprendre ton principe d'événement délégués, et je ne réassigne pas manuellement les listeners puis qu'ils sont définit une fois pour toute dans ma fonction Affect_Window.
19/07/2016, 20h23
SylvainPV

http://javascript.developpez.com/act...en-JavaScript/

Justement parce que tu poses les event listeners sur window, tu fais du délégué (et même du ultra-délégué, vu que c'est la dernière étape de propagation) donc pas besoin de références aux élements. Mais d'un autre côté tu utilises les références pour stocker tes attributs, donc les références, tu les as. Je ne vois pas pourquoi alors poser les listeners sur window et tester la target, si ce n'est perdre en performances et complexifier le code.

Pourquoi mettre des règles de logique ou d'interaction dans une BDD est une bien drôle d'idée ? Ben déjà parce que ça s'appelle une base de données, donc prévu pour stocker des données et pas les règles logiques qui viennent manipuler ces données. Le seul moyen de sérialiser des fonctions est de passer par de l'évaluation dynamique, ce qui soulève de grosses problématiques de sécurité. C'est pour ça que tu as choisi une autre option qui est de ne pas stocker de fonctions, mais un objet arbitraire de configuration servant à générer une fonction comme un texte à trou. Mais ce texte à trou sera forcément toujours moins flexible que d'écrire directement les fonctions dans le code avec le paramétrage adéquat. C'est donc moins flexible, plus complexe à coder, plus lent à cause des requêtes BDD, moins prévisible, bien plus délicat voire impossible à tester, ça ne permet pas de varier le code selon l'user agent, ça empêche le fonctionnement en cache ou en hors-ligne... bref pourquoi partir sur quelque-chose d'aussi ésotérique et pénalisant ?

Explique-nous plutôt ton besoin final, je suis sûr qu'il y a une solution bien plus simple et directe.
19/07/2016, 21h37
Coocky10

Oui il me parait plus simple de gérer les déclencheurs d'événement une seule fois sur windows, inutile de créer des listeners pour chaque div ca me parait plus lourd puisque l'on peut récupérer le target de l'élément déclencheur.

D'un autre côté chacun de mes div auront bien des actions différentes en fonction de l'événement détecter, par exemple mon DIV1 cachera mon DIV3 si je clique dessus, et mon DIV2 changera de couleur de fond du DIV1 si je clique dessus etc...
Donc on a pas le choix les actions sont forcément liés aux DIVs.

Franchement niveau code c'est très loin d'être complexe, pour les performances est ce que créer plusieurs listeners pour chaques DIV ne va pas justement alourdir les performances ? moi j'ai le sentiment que si.

Une base de donnée est prévu pour stocker des données, donc n'importe qu'elle type de données, on sait très bien que les données d'une BDD lues par un programme vont d'une façon certaine interagir sur le comportement du programme en lui même, alors pourquoi pas y stocker des règles de logiques, ce n'est pas si ésotérique que cela.

Plus lent surement j'ai déjà envisager ce problème c'est pour cela que je vais tester la version XML qui est intéressante je compte juste tester pour la voir et je prendrait une décision après, je n'ai pas encore statué la dessus de toute façon mais c'est juste l'idée qui plait et puis avec la fibre ce qui est lent aujourd'hui ne le sera peut être plus demain.

Pour ce qui est de flexibilité, tu as raison je te l'accorde sans problème mais qui dit plus de flexibilité dit aussi plus complexe, et du coup pour ce qui est de la complexité du code je regrette mais je ne suis pas d'accord du tout avec toi, encore une fois mon code est très basique et cela fonctionne parfaitement de plus une fois le code créer je n'y touche plus puisque toutes les interactions passeront par un simple paramétrage et c'est tout l'intérêt de mon projet avoir des fonctions basiques tout en essayant de garder un maximum de possibilité et de flexibilité (c'est bien le lot de tout programmeur de jongler entre la puissance de son programme et sa complexité).

Après je vois pas pourquoi ca serait moins prévisible et plus difficile à tester, jusqu'à maintenant je m'en sort très bien sur ces deux points.

Enfin varier le code suivant l'agent, inutile puisqu'on peut varier le paramétrage suivant l'agent :), pour le hors ligne oui forcément mais de toute façon en hors ligne on est vite limité non ?
19/07/2016, 23h30
SylvainPV

Citation:

Envoyé par Coocky10

on sait très bien que les données d'une BDD lues par un programme vont d'une façon certaine interagir sur le comportement du programme en lui même

Ben, justement non ! Si c'est le cas, je considère ça comme un bug. Les données sont les données, elles ne changent pas le comportement d'une application.

Citation:

Envoyé par Coocky10

pour les performances est ce que créer plusieurs listeners pour chaques DIV ne va pas justement alourdir les performances ? moi j'ai le sentiment que si.

Plus qu'un sentiment, fais l'essai :) Multiplier les listeners c'est juste quelques Ko de RAM occupée en plus, ça n'a pas d'importance tant qu'on évite les fuites mémoire. Ce qui va pénaliser les performances c'est le nombre de fois où le callback des event listeners va être déclenché. Et window est le niveau racine, donc l'endroit où vont circuler le plus d'évènements (surtout si tu écoutes des choses comme mouseover ou mousemove). Seule une minorité de ces évènements seront vraiment utiles à traiter, donc gâchis de perf. La bonne pratique est donc de positionner les event listeners le plus bas possible dans le DOM. C'est pour ça que même quand on fait de la délégation d'évènements, on va généralement positionner les listeners sur l'élément parent commun aux élements ciblés, et pas sur document ou window.

Citation:

Envoyé par Coocky10

Enfin varier le code suivant l'agent, inutile puisqu'on peut varier le paramétrage suivant l'agent :)

Argh ! Et une entrée BDD par user agent existant donc ? Bon courage !

Bon je le répète, tu fais comme tu veux, mais ne compte pas sur moi pour t'aider à creuser ton trou ;)
20/07/2016, 00h29
Coocky10

Merci pour tes conseils SylvainPV.

J'ai bien pris note pour les listeners, je vais revoir ce point, ca ne devrait pas trop impacter mon programme de toute façon je créerais un listener en fonction de chaque events lié à une action à réalisé sur le DIV en question, on aura donc que des listeners utiles.

Pour la BDD par exemple si tu fait une requête SQL que tu souhaite afficher dans un tableau, si la requête n'obtient aucun résultat, il est inutile de créer le tableau en question, donc les données on un impact sur le comportement de ton programme c'est juste ce je voulais dire.

Pour les users Agent, évidement si tu à un code particulier en fonction de chaque agent c'est aussi pénible non ? en général ca ce gère par groupe, et tu gère généralement des droits.

Encore une fois c'est juste le principe de lire un site par une liste de paramètres, tout est gérable sous forme de paramètres et d'avoir aucun contenu de donnée dans le programme juste des fonctions auxquelles on transmet ces paramètres et qui exécute ce qu'elles ont à faire en fonction des paramètres transmis, ensuite que ces paramètres viennent d'un autre programme, d'un fichier XML ou d'une base de données c'est pas tellement important pour mon projet.
20/07/2016, 20h17
sekaijin

Je ne vois pas le rapport entre ne pas utiliser de fonction et utiliser un JS statique.

Tu as un js qui associe des data aux éléments. Pourquoi il ne peut pas associer une fonction ?

Que tu associe ta fonction ou pas aux éléments, elle reste définie qu'une fois.

A+
From smartphone.

Inutile de citer un message pour y répondre.

J'imagine que si tu en reparles c'est que tu penses que je n'utilise pas la bonne méthode alors voici la partie du code concerné.
Code:

1 2 3 4 5 6 7 8 9 10 function AjoutEvents(Div, ObjDiv) { for(var i in ObjDiv) { Div.Events.push(ObjDiv[i]); Div.addEventListener(Div.Events[i].Event, SeqEvent); } }
ou ObjDiv ressemble à cela.
Code:

1 2 3 4 5 ObjEvent = { "Event":"click", "Cond":"true", "Action":"Modif", "Affect":"TAB02.style.visibility.hidden"}, ObjEvent = { "Event":"click", "Cond":"true", "Action":"Modif", "Affect":"TAB01.style.visibility.visible"}, ObjEvent = { "Event":"click", "Cond":"true", "Action":"Modif", "Affect":"BTN01.style.backgroundColor.#FFFFFF"}, ObjEvent = { "Event":"click", "Cond":"true", "Action":"Modif", "Affect":"BTN02.style.backgroundColor.#000000"}
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 function SeqEvent(evt) { var _Target = evt.target; var _TypeEvt = evt.type; for(var x in _Target.Events) { if(_TypeEvt === _Target.Events[x].Event) { if(_Target.Events[x].Cond) { var TabParam = _Target.Events[x].Affect.split("."); var _Div = document.getElementById(TabParam[0]); Modif_Obj(_Div, TabParam[1], TabParam[2], TabParam[3]); } } } }
La fonction SeqEvent va évoluer en fonction de mes besoins, elle n'est pas optimisée non plus, pour l'instant je suis sur une autre partie de mon programme, mais il y aura une fonction pour le test de ma Condition qui sera plus évolué qu'un simple true ou false, et pour l'action actuellement j'ai juste testé la modification des éléments style d'un DIV mais il y aura aussi d'autre type d'action.

Si tu penses que cela peut être optimisé fait moi part de tes remarques merci.