Major commit for jQuery.Event/jQuery.event.trigger with features, enhancements and bug fixes.
http://dev.jquery.com/changeset/6016 -- Ariel Flesler http://flesler.blogspot.com On Dec 29, 7:59 pm, Ariel Flesler <[email protected]> wrote: > jQuery.Event can be now instantiated without the 'new' operator, still > optional. > > http://dev.jquery.com/changeset/6008 > > -- > Ariel Fleslerhttp://flesler.blogspot.com > > On Dec 25, 7:59 pm, Ariel Flesler <[email protected]> wrote: > > > Ok, took me more than an hour but I finally updated the patch to fit > > all the new changes in the trunk (live,event bubbling,etc). > > > I added a 'currentTarget' attribute to the event object which reflects > > the actual element while bubbling, while 'target' keeps the original. > > I added the possibility to pass a literal object as THE event object > > ({type:'click',foo:'bar'}). It gets copied to a real one afterwards. > > > I think this is enough to satisfy John's request. One isn't FORCED to > > use the 'new' keyword. But it is possible. > > While it is nice to use jQuery without 'new'. One cannot extend it if > > desired. > > jQuery.Event can be surely extended, so I think hiding its OO source > > would just confuse someone trying to extend it. > > We could have a plugin that adds MouseEvent and KeyboardEvent, as an > > easy way to simulate those. > > > In addition, event objects have a 'stopImmediatePropagation' method to > > kill the following handlers. This was added some time ago. > > >http://dev.jquery.com/changeset/6005 > > > Cheers > > > -- > > Ariel Fleslerhttp://flesler.blogspot.com > > > On Dec 2, 12:18 pm, "Ariel Flesler" <[email protected]> wrote: > > > > Could do, I'll check this a little more in depth, later. > > > > Thanks > > > > On Tue, Dec 2, 2008 at 11:56 AM, Mark Gibson <[email protected]> wrote: > > > > > How about allowing passing of a plain object that is then copied into > > > > anEventobject: > > > > > $(...).trigger({type: 'change', customfield: 'something', target: > > > > myelement}); > > > > > $.fn.trigger = function(arg) { > > > > if (typeof arg === 'object') { > > > > ev = $.extend(new $.Event(), arg); > > > > } > > > > ... > > > > } > > > > And also detect whether the arg is actually an $.Eventobject first, > > > > and just use it as it comes. > > > > > On Dec 1, 11:35 pm, "Ariel Flesler" <[email protected]> wrote: > > > >> I think the only common use for the returned data fromeventhandlers > > > >> is the (get|set)Data events, which in my opinion, are already weird. > > > >> I think we should re-think some of these things. > > > > >> As for hiding the new from $.Event... hm... I really disagree. I don't > > > >> see why we should conceal OO. > > > >> I understand that (because of chaining) $('foo') is nicer than new > > > >> $('foo'). > > > > >> But not for theeventobject. It is an object and I see no need to > > > >> hide this. Just my opinion. > > > > >> On Mon, Dec 1, 2008 at 11:46 AM, John Resig <[email protected]> wrote: > > > > >> > This looks good - just one point that I wanted to mention: We really > > > >> > need a way to still get at the return values of the triggered > > > >> > callbacks. I agree with your decision to move to using the W3C-style > > > >> > of return values. Perhaps we could use a property like .returnValue > > > >> > to > > > >> > maintain the last return value from the functions. Or even something > > > >> > like .returnValues. > > > > >> > The reason why I bring this up is that it's becoming increasingly > > > >> > common for developers to use jQuery events as a way of doing custom > > > >> > events for communication and moving in this direction simply provides > > > >> > an extra level of indirection for them to dance through. > > > > >> > Even with my proposal in order to get the previously-available return > > > >> > value a developer would have to do: > > > >> > var evt = new jQuery.Event("something"); > > > >> > $(foo).trigger(evt); > > > >> > evt.returnValue > > > > >> > Which is very clumsy. I might be ok with a new method - something > > > >> > akin > > > >> > to .triggerHandler but with the addition of returning the > > > >> > returnValue. > > > > >> > Another point I want to mention: We're exposing jQuery.Eventfor > > > >> > developers to use but this is the first time that we've explicitly > > > >> > asked them to instantiate anything (new jQuery.Event). I'd like to > > > >> > request that the 'new' not be used - much in the same way that > > > >> > developers don't have to do 'new jQuery' (since we hide that away). > > > > >> > --John > > > > >> > On Mon, Dec 1, 2008 at 7:28 AM, Ariel Flesler <[email protected]> > > > >> > wrote: > > > > >> >> Anyone else that "concretely" agrees or disagrees with any of the 2 > > > >> >> mentioned tickets ? > > > > >> >> Thanks > > > > >> >> -- > > > >> >> Ariel Flesler > > > >> >>http://flesler.blogspot.com > > > > >> >> On Nov 29, 2:44 pm, Ariel Flesler <[email protected]> wrote: > > > >> >>> Addition: > > > > >> >>>http://dev.jquery.com/ticket/3665 > > > > >> >>> Feedback please. > > > > >> >>> -- > > > >> >>> Ariel Fleslerhttp://flesler.blogspot.com > > > > >> >>> On Nov 29, 1:22 pm, "Ariel Flesler" <[email protected]> wrote: > > > > >> >>> > @Scott > > > > >> >>> > Ok, that's an easy change (leave it or remove it). The question > > > >> >>> > is, > > > >> >>> > what's the formal application of this extra function ? > > > > >> >>> > @Diego > > > > >> >>> > We don't have the needed hacks to implementeventcapturing in IE > > > >> >>> > (I > > > >> >>> > know your NWEvents does). We don't plan to add that I think, that > > > >> >>> > requires a lot of hacking and not many would benefit from it. > > > >> >>> > So why add that parameter to our method ? > > > > >> >>> > I've been thinking about trying nativeeventtriggering instead of > > > >> >>> > what we have now. I showed that old experiment where I achieved > > > >> >>> > native > > > >> >>> >eventbubbling on all browsers, even for custom events. But that > > > >> >>> > required quite a large amount of code, maybe we can leave that > > > >> >>> > as a > > > >> >>> > plugin. > > > > >> >>> > About theeventproperties from the originalEvent... jQuery > > > >> >>> > "claims" > > > >> >>> > it normalizeseventobjects in a cross browser way (some > > > >> >>> > properties). > > > >> >>> > Telling the user "look for them on the original object" doesn't > > > >> >>> > seem > > > >> >>> > too nice for me. > > > > >> >>> > Thanks both for replying. > > > > >> >>> > Cheers > > > > >> >>> > On Sat, Nov 29, 2008 at 1:08 PM, Scott González > > > > >> >>> > <[email protected]> wrote: > > > > >> >>> > > jQuery UI uses the return value of triggerHandler, but we only > > > >> >>> > > care > > > >> >>> > > about false, so this change shouldn't affect us. > > > > >> >>> > > What's the logic behind removing theeventfrom the extra > > > >> >>> > > function? > > > >> >>> > > If I remember correctly, I talked to John about this a while > > > >> >>> > > ago and > > > >> >>> > > he couldn't think of any reason why that was done. I created > > > >> >>> > > a ticket > > > >> >>> > > to remove this behavior and it has just been sitting in Trac > > > >> >>> > > for 5 > > > >> >>> > > months (http://dev.jquery.com/ticket/3096). > > > > >> >>> > > On Nov 28, 7:14 pm, Ariel Flesler <[email protected]> wrote: > > > >> >>> > >> Feedback please! :) > > > > >> >>> > >> I really like (and support) this feature. > > > > >> >>> > >>http://dev.jquery.com/ticket/3662 > > > > >> >>> > >> Also... I know that the returned value from jQuery.fn.trigger > > > >> >>> > >> is used > > > >> >>> > >> here and there (jQuery UI?). But that behavior is really odd > > > >> >>> > >> and > > > >> >>> > >> fragile in my opinion (false overrides any previous value). > > > > >> >>> > >> I think it'd be nice to return true/false depending on whether > > > >> >>> > >> e.preventDefault() was called. This would be very useful for > > > >> >>> > >> custom > > > >> >>> > >> events, to alloweventhandlers to stop a scheduled (custom) > > > >> >>> > >> behavior. > > > > >> >>> > >> As an alternative, we could add e.isDefaultPrevented() that > > > >> >>> > >> retrieves > > > >> >>> > >> this value from theeventobject. > > > > >> >>> > >> Note that none of this last 2 behaviors (or the one in the > > > >> >>> > >> ticket) is > > > >> >>> > >> my invention. > > > >> >>> > >> I'm just imitating AS3'seventsystem. I suppose that belongs > > > >> >>> > >> to some > > > >> >>> > >> EcmaScript specification as well. > > > > >> >>> > >>http://docs.brajeshwar.com/as3/flash/events/Event.html > > > > >> >>> > >> Thanks > > > > >> >>> > >> -- > > > >> >>> > >> Ariel Fleslerhttp://flesler.blogspot.com > > > > >> >>> > -- > > > >> >>> > Ariel Fleslerhttp://flesler.blogspot.com > > > > >> -- > > > >> Ariel Fleslerhttp://flesler.blogspot.com > > > > -- > > > Ariel Fleslerhttp://flesler.blogspot.com > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
