[dojo-contributors] live() and delegate() prototype

Bill Keese bill at dojotoolkit.org
Thu Mar 4 20:23:50 EST 2010

OK, makes sense, I'll add it to my TODO list (unless someone else wants 
to do it first).

Even if live() doesn't go into 1.5 (seems unlikely it will), I'd really 
like to see dojo.trigger() checked in soon as it would (theoretically) 
let dijit redesign how the Button widget works, using a hidden <button> 
node, which would solve a bunch of IE rendering glitches.

I just realized that there's a public NodeList.filter(simpleFilter) 
method.  Maybe the first step is to enhance it (and related functions 
like orphan()) to handle any selector, rather than just simple 
selectors, but still fast-path the simple selectors.   I'll add that as 
a separate ticket.

James Burke wrote:
> If you want to proceed further with the prototype, I suggest putting
> it in dojox or dojoc and iterate from there, probably with an
> associated ticket. Hopefully you and Sam can compare notes on the
> implementation. Some hurdles to getting this further along:
> - there is a die() method, to remove a live connection.
> - IE has problems with select change events and some focus/blur
> things. From what I recall, jQuery ended up doing quite a few hacks to
> get that all to work right. To the point that I would probably be
> uncomfortable with that amount of hacking being injected into Dojo
> Base. Maybe this would never live in base (particularly with closest()
> dependency), but we have to decide on the tradeoff on full IE support
> vs. just doing something similar. My initial feeling is to just do a
> tidy implementation and just document the cases that do not work for
> IE.
> I like dojo(x).live(), and a .delegate method on dojo.NodeList, but
> hopefully we would have a .delegate that works outside the NodeList
> context. This is tricky on naming given the existence of
> dojo.delegate() for object delegation. I like how you did not put a
> .live() method on dojo.NodeList, as it is not a dojo.NodeList
> operation.
> To make this code fast, I support doing some fast pathing to
> _filterQueryResult where the selectors are simple ones that it
> supports for .closest() and/or its supporting infrastructure.
> James
> On Thu, Feb 25, 2010 at 11:19 PM, Bill Keese <bill at dojotoolkit.org> wrote:
>>> We have closest() in NodeList-traverse.
>> Ah, cool, I didn't realize that was there.
>> I checked over our closest() code, and ISTM the biggest issue is that
>> even for trivial filters, like closest("div"), it's calling dojo.query()
>> repeatedly, and dojo.query() is scanning the entire document.   That
>> problem can be lessened by modifying the closest()'s code to call
>> dojo._filterQueryResult() instead of self._filterQueryResult() when the
>> query is simple (presumably non-hierarchical).
>> Alternately, Sizzle.matches( String selector, Array<DOMElement> set ),
>> which is the same functionality as self._filterQueryResult(), already
>> has a fast path for simple selectors.   So that's another option.
>>> [jQuery] also has a $.live("a", "onclick", fn), much like our own pattern
>>> of node/nodelist.  IIRC, this is why delegate() was added, and $.live
>>> recommended (for the same lazy-nodelist reasons).
>> Ah OK, thanks.   I can't find any doc in http://api.jquery.com/live/ for
>> this a $.live("a", "onclick", fn) method signature, but it sounds the
>> same as:
>>    $("body").delegate("a", "onclick", fn)
>> Anyway, I've implemented prototypes of both a dojo.live() function and a
>> dojo.NodeList.delegate() method.   To monitor clicks on all <a> nodes in
>> the document you'd do:
>>    dojo.live("onclick", "a", function(){ ... })
>> And to only monitor clicks for <a> nodes inside of .navigation <div> nodes:
>>    dojo.query(".navigation").delegate("onclick", "a", fn)
>> See http://bill.dojotoolkit.org/trunk/dojo/tests/live.html and
>> http://bill.dojotoolkit.org/trunk/dojo/tests/delegate.html for the
>> prototype code I wrote.  I guess it's similar to Sam's code.  It doesn't
>> have the fancy caching that Dustin's code has.   Caching would be good
>> to add but I think the main thing is getting closest() to run in O(1)
>> time for simple selectors (and bonus points for getting it to run in
>> O(log N) time for complex selectors).   Note that my prototype doesn't
>> properly fix the closest() performance problem either.
>> _______________________________________________
>> dojo-contributors mailing list
>> dojo-contributors at mail.dojotoolkit.org
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

More information about the dojo-contributors mailing list