Moreover, firebug magic should never be necessary just to read and understand the code!

We need to solve the connection problem in the code. See also Jamis Buck considerations about this: http://weblog.jamisbuck.org/2010/3/2/unobtrusive-yet-explicit

Ideally, Ctrl+B on the element in your favorit IDE should take you to where the relevant events are defined.

I know that the solution I proposed has maintenance problems, and I pointed that out in the article. Which is why I proposed a simpler comment to be added that wouldn’t require maintenance.

But I think you’re wrong when you say:

You shouldn’t ever need to know that. It should be transparent, irrelevant, a separate and self-contained layer, the functional layer.”

Separation of behaviour from markup is supposed to be for the purpose of maintainability. But if that separation causes maintenance problems, then it is for no purpose. I think we need to get away from the “trend” of separating our layers for separation’s sake, and start creating code that is maintainable.

But don’t get me wrong: I agree with most of what you’re saying; I just think there are some circumstances where complex JS code can be a little tricky to track down, and a solution like this could help at least a little bit.

But your “solution” here isn’t a good one.

<a href="#" id="myLink">click this link</a>
<!-- JS: scripts/link.js selector: myLink -->

The point of the way things are done now is to get the javascript references OUT of the HTML, to separate them and make them not dependent on each other. This improves manageability of BOTH the JS and the HTML. Either can be upgraded or revised without them being intertwined.

What you’re doing there is the worst of both worlds. You make your html require extra maintenence (say you move the javascript) and you make it obvious that “this HTML has javascript on it”. That should be the opposite of the point. You shouldn’t ever need to know that. It should be transparent, irrelevant, a separate and self-contained layer, the functional layer.

“…all event’s binded (sic) through jQuery, are actually stored in the
‘events’ portion of that elements data object.”

1. maybe this precludes a need for “firequery”?

2. I know jQuery is just one library of javascript functions – but it sure
is prevalent and in interesting, useful projects. So maybe this could help
clarify a narrow tree-branch on tracking of bound events?

3. Or am I off the mark – does this info not indicate the ultimate HTML
affected by the javascript?

thanks for your great info!

The only exception is dynamically-added event handlers (i.e. ones that aren’t always on), since it’s not appropriate to wire those up inside $(function () { … }). But in those cases, the elements are often themselves added dynamically, or if they’re not, then the event-adding process is so crucial to the page that it should be obvious enough to look for a function like ProcessCalendarActions() or the like.

Well, I guess this is certainly a much better way to track down events. Thanks a lot, Nick.

Notice in the upper right hand corner you can see the file name and line number. Clicking on it brings you directly to the handler.

I guess chrome 5 doesn’t yet have it, but if you want to give it a shot without upgrading, check out chrome canary:

http://googlesystem.blogspot.com/2010/07/google-chrome-canary-build.html

I’m using Chrome 5.x. Not sure if that would affect such a feature (maybe if it’s new?).

Can you send a screenshot?

That’s great, thanks for pointing out that feature in Chrome dev. That does work to some extent, but from my examination of it, it still doesn’t tell you what file the event is located in. So, it still requires some poking around.