I've been using requireJS for a couple of days and what i've seen so far makes me wanna use it on the long term.
The only problem i ran into was when using jQuery Plugins. Whenever a new dependency, which actually was a jQuery Plugin, was introduced on a page all subsequent scripts could use it too, no matter if they declared it or not. The problem is with the concept of plugins as they just apply to the global jQuery object. To omit this behavior i've been using sub() but it seems to be quite expensive: http://jsperf.com/jquery-sub
i think there's a bug in the trigger method of jQuery. If i use $(document).trigger('click') the event doesn't bubble up to window, if instead i use $('body').trigger('click') it bubbles up all the way (a event handler is registered in both cases).
The problem is in the trigger method itself, starting line 3196 in jQuery - 1.7.2:
// Only add window if we got to document (e.g., not plain obj or detached DOM)
I've been searching around the net and also on this forum for this topic. There're several post but none of them suffices my expectation. We're using a 3rd party framework which registers event handlers on various elements in the DOM, mostly directly on the element but possibly also on a container (not sure if that's the correct wording, i mean the enclosing element).
Only i wouldn't sort the events when inserting but rather when a event was triggered. As i already mentioned the event handler isn't always on the element itself and in case all click events should be prevented i need to ensure to catch them all. My idea was to overwrite the jQuery.event.handle method as i didn't expect jQuery to change it's code as it kinda breaks the idea of event bubbling. When i came back to look at the internals again i saw handle being deprecated and dispatch sorting the event handling not by priority but by the selector. As this itself breaks event bubbling in a way when i.e. having an a tag enclosed in a div and registering those 3 handlers:
When clicking on the a tag (without cancelling bubbling of course) the order the handler's would be called using the jQuery.event.dispatch method would be:
Handler2 Handler3 Handler1
I'd say it's arguable if the event order should be the way it is or if the selector of the on method should be taken into account a bit more, as the selector is more specific i'd want the order to be:
Handler2 Handler1 Handler3
Anyways, what i was thinking about was to extend the on method with a priority parameter just like in the post linked above but only sort the event order when this kind of event actually fired. I'd wrap the whole chain, when the event bubbled up all the way i'd resort the handlers and then actually call them based on their priority. Some more thought has to be put into this as how to prevent resorting the order over and over even if nothing changed. How can it be accomplished not to sort events without a priority (meaning several handlers are registered in the chain but none of them care when it's running). How to know when bubbling is done, if no handler is registered on the top DOM element the jQuery.event.dispatch never gets called for this element and there's no way to find out if there're more handler in the chain, which is necessary to know as when all got called they need to be resorted and executed.
I think it would be very beneficial for jQuery to offer such functionality as there're plenty of requests and situations where it would make everybodies life easier. We've been dealing with Prototype and jQuery in the project for a long time, event handling is the main reason we finally fully switched over to jQuery as Prototype doesn't allow resorting at all (except unregistering all, inserting a new one and reregister the old ones).
Hoping for some input if there's a chance we see such a functionality cooked into jQuery or if we have to go down the lonely road and create our custom plugin?
we're using Tapestry for a big web application and are currently converting over to jQuery. Tapestry uses prototype but it's possible to eliminate that and replace it with prototype. Anyways, a lot of times we heavily rely on the order of the event handler being called. One example is if we open multiple modal dialogs, using the tab key we want to only focus on the elements of the foremost dialog. In prototype we simply unregistered available handlers, registered our new handler (as the first registered runs first), and reregistered the old handlers. Another example would be when we want to prevent clicking links, Tapestry registers a handle on each clickable/accessible elements and throws a custom event, to prevent anything from happening we also need to ensure the correct order. We never liked that solution but couldn't come up with any better one. With jQuery it's a bit easier as we can simply resort the data('events') array. Still, the solution doesn't really seem to be too elegant. Another problem i see coming is with delegate/on as the handler isn't necessarily registered on the element itself but somewhere above in the DOM hierarchy. Would be great if anyone could give me a hint on how to solve those problems. Except enforcing (asking) developers to only register the event handlers on certain elements (e.g.body) so we reliably can find them again i couldn't think of anything.