Order of Event Handler

[Mem12]

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

[T.J. Crowder]

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

[Mem12]

Hello,

thanks for your reply. I don't really like the solution of resorting
the handler myself but couldn't come up with any other attempt as i've
to ensure that i'm running first and nobody runs after me.
So far the solution was to simply do a stopObserving on the click
event and therefore unregistering all handlers and then just
reregister a copy of the Tapestry function which is also a bad
decision in my opinion.
We just switched over to Tap5.3 so maybe there's a better way to
accomplish this now.
I just thought there would be a common pattern to this problem as i
almost can't believe that we're the first ones that need to 'pause'
event handlers without removing them.

Regarding the stop() i think we got some NS problems as prototype and
jQuery is mixed on many different spots and the whole namespacing
isn't consistent.

Thanks again.
Matt

[Victor]

Hello!

I just thought there would be a common pattern to this problem as i
almost can't believe that we're the first ones that need to 'pause'
event handlers without removing them.

Yes, this is a common problem without easy solution. As T.J. Crowder said, better try to find another solution.
 

Regarding the stop() i think we got some NS problems as prototype and
jQuery is mixed on many different spots and the whole namespacing
isn't consistent.

 
There is a special "no conflict" mode in jQuery: docs API.