On 2010-12-05, at 18:11 , ryanwil...@gmail.com wrote:
> On Dec 4, 5:58 am, Per Cederberg <p...@percederberg.net> wrote:
>> In your case, why wouldn't you just attach the signal when creating
>> the element? Otherwise you'd have to listen to any DOM modification
>> and possibly attach signals to elements added. And that use case
>> sounds pretty specific to me.
>
> In the simple case, yes, I could just add the event when I create the
> DOM elements.
>
> However, my current project (Ruby on Rails with jQuery) does a lot of
> AJAX calls to pull in new bits of HTML. If I want to register for
> events for those DOM elements, it's easy with jQuery.live.
>
> jQuery has two ways to register for events
>
> $("selector").event(function (){}...) <--- "selector" must exist
>
> and $("selector").live('event', function(){}...) <-- "selector" can
> exist in the future, doesn't have to now
>
You do realize .live is simply event delegation on document with filtering and
a bit of `this`-munging applied right?
Now of course Mochikit doesn't (as far as I know) have a cross-platform
matchesSelector, but if your "selector" is simple enough (classes, ids, element
names) it's trivial to handle event delegation with Mochikit.
> That's what I'm thinking, actually: some kind of
> MochiKit.BetterSignal.connect that :
>
> (Python looking pseudo code ahead)
>
> if src exists:
> MochiKit.Signal.connect(src....)
> else:
> # add it to some list of DOM elements we are waiting for, and when
> the DOM changes we look for it
That's not what .live() does at all. .live() does not look or wait for DOM
modifications.
--
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to mochi...@googlegroups.com.
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en.
