5568 sujets

Sémantique web et HTML

évènements déclarés dans les pages HTML plutôt que dans le js

Bonjour à tous,

je travaille actuellement sur un gros projet, beaucoup de javascript et d'HTML écrit dans des pages jsp.

Je souhaiterai homogénéiser la déclaration des évènements sur mes éléments.

Je m'explique. L'existant veut qu'il y ait des évènements déclarés dans les balises HTML avec les attributs onclick, ...

En même temps, il existe aussi des évènements déclarés dans les js à l'aide de jQuery tel que:
$('#toto').bind('click',function(){ ... })


Il m'est arrivé de retrouver par ailleurs, des évènements déclarés à plusieurs endroits différents mais pour le même élément.

Par ailleurs quand on débug, il est compliqué de retrouver la fonction qui est appelée sur le click d'un élement s'il est déclaré en jQuery. Alors que défini dans la page html, on sait directement quelle fonction est appelée.

Du coup, je souhaiterai avoir votre avis, sur ce qui est pour vous le plus approprié et le plus clair. Si vous avez un retour d'expérience à ce sujet, je suis preneuse.

Bonne journée à tous.

Missa
Personnellement, je pense que les appels au fonctions doivent se faire dans le javascript lui-même, pour ne pas mélanger les langages et laisser le javascript dans un fichier javascript et parce qu'il me semble logique de séparer les choses qui n'ont pas la même action :
Le HTMl est là pour structurer et le javascript pour animer
Salut,

Même avis que Naemesis, dans l'absolut pour des questions de maintenance et de lisibilité, il vaut mieu tout séparer.

Ceci dit, il faut également voir le coté performance, si tu fait un .js pour un script qui fait 3 lignes, c'est négatif niveau performance ( même si l'impact est moindre )
Je suis d'accord sur le principe. je suis la première à dissocier la forme du fond.

Supprimer le style du html virer toutes les balises script que je peux trouver dans le html et les mettre dans une page js externe.

Mais là, c'est vraiment un choix particulier à faire. Je pense que les règles sont écrites pour nous guider mais des fois, le contexte nous impose de réécrire nos propres règles.
Je suis plutôt d'accord, j'ai assez tendance à déclarer mes événements dans le JavaScript, comme ça, tout est regroupé.

Si le code est propre, normalement, on s'y retrouve Smiley cligne

Et je me vois mal partir à la chasse aux "onclick" dans mon code HTML dans lequel je ne veux voir que du HTML ><
Peut-être n'ai je pas été assez claire sur l'envergure du projet.

J'ai énormément de pages jsp qui sont alimentées en JAVA plus d'une 60aine.

Ensuite plus d'une 20aine de fichier js, organiser en objet comme ci-dessous:
var test = {
     tata: null,
     toto: null, 
     function1: function(){
     },
     function2: function(){
     },
     ....
}


Du coup pour retrouver une déclaration d'évènements ce n'est pas très pratique.

L'application est très complète et très lourde. C'est l'équivalent d'un site grand public.
Modifié par missatorito (07 Jun 2012 - 09:24)
Dans ce cas créé un fichier JS qui regroupe tes assignations d'événements.

J'ai tendance a prioriser les choses de cette façon:

-Sécurité
-Maintenabilité
-Performance

Si pour des questions de maintenabilité du projet, tu doit sacrifier des performances (dans une mesure raisonnable) , il faut le faire, et la on parle pas de prendre 500 ms au chargement, juste une poignée...
Merci pour cette remarque mais là n'est pas la question. doit-on utiliser bind ou on.

Ma question est vraiment au niveau organisation d'un projet et de son javascript.

Si quelqu'un a un retour d'architecture du même genre de projet et qui a du faire un choix. je suis intéressée d'avoir son avis.
Hello.

Le choix est tout vu, tu vires tous les onclick et autres du HTML, et tu rend le tout générique via des classes / datas-attributes, avec tes déclaration dans un / plusieurs fichiers à part comme expliqué par JJK801.

Pour plus de souplesse, tu peux appeler un seul fichier main.js, qui lui chargera d'autres fichiers d'instanciation, selon un principe d'actions et de contrôleurs.
Bonjour,
missatorito a écrit :
Si quelqu'un a un retour d'architecture du même genre de projet et qui a du faire un choix. je suis intéressée d'avoir son avis.

Comme déjà dit plus haut, il est en général bien plus facile de maintenir du code d'interface Web si le code HTML est purgé de sa "décoration" CSS/JavaScript. Cela est d'autant plus vrai si le code est volumineux.

Mais le problème est évidemment un peu plus compliqué que cela. Quelques exemples :

- le on/bind n'est pris en compte qu'après qu'il a été exécuté (évidemment), là où l'attribut HTML correspondant est pris en compte dès la création de l'élément ciblé.
- Le on/bind peut s'appliquer à un ensemble assez conséquent d'éléments, là où l'attribut HTML correspondant doit être dupliqué.
- Plusieurs on/bind peuvent s'appliquer au même élément, là où on ne peut écrire qu'un attribut HTML par type d'événement.
- ...
missatorito a écrit :
Merci pour cette remarque mais là n'est pas la question. doit-on utiliser bind ou on.

Ma question est vraiment au niveau organisation d'un projet et de son javascript.

Si quelqu'un a un retour d'architecture du même genre de projet et qui a du faire un choix. je suis intéressée d'avoir son avis.


Je pense que toutes les personnes ici on déjà était confronté a ce genre de projet, et comme l'a dit Julien Royer:

Julien Royer a écrit :

Cela est d'autant plus vrai si le code est volumineux.


Ce a quoi je rajouterai que c'est quasi indispensable si tu travaille en équipe et que ton intégrité physique te tiens a cœur Smiley smile
Florian_R a écrit :
Pour plus de souplesse, tu peux appeler un seul fichier main.js, qui lui chargera d'autres fichiers d'instanciation, selon un principe d'actions et de contrôleurs.
Très intéressant cet article, merci beaucoup Oo
Modérateur
Je ne met jamais les évènements dans le html. Plus particulièrement dans une grosse application où le html, généré, va se retrouver découpé aux quatre vents.
De plus, des outils comme firebug permettent d'inspecter des éléments pour voir les events attachés.

Et n'oublions pas les déclarations d'events, comme je les faisais déjà avant jQuery:
a écrit :
document.getElementById('bidule').onclick = function() {
};

Avec les autres manières d'accéder à des éléments.

Si tu organises en objet, les évènements doivent être organisés selon la logique objet, et surtout ne pas mettre tous les évènements ensemble. L'objet est justement un moyen privilégié d'organiser de gros projets.
@kustolovic
kustolovic a écrit :
document.getElementById('bidule').onclick = function() {
};
Le onclick de la sorte est tout aussi diabolique que dans le HTML. Il écrasera tout précédent onclick déjà déclaré. Voir la doc de addEventListener.
Modérateur
ça a au moins le mérite d'être plus propre, mais c'est vrai que j'avais complètement oublié le addEventListener (trop de jQuery à outrance depuis un certain temps Smiley biggrin ) et que c'est vraiment beaucoup plus propre.
Modifié par kustolovic (07 Jun 2012 - 16:32)
Je vous remercie pour vos réponses. Je vais pouvoir m'en inspirer.

Du coup, à vos yeux, il est plus propre de faire:
addEventListener

plutôt que
$('##').bind('click',function(){})

ou 
$('##').on(...)


Utiliser jQuery mais avec parcimonie si je comprends bien.
Genre utiliser 
this.id

plutôt que 
$(this).attr('id')
Oula, non !

Pour la gestion des événements, il faut utiliser les fonctions de jQuery (ou autre bibliothèque) encore quelques années : addEventListener n'est pas supporté par les versions d'IE antérieures à la version 9, entre autres légers problèmes d'interopérabilité.
Modifié par Julien Royer (07 Jun 2012 - 17:28)
Sujet clos
Aller à