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
> an Event object:
>
> $(...).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 $.Event object 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 from event handlers
>> 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 the event object. 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.Event for
>> > 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 implement event capturing 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 native event triggering instead of
>> >>> > what we have now. I showed that old experiment where I achieved native
>> >>> > event bubbling 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 the event properties from the originalEvent... jQuery "claims"
>> >>> > it normalizes event objects 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 the event from 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 allow event handlers to stop a scheduled (custom)
>> >>> > >> behavior.
>>
>> >>> > >> As an alternative, we could add e.isDefaultPrevented() that
>> >>> > >> retrieves
>> >>> > >> this value from the event object.
>>
>> >>> > >> Note that none of this last 2 behaviors (or the one in the ticket)
>> >>> > >> is
>> >>> > >> my invention.
>> >>> > >> I'm just imitating AS3's event system. 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 Flesler
http://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
-~----------~----~----~----~------~----~------~--~---
