TODO for 1.6 in source code

[anonymous]

Extrated from the 1.7rc1 source:

TODO: This is a hack for 1.5 ONLY. It will be removed in 1.6. Users should not attempt to inspect the internal events object using jQuery.data, as this internal data object is undocumented and subject to change. if ( name === "events" && !thisCache[name] ) {

return thisCache[ internalKey ] && thisCache[ internalKey ].events;

}

We're moving onto 1.7, so this should be fixed by now!

[ajpiano]

The comment needs to be removed or revised so that it is not woefully inaccurate and anachronistic.

[dmethvin]

Although the part about users inspecting event data is still true. Event-data-spying lurkers beware, you are still on death row, but the governor called and said you can have another day.

[gnarf]

TODO converted into ticket #10589

[Dave Methvin]

Fix #10588. For now, event voyeurism only merits the look of disapproval.

If you are using .data("events") we would like to know how we can provide a documented interface that satisfies the need.

Changeset: 24e416dca36df4b182a612dba37f8b6cdaa25916

[[email protected]…]

It seems to me the most common use case of inspecting the events object (apart from debugging perhaps) is the wish to reorder event execution order.

I wanted to do this for my current project, but got discouraged by the internalness of the component so in the end I wound up simply hardcoding my specific dependencies.

Somehow being able to either prioritize by number or bucket the sequence of events when you bind them would be very nice. Ideally I'd like to .bind("click", function()..., -1) to bind a handler that always got executed before other handlers or .bind("click", function()..., 1) for a handler that got executed after all other handlers. Naturally if the same priority number was used there'd be no guarantee for sequencing.

However the number of use cases are probably fairly low, so I can fully understand if you don't want to clutter the interface by supporting this.