Dissocier le code javascript du code HTML avec Behaviour
Par NiKo le lundi 20 mars 2006, 22:32 - Dev
- Lien permanent -
15 commentaires -
Tags :
Dans un de mes précédents billets sur les effets javascript, je vous ai présenté moult exemples mélangeant allègrement syntaxe HTML et code javascript, notamment evênementiel. Programmer de cette façon n'est pas forcément la meilleure dans la mesure où elle rend difficile la séparation de ces deux langages, et donc de la maintenance des applications les utilisant.
Suite à un commentaire sur le billet en question, la librairie Behaviour s'est rappellée à mon bon souvenir et avérée tout à fait indiquée pour palier à cet épineux problème. Son utilisation est très simple et utilise la syntaxe CSS pour cibler les élements DOM auxquels appliquer certains comportements [1].
Ainsi, après avoir inclus la librairie dans votre page et au lieu d'écrire quelque chose du genre :
<a id="monlien" href="#ancre" onclick="new Effect.ScrollTo('ancre', .7);return false">Test</a>
... nous allons (enfin !) pouvoir dissocier la partie HTML de la partie javascript. Ainsi nous obtenons, pour le code HTML :
<a id="monlien" href="#ancre">Test</a>
Et pour la partie javascript, dans un fichier séparé :
var rules = { 'a#monlien' : function (element) { element.onclick = function() { new Effect.ScrollTo ( 'ancre', {duration: .7} ); return false; } } } Behaviour.register(rules);
Vous noterez qu'on cible directement notre lien par son identifiant DOM, (#monlien) - comme on le ferait dans une simple feuille de style CSS - et qu'on lui assigne une fonction javascript incluant les instructions que nous placions auparavant au sein de l'attribut onclick de la balise.
Vous allez me dire, quel interêt de remplacer un code simple et peu volumineux par cet amas de code javascript ? Par exemple, imaginons que nous voulons utiliser l'effet javascript ScrollTo sur tous les liens hypertextes contenant une référence à une ancre nommée de notre page... Notre règle comportementale devient tout simplement :
var rules = { // Liens et scrollTo automatiques sur tous les liens pointant // vers une ancre dans la page courante 'a' : function (element) { var pos = element.href.indexOf('#'); if (pos) { var target = element.href.substring(pos + 1, element.href.length); if ($(target)) { element.onclick = function() { new Effect.ScrollTo ( target, {duration: .5} ); return false; } } } } }; Behaviour.register(rules);
Voila, vous venez d'appliquer un comportement à tout un ensemble d'éléments [2] (toutes les balises <a /> du document), et ce sans avoir à modifier une ligne de votre code HTML.
Il est bien évidemment possible de chaîner les déclarations de comportements, de la manière suivante :
var rules = { 'a' : function (element) { }, 'p' : function (element) { }, 'li' : function (element) { } }; Behaviour.register(rules);
Mine de rien, nous venons de mettre en place une sorte de feuille de comportements, dissociée de la sémantique de la page et de ses règles de mise en forme. Les perspectives sont énormes mais c'est surtout en maintenabilité que les gains seront les plus substentiels, un argument de poids face à nos chers clients férus d'inflation du périmètre fonctionnel (copyright Glagla 2006) ![]()

15 commentaires (Ajouter un commentaire)
Merci beaucoup !
Je vais essayer d'ajouter ce bidule par petites touches quelque part où ça pourrait être utile.
C'est mon avis personnel, mais je trouve que c'est vraiment se compliquer la vie, en plus ça alourdit le tout. Je n'ai jamais eu besoin de Behaviour pour dissocier syntaxe javascript et code xhtml: pour retrouver un élement précis, je l'appelle par son id via
getElementById(). Quand il s'agit de toute une suite d'éléments, j'utilise legetElementsByTagNamede DOM, ou legetElementsByClassNamede Prototype (inspiré de dom).Évidemment, pour ces deux dernières fonctions les objets retournés sont stockés dans un tableau, donc c'est un peu relou, il faut le parcourir avec un
for()pour leur attribuer une fonction pour un évènement spécial à chaque fois, mais ça reste très lisible et surtout, c'est beaucoup plus léger.Autre chose: plutôt que de faire
element.onclick = function() { }, je te propose de jeter un coup d'oeil à la fonctionEvent.observe()de Prototype. C'est un peu plus pratique, mais aussi plus respectueux des standards.Enfin, ça n'est que mon humble avis...
Arf, tu as sans doute raison, il me reste tant à apprendre. Bonne soirée.
Euh... plus pratique peut-être pas. Je voulais dire "un peu moins pratique", mais plus respectueux des standards.
Vouélé.
Comme le dit Denis, il existe
Event.observedans prototype qui permet aussi de faire quelque chose de similaire. Mais Behaviour permet de faire les choses plus facilement qu'unelement.onclicknormal (si on a envie d'appliquer un effet surdiv>p blockquote>a:hover, sans Behaviour ou Prototype c'est un peu plus long à écrire ^^Un petit article sur Event.observe.
Wow ! merci pour le lien, monsieur N ! Je ne connaissais pas "each" et "item", la lib Prototype est décidement très puissante. L'exemple est également très convaincant.
Justement, sur le même site la personne viens de sortir un script qui peut remplacer Behaviour dans certains cas
Ah oui en effet, ça a l'air top... J'ai juste un doute sur la standard-compliance des termes
mouseover,loaded, etc...Sinon la meilleur intégration de prototype est un vrai plus.
> Arf, tu as sans doute raison, il me reste tant à apprendre. Bonne soirée.

Qu'elle belle façon de ne pas contredire
@Denis Hovart > Il y a deux écoles : "quick, dirty, up and working as fast as possible" et "design pattern inside" ... Les deux se valent ... c'est vrai que pour le Web le plus rapide c'est, le mieux c'est ... mais pour un vrai projet (j'entends un truc que tu dois maintenir sur le temps) plus tu fais d'abstraction et de généralisation de ce genre (ce qui implique de la complication et du ralentissement) mieux c'est !!! Après il faut trouver le juste milieux mais a savoir que pour un projet Web2.0 la maintenance Javascript est horrible, il vaut peut être mieux investir dans une bibliothèque comme celle la ou une autre tout de suite
@Niko > Merci pour cette biblio ... je trouve le concept super bien foutu et ça épargne un sacré paquet de boulot !!!
Oui, tu as sans doute raison. Je n'ai pas encore vraiment l'habitude des gros projets, jsuis juste un petit jeunot de 18 ans qui essaie de s'autoformer tant bien que mal. Si on met en pratique ce que j'ai dit plus tôt, c'est vrai que ça devient très vite assez crade.
Ce n'est pas moi qui vais vous apprendre quoi que ce soit ^^
vraiment interessant, je crois que je vais pas tarder à implémenter ca. surtout la fonction ScrollTo à l'air bien fun
eso mismo
:no:
je trouve ca un peu lent behaviour, personne ne rencontre de problèmes de performance avec ?
J'ai pas constaté ça... Mais je l'utilise pas sur des devs complexes et/ou à fortes charges...
Il y a aussi Event:Selector qui est plus leger et utilise bien prototype à tester : http://borkweb.com/story/oooo-eventselectors-for-prototype