Hi, You'll need to store the handler so you can remove it too, and provide an adequate API for this.
Best, Tobie On May 28, 7:49 am, Luisgo <lgo...@gmail.com> wrote: > So... here's a first pass. I forked the project committed the changes > to my fork and sent a pull request to sstephenson for review. In the > mean time, you can take a look and give me your feedback > here:http://github.com/lgomez/prototype/commit/eb3fa460b2e850440b5aa89e525... > > This is my first patch and contribution ever to an open source project > so please bare with me if you find some obvious mistakes. I also added > a first iteration of a functional test. > > Thanks! > > On May 27, 8:42 pm, Luisgo <lgo...@gmail.com> wrote: > > > That makes a lot of sense! All the while I've been thinking of > > extending the library when delegation makes all the sense and is > > probably going to perform better. Nice. > > > Now, wouldn't it make sense to put this under Event.delegatedObserver > > (selector, eventName, handler) ? > > > I think using the word 'observer' in there would help make it's > > purpose clearer and I put it under Event for consistency. > > > What do you think? > > > I'll look into creating the patch as soon as I have some time off and > > sharing it here to get your input. > > > Thanks! > > > On May 27, 7:40 pm, Samuel Lebeau <samuel.leb...@gmail.com> wrote: > > > > Josh: > > > I believe the `e.element()` line should use `Event#findElement` > > > instead to walk the DOM tree up to find the first parent matching. > > > > i.e.: > > > document.observe('click', function(e) { > > > if (e.findElement('.test')) { > > > console.log('clicked'); > > > } > > > }); > > > > Luisgo: > > > I think it's definitely worth the effort, I've been personnally using > > > this pattern successfully in many applications. > > > In previous discussions, we ended up with the following signature: > > > > `Element.delegate(@element, selector, eventName, callback)` > > > > Then jQuery's `.live` query : > > > > `$(selector).live(eventName, callback); > > > > would become: > > > > document.delegate(selector, eventName, callback); > > > > IMO it should definitely be part of the framework. > > > > Best, > > > Samuel. > > > > On 28 mai 09, at 03:31, Josh Powell wrote: > > > > > $(document).observe('click', function (e) { > > > > if (e.element().match('.test')) { > > > > console.log('clicked'); > > > > } > > > > }); > > > > > Ok, that's not tested. The e.element() line is probably wrong, but it > > > > accomplishes what .live() in jQuery does. You set an event handler on > > > > the document, which all events filter up to, and then check to see if > > > > the element that bubbled up the event matches your selector and > > > > execute your code if it does. > > > > > Josh Powell > > > > > On May 27, 5:46 pm, Luisgo <lgo...@gmail.com> wrote: > > > >> I have thought about creating an extension for prototype to emulate > > > >> JQuery's ".live" behavior but, it not being available makes me think > > > >> that maybe it's not possible or worth the effort. > > > > >> I know how to apply behaviors after changing the DOM but no one can > > > >> deny .live is very handy. > > > > >> 1. Any thoughts on this? > > > >> 2. Has anyone tried to implement it? > > > >> 3. Can I help? > > > >> 4. How would you implement it? > > > > >> I thought about extending both the selector (to keep an array of > > > >> executed queries/CSS selectors) and Ajax.Request but this would not > > > >> cover elements added dynamically that are NOT loaded through ajax. > > > > >> Thanks --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
