This will do it:
$('input').on('change', function(event){
...
}).change();
...but what if there is another plugin installed that hooks some function on the change event? I'll trigger that function too, and it may not be desirable. How can I avoid such conflicts?
Use namespaced events
$('input').on('change.myevent', function(event){
...
}).trigger('change.myevent');
This will get triggered on normal change events (along with other change handlers on it) but will also be triggered by change.myevent (only it)
This will also allow you to unbind only your own event in case you need to ..
Related
I need to capture data from an instance generated by <template is="dom-repeat"> in Polymer (v1.2.4) and I am not sure what would be the safest way to do so considering the myriad of Shadow DOMs available (client browser might be polyfilled etc).
A simple example:
<template is="dom-repeat" items="[[myItems]]" id="collection">
<paper-card on-tap="handleTap">
(...)
What is the most reliable way to access the model data from the event handler?
1.
handleTap: function(e) {
var data = e.model.get('item.myData');
}
2.
handleTap: function(e) {
var data = this.$.collection
.modelForElement(Polymer.dom(e).localTarget)
.get('item.myData');
}
My concern is that the simplest (#1) option might be working as expected in my environment but can get buggy in other browsers.
And even in option #2, I am not confident if it is really necessary to normalize the event target (as recommended in the official Polymer guide on events) prior to passing it to modelForElement.
Both should work; but, it seems you should fire a custom event though over trying to inspect a child model. What ever component that has "item.myData" should fire a custom event on tap with "item.myData" as part of the event. Then you should setup a listener for that custom event.
See custom events for more details.
I want to execute a function after the user hilites some text.
I was hoping to listen for the 'selectionChange' event for that purpose, but the documentation states that it doesn't fire for every case, plus I've noticed that it actually also fires just by clicking into the editable area. Is there another event the my plugin can listen for?
This worked for me.
CKEDITOR.instances.editor1.document.$.addEventListener('selectionchange', function (e) { //selection change logic goes here });
I've got an event listener for click:
circle.on('click', function() { ... });
Can I use a callback to do something after the click event handling has occurred?
I'm not entirely sure what you mean, but you can run arbitrary code inside the click handler, including code that is run after the "normal" event handling is done. You can also trigger other events from that code to allow you to use other callbacks.
I don't really understand what delegate and promise are.
According to the docs -
delegate would bind a selector and event to some sort of wrapping container that can be used again at a later time for current and future items.
promise() would remap things back to when it was first bounded if everything newly loaded matches. Maybe I don't really understand this promise method.
What if the wrapper is still there, but the contents in the wrapper container have changed, and/or reloaded via Ajax? Why is it that the events are not triggering or working as it would the first time it is bound?
And yes, I have been to the docs page, I just don't understand their explanations completely.
I'm a bit confused by this question. I think this is because you are confused by promise and delegate. They are in fact completely unrelated features of jQuery. I'll explain each separately:
delegate
delegate is a feature of jQuery that was introduced in jQuery 1.4.2. (It is a nicer approach to the live feature that was added in jQuery 1.3). It solves a particular problem that comes with modifying the DOM, and particularly with AJAX calls.
When you bind an event handler, you bind it to a selection. So you might do $('.special').click(fn) to bind an event handler to all the members of the special class. You bind to those elements, so if you then remove the class from one of those elements, the event will still be triggered. Inversely, if you add the class to an element (or add a new element into the DOM), it won't have the event bound.
There is a feature of Javascript that mitigates this called "event bubbling". When an event is triggered, first the browser notifies the element where the event originated. Then it goes up the DOM tree, and notifies each ancestor element. This means that you can bind an event handler on an element high up the DOM tree, and events triggered on any child elements (even those that don't exist when the handler was bound).
delegate is jQuery's implementation of this. First, you select a parent element. Then you specify a selector – the handler will only be run if the originating element matches this selector. Then you specify an event type, such as click, submit, keydown, just as with bind. Then finally you specify the event handler.
$('#containingElement').delegate('a.special', 'click', function() {
alert('This will happen on all links with the special class');
});
promise
promise is another relatively recent addition to the jQuery featureset. It is part of the Deferred concept that was introduced in jQuery 1.5. (I think the similarity in sound between "deferred" and "delegate" is probably the source of confusion.) This is a way of abstracting away the complications of asynchronous code. The best example of this is with AJAX calls, as the object returned by $.ajax is a Deferred object. For instance:
$.ajax({
url: 'somepage.cgi',
data: {foo: 'bar'}
}).done(function() {
// this will be run when the AJAX request succeeds
}).fail(function() {
// this will be run when the AJAX request fails
}).always(function() {
// this will be run when the AJAX request is complete, whether it fails or succeeds
}).done(function() {
// this will also be run when the AJAX request succeeds
});
So it is in many ways the same as binding success handlers in the $.ajax call, except that you can bind more than one handler, and you can bind them after the initial call.
Another time when it would be useful to deal asynchronously is with animations. You can provide callbacks to functions, but it would be nicer to do this with similar syntax to the AJAX example I've provided above.
In jQuery 1.6, this functionality was made possible, and promise is part of this implementation. You call promise on a jQuery selection, and you'll get an object that you can bind event handlers to, when all the animations in the object have completed.
For instance:
$('div.special').fadeIn(5000).promise().then(function() {
// run when the animation succeeds
}).then(function() {
// also run when the animation succeeds
});
Again, this is similar in effect to traditional methods, but it adds flexibility. You can bind the handlers later, and you can bind more than one.
Summary
Basically, there is no significant relationship between delegate and promise, but they're both useful features in modern jQuery.
Working on a Wicket application that adds markup to the DOM after onLoad via Wicket's built-in AJAX for an auto-complete widget. We have an IE6 glitch that means I need to reposition the markup coming in, and I am trying to avoid tampering with the Wicket javascript... blah blah blah... here's what I'm trying to do:
New markup arrives in the DOM (I
don't have access to a callback)
Somehow I know this, so I fire my
code.
I tried this, hoping the new tags would trigger onLoad events:
$("selectorForNewMarkup").live("onLoad", function(){ //using jQuery 1.4.1
//my code
});
...but have become educated that onLoad only fires on the initial page load. Is there another event fired when elements are added to the DOM? Or another way to sense changes to the DOM?
Everything I've bumped into on similar issues with new markup additions, they have access to the callback function on .load() or similar, or they have a real javascript event to work with and live() works perfectly.
Is this a pipe dream?
.live() doesn't work like this, it's a common misconception. .live() creates an event handler at the DOM root and waits for events to bubble up to it. If the selector matches the event target, .live() will fire the bound event.
It doesn't look for new objects and bind events to them in any way, rather it just listens for a bubble, and doesn't care when that object was added to the DOM.
You need to fire whatever code is needed to run manually when your load operation completes.
What will this is the livequery plug-in, look specifically at the livequery( matchedFn ) call.
You can do something like this:
$('#myID').livequery(function() { $(this).offset()...stuff });
i guess this is what you are looking for http://ananthakumaran.github.com/2010/02/19/wicket-post-ajax-handling.html