Porting JQuery's .live extension to prototype.

291 views
Skip to first unread message

Luisgo

unread,
May 27, 2009, 8:46:05 PM5/27/09
to Prototype: Core
I have thought about creating an extension for prototype to emulate
JQuery's ".live" behavior but, it not being available makes me think
that maybe it's not possible or worth the effort.

I know how to apply behaviors after changing the DOM but no one can
deny .live is very handy.

1. Any thoughts on this?
2. Has anyone tried to implement it?
3. Can I help?
4. How would you implement it?

I thought about extending both the selector (to keep an array of
executed queries/CSS selectors) and Ajax.Request but this would not
cover elements added dynamically that are NOT loaded through ajax.

Thanks

Josh Powell

unread,
May 27, 2009, 9:31:24 PM5/27/09
to Prototype: Core
$(document).observe('click', function (e) {
if (e.element().match('.test')) {
console.log('clicked');
}
});

Ok, that's not tested. The e.element() line is probably wrong, but it
accomplishes what .live() in jQuery does. You set an event handler on
the document, which all events filter up to, and then check to see if
the element that bubbled up the event matches your selector and
execute your code if it does.

Josh Powell

Samuel Lebeau

unread,
May 27, 2009, 10:40:08 PM5/27/09
to prototy...@googlegroups.com
Josh:
I believe the `e.element()` line should use `Event#findElement`
instead to walk the DOM tree up to find the first parent matching.

i.e.:
document.observe('click', function(e) {
if (e.findElement('.test')) {
console.log('clicked');
}
});

Luisgo:
I think it's definitely worth the effort, I've been personnally using
this pattern successfully in many applications.
In previous discussions, we ended up with the following signature:

`Element.delegate(@element, selector, eventName, callback)`

Then jQuery's `.live` query :

`$(selector).live(eventName, callback);

would become:

document.delegate(selector, eventName, callback);

IMO it should definitely be part of the framework.

Best,
Samuel.

Luisgo

unread,
May 27, 2009, 11:42:45 PM5/27/09
to Prototype: Core
That makes a lot of sense! All the while I've been thinking of
extending the library when delegation makes all the sense and is
probably going to perform better. Nice.

Now, wouldn't it make sense to put this under Event.delegatedObserver
(selector, eventName, handler) ?

I think using the word 'observer' in there would help make it's
purpose clearer and I put it under Event for consistency.

What do you think?

I'll look into creating the patch as soon as I have some time off and
sharing it here to get your input.

Thanks!

Luisgo

unread,
May 28, 2009, 1:49:21 AM5/28/09
to Prototype: Core
So... here's a first pass. I forked the project committed the changes
to my fork and sent a pull request to sstephenson for review. In the
mean time, you can take a look and give me your feedback here:
http://github.com/lgomez/prototype/commit/eb3fa460b2e850440b5aa89e5259c1afa7c04bfb

This is my first patch and contribution ever to an open source project
so please bare with me if you find some obvious mistakes. I also added
a first iteration of a functional test.

Thanks!

Tobie Langel

unread,
May 28, 2009, 3:10:06 AM5/28/09
to Prototype: Core
Hi,

You'll need to store the handler so you can remove it too, and provide
an adequate API for this.

Best,

Tobie

On May 28, 7:49 am, Luisgo <lgo...@gmail.com> wrote:
> So... here's a first pass. I forked the project committed the changes
> to my fork and sent a pull request to sstephenson for review. In the
> mean time, you can take a look and give me your feedback here:http://github.com/lgomez/prototype/commit/eb3fa460b2e850440b5aa89e525...

Luisgo

unread,
May 28, 2009, 3:15:48 AM5/28/09
to Prototype: Core
Cool.

Sorry for the questions but can you point me to an example of storing
a handler for removal and removing it and an explanation of what you
mean by adequate API?

I'll work on it, just need a little guidance.

Thanks!

Tobie Langel

unread,
May 28, 2009, 6:31:39 AM5/28/09
to Prototype: Core
You might want to have a look at the API and implementation of
Event.observe.

Best,

Tobie

Radoslav Stankov

unread,
May 28, 2009, 6:38:14 AM5/28/09
to Prototype: Core
In Prototype it will be Event.delegate -
https://prototype.lighthouseapp.com/projects/8886/tickets/435-eventdelegate-and-elementmethodsdelegate

I have been using for a while now and I it was working really well for
4-5 projects now

You can use Event.delegate from here: http://gist.github.com/66568
Or with my lib ControlDepo 3 Widgets -
http://github.com/RStankov/controldepo-3-widgets/blob/0e2cfcfa39aa301947fd4e078ceca888891b6161/src/extensions/event.js
(it work best with CD3.Behaviors
http://github.com/RStankov/controldepo-3-widgets/blob/0e2cfcfa39aa301947fd4e078ceca888891b6161/src/behaviors.js
)

It require the newest version of prototype, because of Element.Store

Radoslav Stankov

unread,
May 28, 2009, 6:42:45 AM5/28/09
to Prototype: Core
p.p. In several day I will make Event.delegate to be able to watch for
focus / blur / submit events ( and probably will try to make a good
patch for Prototype.js but the testing of this thing is really hard
for me )

Simon Charette

unread,
May 28, 2009, 11:06:23 AM5/28/09
to prototy...@googlegroups.com
I can help providing a cross platform test environement if you provide test cases.

2009/5/28 Radoslav Stankov <RSta...@gmail.com>

Radoslav Stankov

unread,
May 28, 2009, 12:57:22 PM5/28/09
to Prototype: Core
10x

I'm overloaded with work in the next couple of weeks, but maybe in
Sunday will have time to work on better tests on Event.delegate +
adding support for focus/blur
Reply all
Reply to author
Forward
0 new messages