Ariel, Perhaps I am just polluting the plugin universe with duplicate features, but part of the reason I created another plugin is because I learn by coding. When you have an idea, do you prefer to write it out yourself, or tell someone else to write it for you? I guess it depends on the idea, but I wanted to try this one myself.
Matt, I did not see that thread from the other list before. The ways that this is different from other plugins centers around attempting to make this more closely match the features available with "bind"... - the ability to bind "data" with a delegate handler - the ability to bind multiple handlers to the same selector - the ability to bind multiple events and multiple selectors to the same handler - the ability to stop the artificial propagation of delegates - the ability to selectively remove selectors, events, or everything Diego, I have not had a chance to look at your code, but it seems like you and Matt and many more people really want to use complex descendant selectors. Ariels "intercept" plugin acheives this through the use of a document wide query through a new jquery object, and it sounds like Matt's theory is of a similar vein. I am very skeptical of the possible pitfalls that could create for many developers... So I wrote a new "is" method that correctly handles complex hierarchical selectors. Using this new method in conjunction with a rewrite to "jQuery.multiFilter" allows the correct usage of complex selectors in any method that uses "multiFilter": filter not parent parents next prev nextAll prevAll siblings children contents I will include the "is" rewrite in the next plugin release, and have already proposed it as a patch that will hopefully get applied to the core. http://dev.jquery.com/attachment/ticket/3137/multiFilter_patch.js and related bugs... http://dev.jquery.com/ticket/2266 http://dev.jquery.com/ticket/2851 http://dev.jquery.com/ticket/3316 http://dev.jquery.com/ticket/3430 On Oct 11, 1:55 pm, Diego Perini <[EMAIL PROTECTED]> wrote: > Mike, > what I normally need is let the CSS selector specify on what elements > I want lo listen for event and not have that embedded by default > (forced) in the plugins or core. > > For example I prefer to be able to fully use and specify CSS selector > like these in the delegation method: > > '#nav' listening on one element in the page > '#nav *' listening on elements children of #nav > '#nav, #nav *' listening on #nav itself and all of its children > > so the developer can decide on which elements to fire only through > specific CSS selectors. > > For simpler tasks the .is() will be enough for most needs, for the > above, I believe we will need find() or something still more powerful. > > Having the choice to delegate events for "not yet rendered" elements > will greatly improve the "early page enlivenment" capabilities of > jQuery. > > The NWEvents code above is doing that, and is emulating the bubbling > for those events that do not bubble which makes it a bit more generic. > > In my simple tests I can perfectly handle also mouseover/mouseout and > mousemove event delegation, if handlers yield enough time for > that. :-) > > It would be nice if you could have a look at it and adjust current > proposal for jQuery delegation if deemed adequate. > > Please tell if my needs are so different... > > -- > Diego > > On 10 Ott, 19:09, "mike.helgeson" <[EMAIL PROTECTED]> wrote: > > > So I put out a plugin today to acheive all of the goals stated > > previously: > > > - Data, event data as is currently supported in the event system > > - Bubbling, starting with event.target, and traversing up the parent > > tree to match the delegate selector > > - Canceling default event behavior, parent tree-walking, other > > delegate handlers on the same element > > - Intelligent Removal, being able to remove all delegates, remove > > delegates by event type (or namespace), event type and selector (and > > sometimes handler) > > > Please take a look and discuss how to best implement delegation in the > > core. There are a lot of plugins out there which solve the same > > problem. Ariel has "listen" and "intercept", Jorn has "delegate" in > > his "validation," plugin to name a few... perhaps the best features of > > each should be considered. > > >http://plugins.jquery.com/project/delegatehttp://blog.threedubmedia.c... > > > On Aug 25, 10:51 am, "mike.helgeson" <[EMAIL PROTECTED]> wrote: > > > > Event delegation is on the roadmap for 1.3 > > > >http://docs.jquery.com/JQuery_1.3_Roadmap > > > > My question is: Who is taking the lead on this particular task? > > > I have some thoughts and solutions for event delegation that are a > > > little more robust than Joern's delegate plugin. For the solution that > > > makes it into the core, I would expect to see the following features > > > and functionality for event delegation: > > > > - Data, event data as is currently supported in the event system > > > - Bubbling, starting with event.target, and traversing up the parent > > > tree to match the delegate selector > > > - Canceling default event behavior, parent tree-walking, other > > > delegate handlers on the same element > > > - Intelligent Removal, being able to remove all delegates, remove > > > delegates by event type (or namespace), event type and selector (and > > > sometimes handler) > > > > I have some code I can share with anyone who is interested, it is a > > > first pass at all of these features. I would also like to know the > > > thoughts and expectations of other developers who have ever used event > > > delegation, especially around cancellation. > > > > -mike --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
