Dean Edwards explains how the standard “callback” pattern in JavaScript is too brittle for something like a “DOM ready” event. Prototype appears to be the one major library that handles this “correctly.” WIN!
Dean Edwards explains how the standard “callback” pattern in JavaScript is too brittle for something like a “DOM ready” event. Prototype appears to be the one major library that handles this “correctly.” WIN!
Comments
Prototype handles this correctly you say? I admit I didn’t test Prototype. I’m off to try it. If you’re wrong I’m gonna call you out. ;-)
OK. You use timers. That’s OK for DOMContentLoaded (although not ideal). But for other custom events this won’t work very well.
It looks like you don’t support custom events at all. This should help.
Wait, what? We have supported custom events since 1.6. Here’s my demo page.
Can you show me an example that isn’t DOMContentLoaded? We already established that you support that with timers. Do you support any other custom events?
We “support” it with timers only in that we use the timer to know when to fire the custom event (and even then we only use the timer in Safari). I wrote about our custom events support a while back; you can also check out the API for Element#fire.
Actually, I just looked through your code and you are using a similar trick to me to fire custom events. The only difference is that you fire a “ondataavailable” event to wrap the custom event. I actually thought about that myself, it bubbles and you can use fireEvent in MSIE to fire it. I eventually decided against it just in case people were really using ondataavailable in their apps. So I went with onpropertychange instead.
So kudos. It seems that you have prior art. :-)
Heh, thanks. Credit there goes to Sam and Seth Dillingham. I can’t say for sure that they had this specifically in mind when they wrote it — looks more like a nice bonus.
We use
ondataavailablefor regular custom events; I endeavored to add support for non-bubbling custom events in the next version, but discovered we’d have to “borrow” an IE event that itself does not bubble. So we useonfilterchangefor that.If someone happens to be using either of these events in their apps outside of Prototype, that’s not a huge deal — we just check for our “fingerprints” on the event object and return early if it’s clear the event didn’t come from us.
I was more thinking of the other guy. ;-) If I attach an ondataavailable handler using plain JavaScript or some other library then Prototype’s event system might mess with it. I admit it is unlikely though. :-)
Andrew,
the “ondataavailable” choice is perfect, it can bubble too. My compliments to Prototype for being immune to this.
If a cancelable event is needed another option is the “onhelp” event, also filtering F1 would be needed to avoid shadowing browser native functionalities.
In my NWEvents project I prefer to use native methods to fire events also on IE, in the same way it is done for W3C browsers.
Nerds are talking, it’s better to listen and learn than speak something stupid, never mind, you guys just rock! cheers!!!