Comments on: Events: they’re not just for the DOM, you know

By: Mike Rumble

Mike Rumble — Mon, 22 Feb 2010 19:30:05 +0000

@Tobie, thanks for the info – wasn’t so much referring to the implementation details, but more to the fact that the API exposed by Prototype, by default only allows custom events on DOM elements.

The approach of using the ‘document’ is a neat one, and I’ve seen a mixin you created a while back (http://gist.github.com/204012) that does just that. Would love to have this kind of functionality rolled in to Prototype’s core.

By: James Coglan

James Coglan — Mon, 22 Feb 2010 11:31:13 +0000

Thanks for the reminder about Dean’s article, it’s definitely worth a read. I may amend the first article I’ve drafted to cover robustness, or leave concerns like that for a final round-up piece on the all the patterns I’ll cover. I want to keep the initial implementation examples really simple to communicate the basic ideas in a fairly language-neutral way.

By: Tobie Langel

Tobie Langel — Mon, 22 Feb 2010 11:00:21 +0000

Great article, James.

Mike, for the record, any true event handling system written in JavaScript will need to rely on host objects for error handling (you don’t want an error thrown by an event handler to stop the event being dispatched to the other event handlers). Dean Edwards wrote a great article on the subject a while back: http://dean.edwards.name/weblog/2009/03/callbacks-vs-events/

Prototype’s event model uses the DOM, other systems will rely on `setTimeout` to call handlers. Either way, you’re bound to the browser environment.

That said, if you consider the `document` object as as the broker in a publisher/subscriber pattern, you can very well use Prototype’s custom event system outside of the DOM.

By: Mike Rumble

Mike Rumble — Sun, 21 Feb 2010 23:33:09 +0000

Great article.

I use Prototype a fair bit, which suffers from the same limitations – you can subscribe to, and fire “custom” events, but only on DOM elements.

Can’t wait to read the rest in your series!