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
-~----------~----~----~----~------~----~------~--~---

Reply via email to