Hi,

The fundamental answer here is: Relying on the order in which event
handlers are triggered is usually not a good design decision. Rather
than spending time trying to get it working, I'd spend time finding a
completely different way to solve the problem if at all possible.

Unlike jQuery, Prototype doesn't guarantee the order in which event
handlers are fired. When you attach an event handler with Prototype,
it really calls addEventListener/attachEvent for your specific handler
(after putting a wrapper around it), and so the order in which the
handlers are called is determined by the browser implementation.
Unfortunately, different browsers do different things. *Most* browsers
(Chrome, Firefox, Safari, Opera, IE9+ [if in standards mode]) fire
handlers in the order in which they were attached (FIFO); some
browsers (IE6, IE7, IE8) fire them in reverse order (LIFO).

jQuery addresses that by only attaching a single handler for each
event to each element; if you attach further handlers, jQuery chains
them *itself* rather than relying on the browser to do it. Prototype
doesn't do that.

> ...when i'm
> running the scripts my handler comes first but doesn't prevent the
> other handlers to run. Do i misinterpret the event.stop() method.

No, `event.stop` is meant to both stop propagation and prevent the
default action -- and it does, in the normal case.

> Weirdly, subsequent handler don't get the event when i call
> event.stopImmediatePropagation(); from within my first prototype
> handler. I'm writing weirdly cause i couldn't find any documentation
> about stopImmediatePropagation() except in jQuery, any explanation to
> this?

stopImmediatePropagation is a jQuery-only thing. If you're calling it
from within a Prototype handler, you're presumably causing an
exception by trying to call a function that doesn't exist. I can't see
why that would prevent other handlers from running.

So trying to address this with order-of-handlers is going to be a mess
and I don't recommend it. There has to be another solution.

However, if you're going to go down the order-of-handlers route, one
option would be to use a modified version of Prototype that actually
uses jQuery to hook up the handlers. This would be non-trivial, but
possible. The event object jQuery passes into handlers has access to
the "raw" event object as `event.originalEvent`, so it would be
possible for you to modify Prototype so that it inserts a wrapper
handler that receives the jQuery event object, uses Prototype to
extend the `event.originalEvent` object, and then fires the handler
using that. But it will get complicated fast (not least around
`stopObserving`).

Good luck,
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com

On Feb 7, 6:48 am, Mem12 <memcac...@gmail.com> wrote:
> Hello,
>
> we're working on a big web application and using prototype as well as
> jQuery, both are needed due to dependencies on plugins, frameworks and
> so on.
> One specific framework, Tapestry to name it, uses prototype and
> registers a click handler on each element, when clicked the event is
> stopped and a custom event is thrown which then gets processed and
> does the communication with the server.
> We show parts of an entity on a page in different sections and use
> optimistic locking. To prevent concurrent modification exceptions we'd
> like to set one section in edit mode and prevent all outside elements
> from being clicked. My problem is now that there're already click
> handler on each element and there's no way i can run a JS before that
> handler are registered. My first attempt was to resort the handler as
> i already did something similar in jQuery and it worked just fine by
> reading and manipulating the results of data('events').
> In prototype i found this to read the handler:
> {{code}}
> var registry = Element.retrieve($(element),
> 'prototype_event_registry');
> if(registry) {
>         var responders = registry.get('click');
>         //insert new handler here
>         responders = responders.reverse();
> {{/code}}
> Even that's not the clean solution i'd want (preferably i'd like to
> insert a new handler up front) i could live with that, regrettably
> prototype isn't impressed by this solution and just ignores the order.
> So my second approach was to still read the responders but instead of
> inserting my new handler i first call stopObserving('click') to
> unregister them all, then i register my new handler and subsequent the
> earlier registered ones.
>
> Any suggestions how to solve this kind of problem cleaner/faster/the
> right way would be highly appreciated.
> IMHO this problem shouldn't be new or unique as i'd guess it's quite
> common that a later handler needs to prevent earlier registered ones
> from running without removing them.
>
> So the resorting at least kinda works as described above (copy
> responders, unregister all, register new, register old, still
> hopefully someone can come up with a better solution), when i'm
> running the scripts my handler comes first but doesn't prevent the
> other handlers to run. Do i misinterpret the event.stop() method. In
> it's code there's even a call to event.stopPropagation() so i'd assume
> it does so but it doesn't? Is it the wanted and expected behaviour
> that stop doesn't prevent all subsequent handlers from also getting
> the event?
> Weirdly, subsequent handler don't get the event when i call
> event.stopImmediatePropagation(); from within my first prototype
> handler. I'm writing weirdly cause i couldn't find any documentation
> about stopImmediatePropagation() except in jQuery, any explanation to
> this?
>
> Thanks for reading such a long post and even more for answering.
> Matt

-- 
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.

Reply via email to