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