[Proto-Scripty] Re: Order of Event Handler
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: docshttp://docs.jquery.com/Using_jQuery_with_Other_Libraries API http://api.jquery.com/jQuery.noConflict/. -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To view this discussion on the web visit https://groups.google.com/d/msg/prototype-scriptaculous/-/wQpy_YAkokcJ. 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.
[Proto-Scripty] Re: Order of Event Handler
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
[Proto-Scripty] Re: Order of Event Handler
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