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 Flesler
http://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
-~----------~----~----~----~------~----~------~--~---
