Y a-t-il des cas où vous devez utiliser liaison précoce / attribut d'événement en ligne dans HTML / JavaScript

Question

Dans ma réponse à la question suivante SO: Qu'est-ce événement de liaison moyenne , je fait une remarque en passant que le? utilisation de ligne JavaScript / liaison précoce pour lier des événements JavaScript était « souvent erronée »

Par exemple:

<input id="MyButton" type="button" value="clickme" onlick="Somefunction()" />

Je discutais l'approche « liaison tardive » où il n'y a pas JavaScript référencé dans le balisage, que je crois être le plus pratique établie. Cependant, les commentateurs ont affirmé qu'il y avait des occasions qui ont nécessité son utilisation, et je me suis demandé ce que ceux-ci pourraient être.

Sans engager dans une discussion sur les mérites relatifs des deux, peut-on penser à toutes les circonstances qui exigent que vous utilisez le (par exemple) attribut onclick sur une approche liaison tardive.

Merci beaucoup

Answer 1

Je pense que beaucoup de développeurs feront ce soit en raison de l'ignorance ou le manque de connaissance (ce qui est, bien sûr, commun) et les développeurs restants vais le faire parce qu'il est tout simplement plus pratique d'utiliser des attributs HTML-JS que la liaison tardive, si vous savez que certains objets et fonctions sont toujours chargés sur chaque page et ils vont tout simplement « être là ».

Je pense que c'est en particulier true lorsque le HTML provient d'un rappel AJAX. Prenons un exemple où une demande d'AJAX revient avec une réponse HTML et que HTML est inséré dans la page. Maintenant, le développeur naïf penserait le long de ces lignes:

• Je ne sais pas quels sont les éléments à l'intérieur que le HTML de réponse, donc je ne sais pas ce que les liaisons en retard, je dois ajouter.
• Peut-être que je dois les ajouter au cas où! Ou écrire un script d'analyse qui détecte les éléments et se fixe à ceux que je trouve?
• Mais si je dois lier à quelque chose qui n'existe pas déjà? Le temps d'écrire une longue JavaScript en ligne!

Tout cela peut être éliminé en utilisant une sorte de omniprésente contraignant applicable à tous les courant et éléments à venir sur la page. En jQuery, l'équivalent est live() . Au lieu d'écrire:

$('.foo').click(function(){...});

Vous pouvez écrire:

$('.foo').live('click', function(){...});

Maintenant, tous les éléments avec un nom de classe « foo » exécutera la fonction lorsque vous cliquez dessus, y compris les éléments qui n'existent actuellement . Très utile pour les interfaces AJAX dynamiques.

Vous savez que déjà, mais je signale simplement que tout les attributs JS peut faire, JS pur peut faire mieux, et je considérerais que les meilleures pratiques.

Answer 2

commenters asserted that there were occasions that necessitated its use

I suppose I'm one of those commentors. What I actually said was that inline listeners "are a reasonable option in certain circumstances". I don't think there are any cases where it is "necessitated" (which I understand in this context to mean required).

Adding inline listeners is simply applying the same logic on the server to add listeners as would be applied on the client and has advantages in that:

1. Markup can be created and cached or used as static pages, listeners aren't added by every client over and over again when pages are downloaded
2. Issues related to delay between the element being available and the listener being added by DOMReady or onload functions or "bottom scripts" are completely removed
3. The vagaries of various "cross browser" DOMReady functions with onload fallback are removed - there is no opportunity for such functions to fail to add listeners if they aren't used

Of course this doesn't mean that all listeners should be added inline and that dynamic addition of listeners is rubbish, I'm just point out that it is a viable method that solves certain issues and is a perfectly reasonable solution in many cases.

If you believe "early binding" of listeners is good, then make it as early as possible - put them inline. :-)

PS. I also think I said I didn't like the use of "binding" in this context as listeners aren't bound to elements in any real sense. They are simply functions that are called when an element receives a related event. The only type of binding is that the listener's this keyword may be set to reference the related element (which is consistent in all browsers for inline listeners but not necessarily for those added later).

Answer 3

Reasons why onclick attributes are bad :

onclick="foo()"

• Your passing in a string of code that get's evalled at runtime when the element is clicked. This is inefficient and uses the horrors of eval
• Your forced to store the function foo in global scope thus polluting global scope with all your event handling logic.