[Prototype-core] Re: Simple event delegation
@kangax,
have a look here:
http://javascript.nwbox.com/NWEvents/delegates.html
"focus/blur" events are simulated cross-browser but
transparently to the event setup by the programmer.
Of great note is that in the example no "onload/DOMReady"
event is used to bootstrap the functionality of the interface,
it just run as it loads, this is event delegation.
It uses a lengthy syntax that you surely don't like, but is very
compact and framework agnostic (so easy to port to your
preferred environment):
NW.appendDelegate(selector, event-type, handler, [delegate]);
NW.removeDelegate( ... , ... , ... );
But you are free to add your $ taste and extra saccharine.
In my code the "[delegated]" element is optional, in case you do not
specify the element the code will use the mighty "documentElement".
This is the HTML node which is omnipresent in all browsers, for sure
this also mostly avoid conflict with current work since nobody uses
it.
This was the result of this thread:
http://peter.michaux.ca/article/3752
The "submit" is a pain for me too, but a couple of "mouseup/keyup"
events will do the trick without patching the library just for an IE
bug.
Would be great if you can confirm that speed is not a problem with
my approach, I can use this fine with mouseover/mouseout, for
mousemove I would have to enable some caching methods
that are included in NWMatcher, the faster "match()" method
you could see around. Promised :-)
Diego Perini
On Feb 22, 8:32 pm, kangax <[EMAIL PROTECTED]> wrote:
> Protolicious is my personal repo for little snippets I use at work or
> play with : )
>
> You noticed right about main differences. My main concern was
> definitely a performance, therefore selector caching and plain loops.
> Another thing to note is that it accepts comma-separated selector
> expressions:
>
> Event.register('.confirmation abbr, .error abbr', 'click', showInfo);
>
> I'm not sure how important it is, but it also purges all the event
> handlers (attached internally) when page unloads.
>
> - kangax
>
> On Feb 22, 2:03 pm, Ken Snyder <[EMAIL PROTECTED]> wrote:
>
> > kangax wrote:
> > > Ken,
> > > take a look at my implementation [1] - it looks very much alike,
> > > except for the syntax : )
>
> > > [1]http://code.google.com/p/protolicious/source/browse/trunk/src/event.r...
>
> > > - kangax
>
> > Cool! So if I understand it correctly, register() has three differences
> > from mine:
> > - register() registers all rules to the document
> > - register() caches the Selector objects (cool!)
> > - register() requires attaching one selector-handler pair at a time
>
> > So what is this protolicious?
>
> > I couldn't find any event delegation scripts on scripteka... is your
> > script in protolicious only?
>
> > - Ken
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
Protolicious is my personal repo for little snippets I use at work or
play with : )
You noticed right about main differences. My main concern was
definitely a performance, therefore selector caching and plain loops.
Another thing to note is that it accepts comma-separated selector
expressions:
Event.register('.confirmation abbr, .error abbr', 'click', showInfo);
I'm not sure how important it is, but it also purges all the event
handlers (attached internally) when page unloads.
- kangax
On Feb 22, 2:03 pm, Ken Snyder <[EMAIL PROTECTED]> wrote:
> kangax wrote:
> > Ken,
> > take a look at my implementation [1] - it looks very much alike,
> > except for the syntax : )
>
> > [1]http://code.google.com/p/protolicious/source/browse/trunk/src/event.r...
>
> > - kangax
>
> Cool! So if I understand it correctly, register() has three differences
> from mine:
> - register() registers all rules to the document
> - register() caches the Selector objects (cool!)
> - register() requires attaching one selector-handler pair at a time
>
> So what is this protolicious?
>
> I couldn't find any event delegation scripts on scripteka... is your
> script in protolicious only?
>
> - Ken
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
kangax wrote: > Ken, > take a look at my implementation [1] - it looks very much alike, > except for the syntax : ) > > [1] > http://code.google.com/p/protolicious/source/browse/trunk/src/event.register.js > > - kangax > > Cool! So if I understand it correctly, register() has three differences from mine: - register() registers all rules to the document - register() caches the Selector objects (cool!) - register() requires attaching one selector-handler pair at a time So what is this protolicious? I couldn't find any event delegation scripts on scripteka... is your script in protolicious only? - Ken --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
Ken, take a look at my implementation [1] - it looks very much alike, except for the syntax : ) [1] http://code.google.com/p/protolicious/source/browse/trunk/src/event.register.js - kangax On Feb 22, 1:07 pm, Ken Snyder <[EMAIL PROTECTED]> wrote: > Based on this thread, I created flexible Event delegation functions for > attaching and removing delegation rules: > > http://kendsnyder.com/sandbox/delegate/http://scripteka.com/script/element-delegate > > - Ken Snyder --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
Based on this thread, I created flexible Event delegation functions for attaching and removing delegation rules: http://kendsnyder.com/sandbox/delegate/ http://scripteka.com/script/element-delegate - Ken Snyder --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
On Feb 8, 2008 9:19 PM, Nicolás Sanguinetti <[EMAIL PROTECTED]> wrote:
> I'd normally respond that since adding this feature is only 5 lines
> away,
On Feb 9, 2008 6:30 AM, kangax <[EMAIL PROTECTED]> wrote:
> The implementation is NOT as simple as it seems to be.
Teehee :) Ok, point taken. And yup, if it's something "big" it should
come up as a plugin *for now*, but my reasoning on why it should be in
core --encourage people to use this technique-- still stands. What do
the rest think?
Moving on, I'd like to argue on the api ^_^
> Event.register(selector, eventName, handler);
I assume that would catch events at the document level always. I kinda
liked Pat's idea of explicitly passing the element so you could scope
down the events--eg, only handle the events inside that table. Maybe
it's more trouble than it's worth, particularly with keyboard events,
and the performance gain is trivial enough, but I'm guessing that on
fairly complex DOMs it might not be that trivial. What do you think?
> Object.extend(document, {
> delegate: Event.delegate,
> delegators: Event.delegators
> })
Boo. Two different methods to do this? I'd rather let the delegate
method take variable arguments and decide over that, as many functions
in Proto do.
-Nicolas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
Wow, I didn't realize how much more complex this was. Thanks for the advice. On Feb 9, 3:30 am, kangax <[EMAIL PROTECTED]> wrote: > I've been working on a delegation plugin with syntax like this: > > Event.register(selector, eventName, handler); > > It supports multiple selectors (separated via comma) and an interface > to unregister events. > > The implementation is NOT as simple as it seems to be. Just to name a > few gotchas you stumble upon: > > 1) When event is caught by a top level element (document in my case), > its target property points to a down-most clicked element (which is a > standard bubble-mode behavior) - not only target but ALL the ancestors > should be matched against as well. > 2) Using selector matching is fine with events like "click" but is a > real blocker (speed-wise) when observing mouseover/mouseout (I had to > cache instantiated selectors to make it all faster). > 3) All this custom mess needs to be carefully cleaned up on page > unload (I'm talking about IE's wonderful GC). > > My point is that this is NOT something to be in a core (or at least > any time soon), but rather a good candidate for a standalone > extension. > I am planning to release this plugin, but wanted to write a nice > article accompanying it (since many people have never even heard of > event delegation) > > Best, > kangax --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
I've been working on a delegation plugin with syntax like this: Event.register(selector, eventName, handler); It supports multiple selectors (separated via comma) and an interface to unregister events. The implementation is NOT as simple as it seems to be. Just to name a few gotchas you stumble upon: 1) When event is caught by a top level element (document in my case), its target property points to a down-most clicked element (which is a standard bubble-mode behavior) - not only target but ALL the ancestors should be matched against as well. 2) Using selector matching is fine with events like "click" but is a real blocker (speed-wise) when observing mouseover/mouseout (I had to cache instantiated selectors to make it all faster). 3) All this custom mess needs to be carefully cleaned up on page unload (I'm talking about IE's wonderful GC). My point is that this is NOT something to be in a core (or at least any time soon), but rather a good candidate for a standalone extension. I am planning to release this plugin, but wanted to write a nice article accompanying it (since many people have never even heard of event delegation) Best, kangax --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
Ok, after working with the syntax I proposed above all day, I'm
inclined to believe a LowPro-esque helper might not be such a bad
thing. Here's the code I'm working with at this point:
Object.extend(Event, (function(){
return {
delegate: function(element, eventName, targetSelector, handler)
{
var element = $(element);
function createDelegation(_delegatedEvent) {
var origin = _delegatedEvent.element();
if ( origin.match(targetSelector) ){ return
handler(_delegatedEvent); }
};
element.observe(eventName, createDelegation);
return element;
},
delegators: function(element, eventName, rules) {
var element = $(element);
function delegateRule(rule) {
element.delegate(eventName, rule.key, rule.value)
}
$H(rules).each(delegateRule)
return element;
}
}
})())
Element.addMethods({
delegate: Event.delegate,
delegators: Event.delegators
})
Object.extend(document, {
delegate: Event.delegate,
delegators: Event.delegators
})
Event.delegate works in the same way as the syntax I proposed above.
Event.delegators (I'm not too keen on that name) works with the same
syntax that you proposed above. I've also added the the two methods to
document.
I'm also working on a way to simulate bubbling for events that don't
natively do so. For example, a form submission would fire the
'form:submitted' custom event. I add the original event that triggered
the custom event as an attribute of the custom event's memo object,
which gives me the liberty to halt the original event down the line if
I choose to do so like this:
event.memo['originalEvent'].stop();
I don't really think this sort of thing is fit for core, though it's
interesting, and it works very well with the Event delegation code I
proposed above.
On Feb 8, 6:44 pm, Pat Nakajima <[EMAIL PROTECTED]> wrote:
> That LowPro post was actually what sparked the idea for me. As for the
> syntax you proposed, I prefer my own (though I'm obviously biased),
> because I like how closely it matches Element.observe. This has a
> couple advantages. First, users will be more inclined to make use of
> it since the syntax will be familiar. Second, the current behavior of
> Event.observe specifies one behavior for one event name, on any number
> of elements (through the use of the following pattern:
>
> $$('.close').invoke('observe', 'click', Behaviors.close)
>
> I've been using Event.delegate as a replacement for this pattern, so
> rather than include a totally new paradigm (which is already provided
> through the LowPro library, which will probably have delegation
> support soon anyway), I think that "the Prototype way" would be:
>
> $('all').delegate('click', Behaviors.close)
>
> What do you think?
>
> On Feb 8, 6:19 pm, "Nicolás Sanguinetti" <[EMAIL PROTECTED]> wrote:
>
> > I'd normally respond that since adding this feature is only 5 lines
> > away, it'd serve well as a plugin. *But*, event delegation is usually
> > "such a good practice" that adding this to core could be a nice
> > incentive for all those people that come into #prototype asking why do
> > my 51238 cells in the table take so much to observe an event :)
>
> > I'm not sure if I like the syntax yet, maybe something more LowPro-ish
> > as artemy suggested could be nicer
>
> > element.delegate("click", {
> > ".close": Behaviors.close,
> > ".send_friend": Behaviors.sendToFriend,
> > ...
>
> > });
>
> > (and probably a "global" document.delegate or Event.delegate that used
> > the body as the target element)
>
> > BTW, and speaking about LowPro, Dan blogged earlier today about this
> > same thing, but in
> > jquery:http://www.danwebb.net/2008/2/8/event-delegation-made-easy-in-jquery
>
> > Thoughts?
> > -Nicolas
>
> > On Feb 8, 2008 9:02 PM, Pat Nakajima <[EMAIL PROTECTED]> wrote:
>
> > > I guess I'll have to simulate non-bubbling events (though that
> > > shouldn't be too painful due to Prototype's custom events). In the
> > > meantime, I've submitted a patch containing pretty much the code I've
> > > included above, as well as unit
> > > tests:http://dev.rubyonrails.org/ticket/11060
>
> > > On Feb 8, 4:07 pm, "artemy tregoubenko" <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > On Fri, 08 Feb 2008 23:48:10 +0300, Pat Nakajima <[EMAIL PROTECTED]>
> > > > wrote:
>
> > > > > Ah, good point. I've updated my code to reflect your advice:
>
> > > > > Object.extend(Event, {
> > > > > delegate: function(element, eventName, targetSelector, handler) {
> > > > > var element = $(element);
> > > > > element.observe(eventName, function(_delegatedEvent) {
> > > > > var origin = _delegatedEvent.element();
> > > > > if ( origin.match(targetSelector) ){
> > > > > return handler(_delegatedEvent);
> > > > > }
> > > > > })
> > > > > }
> > > > > })
>
> > > > > I've looked into the Behaviour library, and used
[Prototype-core] Re: Simple event delegation
That LowPro post was actually what sparked the idea for me. As for the
syntax you proposed, I prefer my own (though I'm obviously biased),
because I like how closely it matches Element.observe. This has a
couple advantages. First, users will be more inclined to make use of
it since the syntax will be familiar. Second, the current behavior of
Event.observe specifies one behavior for one event name, on any number
of elements (through the use of the following pattern:
$$('.close').invoke('observe', 'click', Behaviors.close)
I've been using Event.delegate as a replacement for this pattern, so
rather than include a totally new paradigm (which is already provided
through the LowPro library, which will probably have delegation
support soon anyway), I think that "the Prototype way" would be:
$('all').delegate('click', Behaviors.close)
What do you think?
On Feb 8, 6:19 pm, "Nicolás Sanguinetti" <[EMAIL PROTECTED]> wrote:
> I'd normally respond that since adding this feature is only 5 lines
> away, it'd serve well as a plugin. *But*, event delegation is usually
> "such a good practice" that adding this to core could be a nice
> incentive for all those people that come into #prototype asking why do
> my 51238 cells in the table take so much to observe an event :)
>
> I'm not sure if I like the syntax yet, maybe something more LowPro-ish
> as artemy suggested could be nicer
>
> element.delegate("click", {
> ".close": Behaviors.close,
> ".send_friend": Behaviors.sendToFriend,
> ...
>
> });
>
> (and probably a "global" document.delegate or Event.delegate that used
> the body as the target element)
>
> BTW, and speaking about LowPro, Dan blogged earlier today about this
> same thing, but in
> jquery:http://www.danwebb.net/2008/2/8/event-delegation-made-easy-in-jquery
>
> Thoughts?
> -Nicolas
>
> On Feb 8, 2008 9:02 PM, Pat Nakajima <[EMAIL PROTECTED]> wrote:
>
>
>
> > I guess I'll have to simulate non-bubbling events (though that
> > shouldn't be too painful due to Prototype's custom events). In the
> > meantime, I've submitted a patch containing pretty much the code I've
> > included above, as well as unit
> > tests:http://dev.rubyonrails.org/ticket/11060
>
> > On Feb 8, 4:07 pm, "artemy tregoubenko" <[EMAIL PROTECTED]>
> > wrote:
>
> > > On Fri, 08 Feb 2008 23:48:10 +0300, Pat Nakajima <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > Ah, good point. I've updated my code to reflect your advice:
>
> > > > Object.extend(Event, {
> > > > delegate: function(element, eventName, targetSelector, handler) {
> > > > var element = $(element);
> > > > element.observe(eventName, function(_delegatedEvent) {
> > > > var origin = _delegatedEvent.element();
> > > > if ( origin.match(targetSelector) ){
> > > > return handler(_delegatedEvent);
> > > > }
> > > > })
> > > > }
> > > > })
>
> > > > I've looked into the Behaviour library, and used LowPro quite
> > > > extensively. The trouble is that these libraries (correct me if I'm
> > > > wrong) is that they require some sort of refresh if elements are added
> > > > to the page dynamically, where as a delegation approach does not.
>
> > > Yes, Behaviour requires refresh, however it can be easily patched to use
> > > delegation model. I proposed its syntax only : )
>
> > > > The problem I'm running into with "submit" not working seems to be
> > > > related to the fact that the "submit" event doesn't bubble. I suppose
> > > > I could simulate this, though I wonder if there's a better way.
>
> > > I once had an idea of fighting this issue: watch clicks on inputs and
> > > thus detect forms on page. This worked for me, but not when buttons were
> > > clicked programmatically.
>
> > > > artemy tregoubenko wrote:
> > > >> No, I refer to delegate() method you've sent here via email.
>
> > > >> Event.stop() in you code will stop all event, except ones you want to
> > > >> handle. I.e. when you run body.delegate('click', 'input', something),
> > > >> all links on page will become unclickable.
>
> > > >> > Sorry, I'm not even quite sure what that means. Are you referring to
> > > >> > the sample HTML page?
>
> > > >> > On Feb 8, 2:55�pm, "artemy tregoubenko" <[EMAIL PROTECTED]>
> > > >> > wrote:
> > > >> >> I doubt you really want to stop mismatching events : )
>
> > > >> >> Concerning sugar, you might be interested in syntax of behaviours
> > > >> >> library
>
> > > >> >> > Hey, after reading up a bit about event delegation vs. event
> > > >> >> > handling
> > > >> >> > (http://icant.co.uk/sandbox/eventdelegation), I put together this
> > > >> >> > little bit:
>
> > > >> >> > � Object.extend(Event, {
> > > >> >> > � � delegate: function(element, eventName, targetSelector,
> > > >> >> > handler) {
> > > >> >> > � � � var element = $(element);
> > > >> >> > � � � element.observe(eventName, function(event){
> > > >> >> > � � � � var origin = $(event.target);
> > > >> >> > � � � � if ( origin.match(targetSelector) ){
[Prototype-core] Re: Simple event delegation
I'd normally respond that since adding this feature is only 5 lines
away, it'd serve well as a plugin. *But*, event delegation is usually
"such a good practice" that adding this to core could be a nice
incentive for all those people that come into #prototype asking why do
my 51238 cells in the table take so much to observe an event :)
I'm not sure if I like the syntax yet, maybe something more LowPro-ish
as artemy suggested could be nicer
element.delegate("click", {
".close": Behaviors.close,
".send_friend": Behaviors.sendToFriend,
...
});
(and probably a "global" document.delegate or Event.delegate that used
the body as the target element)
BTW, and speaking about LowPro, Dan blogged earlier today about this
same thing, but in jquery:
http://www.danwebb.net/2008/2/8/event-delegation-made-easy-in-jquery
Thoughts?
-Nicolas
On Feb 8, 2008 9:02 PM, Pat Nakajima <[EMAIL PROTECTED]> wrote:
>
> I guess I'll have to simulate non-bubbling events (though that
> shouldn't be too painful due to Prototype's custom events). In the
> meantime, I've submitted a patch containing pretty much the code I've
> included above, as well as unit tests: http://dev.rubyonrails.org/ticket/11060
>
> On Feb 8, 4:07 pm, "artemy tregoubenko" <[EMAIL PROTECTED]>
> wrote:
>
> > On Fri, 08 Feb 2008 23:48:10 +0300, Pat Nakajima <[EMAIL PROTECTED]> wrote:
> >
> > > Ah, good point. I've updated my code to reflect your advice:
> >
> > > Object.extend(Event, {
> > > delegate: function(element, eventName, targetSelector, handler) {
> > > var element = $(element);
> > > element.observe(eventName, function(_delegatedEvent) {
> > > var origin = _delegatedEvent.element();
> > > if ( origin.match(targetSelector) ){
> > > return handler(_delegatedEvent);
> > > }
> > > })
> > > }
> > > })
> >
> > > I've looked into the Behaviour library, and used LowPro quite
> > > extensively. The trouble is that these libraries (correct me if I'm
> > > wrong) is that they require some sort of refresh if elements are added
> > > to the page dynamically, where as a delegation approach does not.
> >
> > Yes, Behaviour requires refresh, however it can be easily patched to use
> > delegation model. I proposed its syntax only : )
> >
> > > The problem I'm running into with "submit" not working seems to be
> > > related to the fact that the "submit" event doesn't bubble. I suppose
> > > I could simulate this, though I wonder if there's a better way.
> >
> > I once had an idea of fighting this issue: watch clicks on inputs and thus
> > detect forms on page. This worked for me, but not when buttons were clicked
> > programmatically.
> >
> >
> >
> > > artemy tregoubenko wrote:
> > >> No, I refer to delegate() method you've sent here via email.
> >
> > >> Event.stop() in you code will stop all event, except ones you want to
> > >> handle. I.e. when you run body.delegate('click', 'input', something),
> > >> all links on page will become unclickable.
> >
> > >> > Sorry, I'm not even quite sure what that means. Are you referring to
> > >> > the sample HTML page?
> >
> > >> > On Feb 8, 2:55�pm, "artemy tregoubenko" <[EMAIL PROTECTED]>
> > >> > wrote:
> > >> >> I doubt you really want to stop mismatching events : )
> >
> > >> >> Concerning sugar, you might be interested in syntax of behaviours
> > >> >> library
> >
> > >> >> > Hey, after reading up a bit about event delegation vs. event
> > >> >> > handling
> > >> >> > (http://icant.co.uk/sandbox/eventdelegation), I put together this
> > >> >> > little bit:
> >
> > >> >> > � Object.extend(Event, {
> > >> >> > � � delegate: function(element, eventName, targetSelector, handler)
> > >> >> > {
> > >> >> > � � � var element = $(element);
> > >> >> > � � � element.observe(eventName, function(event){
> > >> >> > � � � � var origin = $(event.target);
> > >> >> > � � � � if ( origin.match(targetSelector) ){
> > >> >> > � � � � � return handler(event);
> > >> >> > � � � � } else {
> > >> >> > � � � � � event.stop();
> > >> >> > � � � � }
> > >> >> > � � � })
> > >> >> > � � }
> > >> >> > � })
> >
> > >> >> > � var ElementExtensions = {
> > >> >> > � � delegate: Event.delegate
> > >> >> > � }
> >
> > >> >> > � Element.addMethods(ElementExtensions);
> >
> > >> >> > Now, I'm not the foremost expert on Prototype's event handling, but
> > >> >> > I
> > >> >> > thought this was a nice little bit of syntactic sugar, and it seems
> > >> >> > to
> > >> >> > work well enough. Do you think it's fit for core? (If so, I'd love
> > >> >> > to
> > >> >> > clean it up and write some tests)
> >
> > >> >> --
> > >> >> arty (http://arty.name)
> >
> > >> --
> > >> arty (http://arty.name)
> >
> > --
> > arty (http://arty.name)
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this g
[Prototype-core] Re: Simple event delegation
I guess I'll have to simulate non-bubbling events (though that
shouldn't be too painful due to Prototype's custom events). In the
meantime, I've submitted a patch containing pretty much the code I've
included above, as well as unit tests: http://dev.rubyonrails.org/ticket/11060
On Feb 8, 4:07 pm, "artemy tregoubenko" <[EMAIL PROTECTED]>
wrote:
> On Fri, 08 Feb 2008 23:48:10 +0300, Pat Nakajima <[EMAIL PROTECTED]> wrote:
>
> > Ah, good point. I've updated my code to reflect your advice:
>
> > Object.extend(Event, {
> > delegate: function(element, eventName, targetSelector, handler) {
> > var element = $(element);
> > element.observe(eventName, function(_delegatedEvent) {
> > var origin = _delegatedEvent.element();
> > if ( origin.match(targetSelector) ){
> > return handler(_delegatedEvent);
> > }
> > })
> > }
> > })
>
> > I've looked into the Behaviour library, and used LowPro quite
> > extensively. The trouble is that these libraries (correct me if I'm
> > wrong) is that they require some sort of refresh if elements are added
> > to the page dynamically, where as a delegation approach does not.
>
> Yes, Behaviour requires refresh, however it can be easily patched to use
> delegation model. I proposed its syntax only : )
>
> > The problem I'm running into with "submit" not working seems to be
> > related to the fact that the "submit" event doesn't bubble. I suppose
> > I could simulate this, though I wonder if there's a better way.
>
> I once had an idea of fighting this issue: watch clicks on inputs and thus
> detect forms on page. This worked for me, but not when buttons were clicked
> programmatically.
>
>
>
> > artemy tregoubenko wrote:
> >> No, I refer to delegate() method you've sent here via email.
>
> >> Event.stop() in you code will stop all event, except ones you want to
> >> handle. I.e. when you run body.delegate('click', 'input', something), all
> >> links on page will become unclickable.
>
> >> > Sorry, I'm not even quite sure what that means. Are you referring to
> >> > the sample HTML page?
>
> >> > On Feb 8, 2:55�pm, "artemy tregoubenko" <[EMAIL PROTECTED]>
> >> > wrote:
> >> >> I doubt you really want to stop mismatching events : )
>
> >> >> Concerning sugar, you might be interested in syntax of behaviours
> >> >> library
>
> >> >> > Hey, after reading up a bit about event delegation vs. event handling
> >> >> > (http://icant.co.uk/sandbox/eventdelegation), I put together this
> >> >> > little bit:
>
> >> >> > � Object.extend(Event, {
> >> >> > � � delegate: function(element, eventName, targetSelector, handler) {
> >> >> > � � � var element = $(element);
> >> >> > � � � element.observe(eventName, function(event){
> >> >> > � � � � var origin = $(event.target);
> >> >> > � � � � if ( origin.match(targetSelector) ){
> >> >> > � � � � � return handler(event);
> >> >> > � � � � } else {
> >> >> > � � � � � event.stop();
> >> >> > � � � � }
> >> >> > � � � })
> >> >> > � � }
> >> >> > � })
>
> >> >> > � var ElementExtensions = {
> >> >> > � � delegate: Event.delegate
> >> >> > � }
>
> >> >> > � Element.addMethods(ElementExtensions);
>
> >> >> > Now, I'm not the foremost expert on Prototype's event handling, but I
> >> >> > thought this was a nice little bit of syntactic sugar, and it seems to
> >> >> > work well enough. Do you think it's fit for core? (If so, I'd love to
> >> >> > clean it up and write some tests)
>
> >> >> --
> >> >> arty (http://arty.name)
>
> >> --
> >> arty (http://arty.name)
>
> --
> arty (http://arty.name)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
On Fri, 08 Feb 2008 23:48:10 +0300, Pat Nakajima <[EMAIL PROTECTED]> wrote:
>
> Ah, good point. I've updated my code to reflect your advice:
>
> Object.extend(Event, {
> delegate: function(element, eventName, targetSelector, handler) {
> var element = $(element);
> element.observe(eventName, function(_delegatedEvent) {
> var origin = _delegatedEvent.element();
> if ( origin.match(targetSelector) ){
> return handler(_delegatedEvent);
> }
> })
> }
> })
>
> I've looked into the Behaviour library, and used LowPro quite
> extensively. The trouble is that these libraries (correct me if I'm
> wrong) is that they require some sort of refresh if elements are added
> to the page dynamically, where as a delegation approach does not.
Yes, Behaviour requires refresh, however it can be easily patched to use
delegation model. I proposed its syntax only : )
> The problem I'm running into with "submit" not working seems to be
> related to the fact that the "submit" event doesn't bubble. I suppose
> I could simulate this, though I wonder if there's a better way.
I once had an idea of fighting this issue: watch clicks on inputs and thus
detect forms on page. This worked for me, but not when buttons were clicked
programmatically.
> artemy tregoubenko wrote:
>> No, I refer to delegate() method you've sent here via email.
>>
>> Event.stop() in you code will stop all event, except ones you want to
>> handle. I.e. when you run body.delegate('click', 'input', something), all
>> links on page will become unclickable.
>>
>> >
>> > Sorry, I'm not even quite sure what that means. Are you referring to
>> > the sample HTML page?
>> >
>> > On Feb 8, 2:55�pm, "artemy tregoubenko" <[EMAIL PROTECTED]>
>> > wrote:
>> >> I doubt you really want to stop mismatching events : )
>> >>
>> >> Concerning sugar, you might be interested in syntax of behaviours library
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> > Hey, after reading up a bit about event delegation vs. event handling
>> >> > (http://icant.co.uk/sandbox/eventdelegation), I put together this
>> >> > little bit:
>> >>
>> >> > � Object.extend(Event, {
>> >> > � � delegate: function(element, eventName, targetSelector, handler) {
>> >> > � � � var element = $(element);
>> >> > � � � element.observe(eventName, function(event){
>> >> > � � � � var origin = $(event.target);
>> >> > � � � � if ( origin.match(targetSelector) ){
>> >> > � � � � � return handler(event);
>> >> > � � � � } else {
>> >> > � � � � � event.stop();
>> >> > � � � � }
>> >> > � � � })
>> >> > � � }
>> >> > � })
>> >>
>> >> > � var ElementExtensions = {
>> >> > � � delegate: Event.delegate
>> >> > � }
>> >>
>> >> > � Element.addMethods(ElementExtensions);
>> >>
>> >> > Now, I'm not the foremost expert on Prototype's event handling, but I
>> >> > thought this was a nice little bit of syntactic sugar, and it seems to
>> >> > work well enough. Do you think it's fit for core? (If so, I'd love to
>> >> > clean it up and write some tests)
>> >>
>> >> --
>> >> arty (http://arty.name)
>> > >
>> >
>>
>>
>>
>> --
>> arty ( http://arty.name )
> >
>
--
arty ( http://arty.name )
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
Ah, good point. I've updated my code to reflect your advice:
Object.extend(Event, {
delegate: function(element, eventName, targetSelector, handler) {
var element = $(element);
element.observe(eventName, function(_delegatedEvent) {
var origin = _delegatedEvent.element();
if ( origin.match(targetSelector) ){
return handler(_delegatedEvent);
}
})
}
})
I've looked into the Behaviour library, and used LowPro quite
extensively. The trouble is that these libraries (correct me if I'm
wrong) is that they require some sort of refresh if elements are added
to the page dynamically, where as a delegation approach does not.
The problem I'm running into with "submit" not working seems to be
related to the fact that the "submit" event doesn't bubble. I suppose
I could simulate this, though I wonder if there's a better way.
artemy tregoubenko wrote:
> No, I refer to delegate() method you've sent here via email.
>
> Event.stop() in you code will stop all event, except ones you want to handle.
> I.e. when you run body.delegate('click', 'input', something), all links on
> page will become unclickable.
>
> >
> > Sorry, I'm not even quite sure what that means. Are you referring to
> > the sample HTML page?
> >
> > On Feb 8, 2:55�pm, "artemy tregoubenko" <[EMAIL PROTECTED]>
> > wrote:
> >> I doubt you really want to stop mismatching events : )
> >>
> >> Concerning sugar, you might be interested in syntax of behaviours library
> >>
> >>
> >>
> >>
> >>
> >> > Hey, after reading up a bit about event delegation vs. event handling
> >> > (http://icant.co.uk/sandbox/eventdelegation), I put together this
> >> > little bit:
> >>
> >> > � Object.extend(Event, {
> >> > � � delegate: function(element, eventName, targetSelector, handler) {
> >> > � � � var element = $(element);
> >> > � � � element.observe(eventName, function(event){
> >> > � � � � var origin = $(event.target);
> >> > � � � � if ( origin.match(targetSelector) ){
> >> > � � � � � return handler(event);
> >> > � � � � } else {
> >> > � � � � � event.stop();
> >> > � � � � }
> >> > � � � })
> >> > � � }
> >> > � })
> >>
> >> > � var ElementExtensions = {
> >> > � � delegate: Event.delegate
> >> > � }
> >>
> >> > � Element.addMethods(ElementExtensions);
> >>
> >> > Now, I'm not the foremost expert on Prototype's event handling, but I
> >> > thought this was a nice little bit of syntactic sugar, and it seems to
> >> > work well enough. Do you think it's fit for core? (If so, I'd love to
> >> > clean it up and write some tests)
> >>
> >> --
> >> arty (http://arty.name)
> > >
> >
>
>
>
> --
> arty ( http://arty.name )
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
No, I refer to delegate() method you've sent here via email.
Event.stop() in you code will stop all event, except ones you want to handle.
I.e. when you run body.delegate('click', 'input', something), all links on page
will become unclickable.
>
> Sorry, I'm not even quite sure what that means. Are you referring to
> the sample HTML page?
>
> On Feb 8, 2:55�pm, "artemy tregoubenko" <[EMAIL PROTECTED]>
> wrote:
>> I doubt you really want to stop mismatching events : )
>>
>> Concerning sugar, you might be interested in syntax of behaviours library
>>
>>
>>
>>
>>
>> > Hey, after reading up a bit about event delegation vs. event handling
>> > (http://icant.co.uk/sandbox/eventdelegation), I put together this
>> > little bit:
>>
>> > � Object.extend(Event, {
>> > � � delegate: function(element, eventName, targetSelector, handler) {
>> > � � � var element = $(element);
>> > � � � element.observe(eventName, function(event){
>> > � � � � var origin = $(event.target);
>> > � � � � if ( origin.match(targetSelector) ){
>> > � � � � � return handler(event);
>> > � � � � } else {
>> > � � � � � event.stop();
>> > � � � � }
>> > � � � })
>> > � � }
>> > � })
>>
>> > � var ElementExtensions = {
>> > � � delegate: Event.delegate
>> > � }
>>
>> > � Element.addMethods(ElementExtensions);
>>
>> > Now, I'm not the foremost expert on Prototype's event handling, but I
>> > thought this was a nice little bit of syntactic sugar, and it seems to
>> > work well enough. Do you think it's fit for core? (If so, I'd love to
>> > clean it up and write some tests)
>>
>> --
>> arty (http://arty.name)
> >
>
--
arty ( http://arty.name )
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
Hrm, maybe my script isn't as good as I thought, since it doesn't seem
to be working with submit events. Oh well. Sorry about that.
On Feb 8, 3:04 pm, Pat Nakajima <[EMAIL PROTECTED]> wrote:
> Sorry, I'm not even quite sure what that means. Are you referring to
> the sample HTML page?
>
> On Feb 8, 2:55 pm, "artemy tregoubenko" <[EMAIL PROTECTED]>
> wrote:
>
> > I doubt you really want to stop mismatching events : )
>
> > Concerning sugar, you might be interested in syntax of behaviours library
>
> > > Hey, after reading up a bit about event delegation vs. event handling
> > > (http://icant.co.uk/sandbox/eventdelegation), I put together this
> > > little bit:
>
> > > Object.extend(Event, {
> > > delegate: function(element, eventName, targetSelector, handler) {
> > > var element = $(element);
> > > element.observe(eventName, function(event){
> > > var origin = $(event.target);
> > > if ( origin.match(targetSelector) ){
> > > return handler(event);
> > > } else {
> > > event.stop();
> > > }
> > > })
> > > }
> > > })
>
> > > var ElementExtensions = {
> > > delegate: Event.delegate
> > > }
>
> > > Element.addMethods(ElementExtensions);
>
> > > Now, I'm not the foremost expert on Prototype's event handling, but I
> > > thought this was a nice little bit of syntactic sugar, and it seems to
> > > work well enough. Do you think it's fit for core? (If so, I'd love to
> > > clean it up and write some tests)
>
> > --
> > arty (http://arty.name)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
Sorry, I'm not even quite sure what that means. Are you referring to
the sample HTML page?
On Feb 8, 2:55 pm, "artemy tregoubenko" <[EMAIL PROTECTED]>
wrote:
> I doubt you really want to stop mismatching events : )
>
> Concerning sugar, you might be interested in syntax of behaviours library
>
>
>
>
>
> > Hey, after reading up a bit about event delegation vs. event handling
> > (http://icant.co.uk/sandbox/eventdelegation), I put together this
> > little bit:
>
> > Object.extend(Event, {
> > delegate: function(element, eventName, targetSelector, handler) {
> > var element = $(element);
> > element.observe(eventName, function(event){
> > var origin = $(event.target);
> > if ( origin.match(targetSelector) ){
> > return handler(event);
> > } else {
> > event.stop();
> > }
> > })
> > }
> > })
>
> > var ElementExtensions = {
> > delegate: Event.delegate
> > }
>
> > Element.addMethods(ElementExtensions);
>
> > Now, I'm not the foremost expert on Prototype's event handling, but I
> > thought this was a nice little bit of syntactic sugar, and it seems to
> > work well enough. Do you think it's fit for core? (If so, I'd love to
> > clean it up and write some tests)
>
> --
> arty (http://arty.name)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
I doubt you really want to stop mismatching events : )
Concerning sugar, you might be interested in syntax of behaviours library
>
> Hey, after reading up a bit about event delegation vs. event handling
> (http://icant.co.uk/sandbox/eventdelegation), I put together this
> little bit:
>
> Object.extend(Event, {
> delegate: function(element, eventName, targetSelector, handler) {
> var element = $(element);
> element.observe(eventName, function(event){
> var origin = $(event.target);
> if ( origin.match(targetSelector) ){
> return handler(event);
> } else {
> event.stop();
> }
> })
> }
> })
>
> var ElementExtensions = {
> delegate: Event.delegate
> }
>
> Element.addMethods(ElementExtensions);
>
> Now, I'm not the foremost expert on Prototype's event handling, but I
> thought this was a nice little bit of syntactic sugar, and it seems to
> work well enough. Do you think it's fit for core? (If so, I'd love to
> clean it up and write some tests)
> >
>
--
arty ( http://arty.name )
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Simple event delegation
By the way, here's a quick html page to show it in action:
http://pastie.caboo.se/149394
On Feb 8, 2:17 pm, Pat Nakajima <[EMAIL PROTECTED]> wrote:
> Hey, after reading up a bit about event delegation vs. event handling
> (http://icant.co.uk/sandbox/eventdelegation), I put together this
> little bit:
>
> Object.extend(Event, {
> delegate: function(element, eventName, targetSelector, handler) {
> var element = $(element);
> element.observe(eventName, function(event){
> var origin = $(event.target);
> if ( origin.match(targetSelector) ){
> return handler(event);
> } else {
> event.stop();
> }
> })
> }
> })
>
> var ElementExtensions = {
> delegate: Event.delegate
> }
>
> Element.addMethods(ElementExtensions);
>
> Now, I'm not the foremost expert on Prototype's event handling, but I
> thought this was a nice little bit of syntactic sugar, and it seems to
> work well enough. Do you think it's fit for core? (If so, I'd love to
> clean it up and write some tests)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
