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

Reply via email to