Mochikit.signal and DOM objects that don't exist yet (like jQuery.live)

[ryanw...@gmail.com]

Hi all,

I was playing around with MochiKit.Signal, specifically asking the
question: "Can I use MochiKit.Signal.connect to set event handlers for
objects that don't exist yet.

Like so:


// connect to our make a new button button
MochiKit.Signal.connect("button_that_exists", 'onclick',
function(evt ) {
var new_button = MochiKit.DOM.BUTTON({'id':
"newly_created_button"}, "Hello world, I'm new");

MochiKit.DOM.appendChildNodes( MochiKit.DOM.getElement("main_content_div"),
new_button );
});

MochiKit.Signal.connect("newly_created_button", 'onclick',
function(evt) {
alert("hey world");

});


NOTE that "newly_created_button" won't exist until the user clicks the
"button_that_exists".

When I try this I get an error in MochiKit.Signal, about src being
null.

Is this a bug ("MochiKit.Signal should allow connecting to DOM objects
that don't exist yet"), or a limitation of how MochiKit.Signal was
designed ("MochiKit.Signal.connect supports only objects that live on
the DOM when it is called")?

I do see that MochiKit.Signal.signal DOES seem to support the src
object being a string, so I suspect the former answer.

If it is the former answer (if this error is a bug) I can try to put
together a patch to try and allow this behavior, BUT I wanted to check
before I went down this road.

To see my full example, I've pushed it up to Bitbucket (as part of a
"learning" repository, so there's a lot of extra stuff in there :( ):
<http://bitbucket.org/rwilcox/learning_javascript/src/tip/MochiKit/
signals_and_slots/>

[Per Cederberg]

Thanks for your input to the project, but I don't think we can
consider this a bug. Referring to objects that do not yet exist is an
error in almost any programming language, so it is to be expected. The
MochiKit docs do not explicitly make it clear that the id lookup is
immediate, but they definitely do not discuss any lazy or delayed
lookup of the signal source. The documentation is explicit regarding
that the destination slot will be looked up on the first signal,
though.

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.

BTW. If you'd like to contribute patches to the MochiKit project, it
would be much easier if you forked the project on GitHub I think. The
move happened quite recently, so I haven't moved all my own patches
yet, but by forking on GitHub it becomes much easier for us
maintainers to pick up patches and ideas.

Cheers,

/Per

> --
> You received this message because you are subscribed to the Google Groups "MochiKit" group.
> To post to this group, send email to moch...@googlegroups.com.
> To unsubscribe from this group, send email to mochikit+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
>
>

[Bob Ippolito]

That said, I think jQuery Live style functionality is useful, and I
certainly wouldn't mind seeing some additional module to support it.
However, all existing MochiKit functionality works only on the current
state of the DOM and it is not a bug that it doesn't consider future
changes to the DOM that may match the id or selector given.

[ryanw...@gmail.com]

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

It seemed to me that MochiKit.Signal.connect might be a more
consistant way (aka: One Way To Do It) to do this, if the source
didn't have to exist at time of connect.

> BTW. If you'd like to contribute patches to the MochiKit project, it
> would be much easier if you forked the project on GitHub I think.

Thanks. I've seen mochikit on Github (and +2 for me: I've seen lots of
activity lately, I think partially due to the Github move)

Bob Ippolito said:

> That said, I think jQuery Live style functionality is useful, and I
> certainly wouldn't mind seeing some additional module to support it.

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 with some selector support from MochiKit.Selector might be get me
where I want to go.

Maybe I'll throw a few experiments together and push it to a GitHub
repo. (I'll let the list know)

Hope this helps,
_Ryan Wilcox

[Ryan Wilcox]

On Mon, Dec 6, 2010 at 4:54 AM, Masklinn <mask...@gmail.com> wrote:

>> 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?

Interesting. I'll take a look down this avenue too - thanks!
_Ryan Wilcox