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

On 7 Feb., 10:27, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> 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