On Mon, Jan 18, 2010 at 09:38, Andrew Dupont <goo...@andrewdupont.net>wrote:
> > But that brings me to the other problem: we'd be introducing a leaky > abstraction, perhaps our leakiest yet. Any script that didn't rely on > Prototype's custom methods for DOM manipulation wouldn't fire DOM mutation > events. This is a very important fact, because listening to DOM mutation events in my experience means that you want to catch an event when some code *other* than yours changes the DOM, and this code may be written in another js library (or no library at all), so there's a probability it won't use Prototype's DOM manipulation methods. I had great trouble on a project which used jQuery and "livequery" plugin (back when jQuery didn't have the `live` method). The livequery plugin attached events on all nodes matching a selector and hooked into jQuery's DOM manipulation to re-apply events on new nodes if something changed. Needless to say, this code was messy, not to mention the fact that the whole thing wouldn't work at all if you changed the DOM without jQuery. If I would want maximum security, I wouldn't rely on a framework — I would use native DOM mutation events. In browsers which don't support them I guess I would have to give up on that feature.
-- You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
