> Okay, I believe I've addressed the performance issues of jQuery.event.fix
> and jQuery.event.trigger. Both run much faster now. I've tested the new code
> against the test suite, several plugins and the UI project. It seems to be
> working great but I'm sure I still missed something.
>
> --
> Brandon Aaron
>
> On Sat, Apr 26, 2008 at 4:08 AM, Diego A. <diego.a...@...> wrote:
>
> > Hi Diego,
>
> > I agree with everything you said, but the best way forward may be to
> > not have namspaced events, etc.
>
> > Your code for event handling works perfectly and follows W3C specs.
> > It's the jQuery plugins that have created this need for something that
> > does not follow W3C specs and I think the solution is to find another
> > way to do whatever it is they're trying to do. Some way that does not
> > happen within the event handling code. But that's just me thinking
> > away...
>
> > Let's hope future versions of jQuery (and plugins) find a way to ditch
> > this functionality...
>
> > Cheers,
> > Diego A.
>
> > On Apr 25, 6:12 pm, Diego Perini <diego.per...@...> wrote:
> > > Diego A.,
> > > thank you for finding this inconsistency about my patch for
> > > event.fix(),
>
> > > I didn't know much about namespaced event, after reading a bit those
> > > are "Custom Namespaced" events, as you said I don't know if there
> > > is a real need for that complexity and this is absolutely slowing
> > > down even real DOM0/DOM2 event processing.
>
> > > Anyway I will have a look at it and see if I can submit another
> > > version
> > > of the event.fix() patch that considers these capabilities too.
>
> > > In these days I was really thinking that all this work of re-creating
> > > events with loops to copy properties is really unnecessary, it
> > > would be enough to let plugins re-create events with standard
> > > DOM calls (createEvent/createEventObject) and passing them
> > > when triggering Custom/Namespaced/Special events.
>
> > > In this way we could really improve things in a drastic way.
>
> > > Probably something like an internal "createEvent" as suggested
> > > in my patch but instead of looping through all the properties and
> > > copying them just let the standard createEvent() methods do that.
>
> > > The "createEvent" would just be a cross-browser wrapper
> > > to createEvent() or createEventObject(). In this way the
> > > properties that were read-only will remain read-only and
> > > this will be as from the W3C specifications.
>
> > > In the current implementation it seems to me that the W3C
> > > specs have been completely forgotten and penalized in
> > > favor of personalized implementations for special events,
> > > custom events and namespaced events.
>
> > > I don't think this is correct, we should go back and try
> > > to rethink about it now while the changes are few and
> > > localized to just few plugins using it.
>
> > > As I said it is not a good moment for me now, but I will
> > > try to include a patch that resumes what I said above
> > > with a really small correction to Brandon special events.
>
> > > Diego Perini
>
> > > On 23 Apr, 12:54, "Diego A." <diego.a...@...> wrote:
>
> > > > Hi Diego, (hope you're still monitoring this thread)
>
> > > > I found a problem. jQuery.ui.slider does not work with your patch.
> > > > This is beyond my understand of jQuery's event handling, but I believe
> > > > the problem is happening because of lines like this:
>
> > > > $(element).bind("setData.slider", function(event, key, value){
>
> > > > I don't understand the purpose of the periods in the event ID and how
> > > > jQuery uses it, but it seems to be the cause of the problem in your
> > > > patch.
>
> > > > The question is, is this complex event handling actually necessary?
> > > > Any ideas?
>
> > > > Cheers,
> > > > Diego A.
>
> > > > On Apr 16, 2:07 pm, "Diego A." <diego.a...@...> wrote:
>
> > > > > Hi Diego,
>
> > > > > The fix works perfectly now. Massive improvement!
> > > > > I hope it makes its way into the next jQuery release...
>
> > > > > Thanks for all your work!
>
> > > > > Diego A.
>
> > > > > On Apr 13, 11:57 pm, Diego Perini <diego.per...@...> wrote:
>
> > > > > > Diego A.,
> > > > > > you are correct...I forgot the "special" "custom" event... :-)
>
> > > > > > There are probably a couple of ways to solve this long puzzle,
> > > > > > the first is easy and hope finally backward compatible with
> > > > > > existing code; remove the following conditional lines so
> > > > > > the contained block is always executed:
>
> > > > > >    // is it a custom event
> > > > > >    if ( !ev.initEvent ) {
> > > > > > ...
> > > > > >    }
>
> > > > > > Above code start around line 2220 in the patched jQuery source.
>
> > > > > > This will decrease a bit in performances for every other type of
> > > > > > event on every browser but IE (event properties are writable).
>
> > > > > > That code block is what makes the event object writable on other
> > > > > > browsers different from IE, the conditional around it was put in
> > > > > > place to only do this when dealing with custom events,
> > > > > > but special events are still another case (similar...).
>
> > > > > > I will do my best to setup a new patch with that correction.
>
> > > > > > I am currently closing a long waiting work and not too much
> > > > > > time left. Thank you for reviving this out of that long thread.
>
> > > > > > Diego Perini
>
> > > > > > On 12 Apr, 16:57, "Diego A." <diego.a...@...> wrote:
>
> > > > > > > Continued from:
> >http://groups.google.com/group/jquery-dev/browse_frm/thread/8cce225d1...
>
> > > > > > > Hi Diego (Perini),
>
> > > > > > > I've been away for a few days, and now I've tested the latest
> > version
> > > > > > > of your patch, I still get an error with the TreeView plugin. I
> > don't
> > > > > > > know if it's something the TreeView plugin.
>
> > > > > > > I've setup a test here:
> >http://www.fyneworks.com/jquery/event.fix/DiegoPerini/readOnlyProperty/
>
> > > > > > > The error messages are:
>
> > > > > > > (line 2315) setting a property that has only a getter
> > > > > > > [Break on this error] arguments[0].type = "mouseleave";
>
> > > > > > > (line 2293) setting a property that has only a getter
> > > > > > > [Break on this error] arguments[0].type = "mouseenter";
>
> > > > > > > As far as I can see, the problem originates from the use of the
> > .hover
> > > > > > > function, which in turn uses the special jQuery mouseenter /
> > > > > > > mouseleave events. I found some information about them here:
> >http://jquery.com/blog/2008/01/15/jquery-122-2nd-birthday-present/
>
> > > > > > > I hope this helps.
>
> > > > > > > Diego A.