I took a few minutes to go back and look at this and realized that of
course the test suite fails. I have changed the expected behavior off
of which the tests are based. The new code allows "live" events to
bubble (which in my opinion is the correct behavior). In order to
cancel that behavior, the handler must return false.

For what it is worth, I added a "return false" to 3 of the first 4
live event handlers in the event live/die unit test, and everything
passes...

http://dev.helgeson.info/live/test/

On Feb 17, 11:20 am, John Resig <[email protected]> wrote:
> This is going to have to wait for 1.3.3 - 1.3.2 is already frozen and
> almost out the door.
>
> --John
>
> On Tue, Feb 17, 2009 at 11:19 AM, mike.helgeson <[email protected]> 
> wrote:
>
> > No it does not pass the test suite. I think the problem is from the
> > bubbling in "trigger"...
> > Any chance of getting this method added for 1.3.2? else, the
> > "liveConvert" function moved to the jQuery namespace?
>
> > jQuery.fn.delegate = function( type, selector, fn ){
> >   var proxy = jQuery.event.proxy( fn );
> >   proxy.guid += selector + type;
> >   return this.bind( liveConvert( type, selector ), selector, proxy );
> > };
>
> > I know it is great when things "just work" but this small change
> > allows developers in the know more control over the delegation
> > context, and not needing to execute a selector before setting up
> > delegation.
>
> > On Feb 17, 8:37 am, John Resig <[email protected]> wrote:
> >> Interesting work, Mike. I'll take a deeper look at it after 1.3.2
> >> lands. Out of curiosity - did you test this against the live tests in
> >> the jQuery test suite?
>
> >> --John
>
> >> On Mon, Feb 16, 2009 at 6:05 PM, mike.helgeson <[email protected]> 
> >> wrote:
>
> >> > - The selector must be run, before the event handler is bound... this
> >> > seems less than ideal, if a large number of DOM elements already exist
>
> >> > - Always binds/listens to the document. My biggest hesitation with
> >> > using live for delegation, is that there is no way to control the
> >> > listener, it is always the document. It should at least use the jquery
> >> > collection's context.
>
> >> > - Functionality is private... would like to expose the internal
> >> > functions "liveConvert" and "liveHandler" to enable a plugin to
> >> > leverage some of the features.
>
> >> > - Can't attach data to handlers the way you could using "bind"
>
> >> > - Events don't bubble correctly. Using the "closest" method seems like
> >> > the wrong solution here... I love the method, it is quite useful, but
> >> > in this case it causes elements to need to be sorted, and stops the
> >> > event from bubbling the way events should
>
> >> > - Events and handlers are not cancelable... because of the way the
> >> > liveHandler works.
>
> >> > For the benefit of those who have not looked at the code...
> >> > "liveHandler" goes through all of the stored "live" handlers/
> >> > selectors, checks each handler for a matching event.type, then takes
> >> > the event.target and searches for the closest selector match. (This
> >> > means starting with the given element and walking up the parent tree
> >> > and testing the selector against every element until a match is found,
> >> > and storing the number of "parents" away the match is made) Then
> >> > matched elements and the current handler are stored in a temp array.
> >> > Afterwards, "liveHandler" sorts by "closest" then iterates the temp
> >> > array to finally call each handler. This all makes terrific sense, but
> >> > the biggest drawback for me, is that each handler is only called on
> >> > the first matched element.
>
> >> > If I have nested divs, I would expect the "live" handler for "click"
> >> > on selector "div" to get called twice. This is (currently) not the
> >> > case. To try to work out some of these issues, I have created a plugin
> >> > to try to fix most of these issues. Here is what I tried to
> >> > accomplish:
>
> >> > 1) Exposes some of the private methods so that future plugins can
> >> > modify things a little more easily.
> >> > 2) Bind the event listener to the jQuery context instead of the
> >> > document. (I think there must be a larger issue at play here) This
> >> > also only seems to work, by setting the context with a raw DOM element
> >> > like: $( context ).find( selector ) or $('selector',context).
> >> > 3) "Better" bubbling/canceling... if a handler returns false, that
> >> > handler/selector stops. if event.stopImmediatePropagation() is called,
> >> > all handlers and selectors are stopped.
> >> > 4) Creating a new method for setting up delegation without calling the
> >> > selector... using "liveConvert"
> >> > $( context ).delegate( type, selectot, handler );
> >> > Not sure yet about data... anyway, here is some code I have been
> >> > working on and some very basic tests...
>
> >> >http://dev.helgeson.info/live/
> >> >http://dev.helgeson.info/live/$.live.js
>
> >> > I know that there is probably some issue with "position" selectors,
> >> > but I just want to try to improve this powerful feature...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to