I'm not sure what all is involved/required for calling .unbind() to be
honest. Wouldn't it just be this._input.unbind('change') ?
or are there additional parameters required? If it needs a fn
reference, that's what hitch() returns ...
var cb = $.hitch(this, "_change");
this._input.bind('change',
> this._input.bind('change', $.hitch(this, "_onInputChange"));
How do you unbind the ‘hitched’ method?
On Apr 8, 11:04 pm, pete higgins wrote:
> My hitch() method does this kind of:
>
> http://higginsforpresident.net/js/jq.hitch.js
>
> It would look like:
>
> this._input.bind('change', $.hitch(
+1
The ability to specify the scope to a handler function would be a
great addition to jQuery core.
On Apr 8, 12:03 pm, gregory wrote:
> the only difficulty I am having with
> Balazs Endresz's approach (which I have also
> implemented in my environment) is if another developer passes a
> functio
My hitch() method does this kind of:
http://higginsforpresident.net/js/jq.hitch.js
It would look like:
this._input.bind('change', $.hitch(this, "_onInputChange"));
Regards,
Peter Higgins
On Wed, Apr 8, 2009 at 12:03 PM, gregory wrote:
>
> the only difficulty I am having with
> Balazs Endresz
the only difficulty I am having with
Balazs Endresz's approach (which I have also
implemented in my environment) is if another developer passes a
function as 'data' param, the results become unpredictable. Though I
don't *think* anybody should be passing a function to access as
event.data, it curr
>From the updated jQuery 1.4 Roadmap:
> If you need a different object for the scope, why not use the data argument
> to transport it?
In OOP-style applications the handler is often not an anonymous
function but a link to the current objects's prototype method:
this._input.bind('change', this._
Passing handler after scope is not suitable for two reasons:
1. There's no way to determine whether data or scope is passed in a
three-argument method call.
2. Passing scope after handler is common pattern in JavaScript 1.6
methods like forEach.
On Dec 25 2008, 11:08 pm, "Eduardo Lundgren"
wrot
+1
I like that, we can use it in many instances in jQuery UI.
On 25 Dez., 21:08, "Eduardo Lundgren"
wrote:
> The isFunction is faster now but still has more coast that when you don't
> need to call it.
>
> We should keep the handler as the last parameter to fit with the jQuery API,
> the change
The isFunction is faster now but still has more coast that when you don't
need to call it.
We should keep the handler as the last parameter to fit with the jQuery API,
the change is compatible with it.
$('div').bind('click', {data: true}, scope, *scope.internalHandler*);
Scoping events is a go
True, but the new isFunction is a couple of times faster than the old
one, though it's still many times faster to directly call
Object.prototype.toString, which is far below 0.001ms. But as the
callback function is the last parameter everywhere in jQuery it might
be confusing to change this patter
Note that isFunction is much faster now. It has been improved 3 times
between 1.2.6 and 1.3b.
On Thu, Dec 25, 2008 at 4:06 PM, Eduardo Lundgren wrote:
> Hi Balazs,
>
> Thanks for give us your opinion.
>
> When you use $.isFunction(data) on the bind method it is very expensive
> when you have a l
Hi Balazs,
Thanks for give us your opinion.
When you use $.isFunction(data) on the bind method it is very expensive when
you have a lot of iterations.
Diff the file I attached with the original file (rev. 5996) I made only a
small change on the bind() method, and it's compatible with data and wi
Hi, I think this would be really useful! I've also modified jQuery to
do this a while ago (1.2.6) but with the new scope being the last
argument, so it works without the data object as well:
jQuery.fn.bind=function( type, data, fn, bind ) {
return type == "unload" ? this.one(type,
13 matches
Mail list logo
