[jquery-dev] Re: attr() is still very broken in 1.4a1
I would note some problems (2):
If we have
$(xml).find(foo).attr(height, 180cm)
then you would expect calling elem.setAttribute() and not .height(), I
hope.
If so, there is a bug in jQuery.attr()...
Other think to take in consideration is that
$(div).attr(click, function(){ /*..*/ });
is not equivalent to
$(div).attr({
click: function(){ /*..*/ }
});
Infact in the first case we are setting click attributes with the
result of the function, while in the second case we are binding click
event, in theory (second case is still not ready?).
Not consistently at all.
Also there is a jQuery.attrFn.bind. Why?
Am I missing something?
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: attr() is still very broken in 1.4a1
If we have
$(xml).find(foo).attr(height, 180cm)
then you would expect calling elem.setAttribute() and not .height(), I
hope.
If so, there is a bug in jQuery.attr()...
So we could disable it on XML documents - but regardless, that is
definitely th exception.
I have to correct me, that code will call elem.setAttribute(), but
$(xml).find(foo).attr({height: 180cm})
will call .height()
Naturally, they aren't the case - the second is far superior. Setting
a DOM 0 expando property is simply so substitute for binding events
via jQuery.
And you are completely fine with such discrepancy between
.attr({height: 180}) and .attr(height, 180),
and between
.attr({ click: function(){ /*..*/ } }) and .attr(click, function(){ /
*..*/ }) ?
Because bind can take an object that can set multiple events
simultaneously. .bind({ click: fn, mouseover: fn2 })
Anyway I would remove that just because there is .bind({...}) and .attr
({...}) for setting multiple events simultaneously. .attr({ bind:
{...} }) is certainly dirty. Also bind is an action, not an
attribute.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: attr() is still very broken in 1.4a1
I have to correct my correcting:
Both .attr({height: 180}) and .attr(height, 180) will
call .height().
Still there still is big discrepancy between
.attr({ click: function(){/*..*/} }) and .attr(click, function(){/
*..*/})
Adding that there is no (for now) symmetry between
attr(height, ...) and attr(height)
I am afraid, that I will not be the only confused one...
On Dec 17, 7:50 am, Robert Katić robert.ka...@gmail.com wrote:
If we have
$(xml).find(foo).attr(height, 180cm)
then you would expect calling elem.setAttribute() and not .height(), I
hope.
If so, there is a bug in jQuery.attr()...
So we could disable it on XML documents - but regardless, that is
definitely th exception.
I have to correct me, that code will call elem.setAttribute(), but
$(xml).find(foo).attr({height: 180cm})
will call .height()
Naturally, they aren't the case - the second is far superior. Setting
a DOM 0 expando property is simply so substitute for binding events
via jQuery.
And you are completely fine with such discrepancy between
.attr({height: 180}) and .attr(height, 180),
and between
.attr({ click: function(){ /*..*/ } }) and .attr(click, function(){ /
*..*/ }) ?
Because bind can take an object that can set multiple events
simultaneously. .bind({ click: fn, mouseover: fn2 })
Anyway I would remove that just because there is .bind({...}) and .attr
({...}) for setting multiple events simultaneously. .attr({ bind:
{...} }) is certainly dirty. Also bind is an action, not an
attribute.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: attr() is still very broken in 1.4a1
I disagree. Being able to set all the (useful) properties of a DOM element via a single object structure can be very useful - and I see no reason not to overload the existing .attr() behavior if it already covers most of the functionality well and if there are no conflicts. I especially think that it's important to integrate it into .attr() so that we can effectively deprecate bad ways of setting DOM attributes or properties. For example, instead of doing .attr(innerHTML, some html) we can offer the much saner .attr(html, some html) same with .attr(onclick, fn) becoming .attr(click, fn) - both of these are removing the weirdness of the existing DOM APIs by providing something that's much better. Rethinking, maybe I was too hard with objections, and your arguments are mostly valid. However, there are some problems (for me) that are brought by introducing attrFn. Firstly, you are using attrFn magic with XML documents too. I hope it is not intentional. Secondly, you are exposing attrFn to jQuery. This would be dangerous if used by users that would be able to overwrite and break attr() very easily. In production scenario it would be very bed. At the end, I would be more careful by filling attrFn (i.e. data, append, prepend). Placing this in a separate function creates un-needed ambiguity. I dislike it for the same reason that I dislike having an extra .prop() method for setting just DOM object properties. We should be able to provide a unified API for setting information (called 'attr' in jQuery, mostly for legacy reasons - it actually was 'set' back when jQuery was first released) and work to meet the user's expectations based upon that. Well, I am not a fan of adding set() (or similar) either. How's that? .live() has seen considerable improvements since 1.3.2 both in the form of features (context limiting, data support), cross browser compatibility (submit, change, focus, blur, mouseenter, mouseleave), and performance (huge speed-ups to .closest() and node checking). Certainly it wasn't in my intention to diminish the great job done in that area. However I am not a fan of the current live() API because it is not giving full control to me (see http://groups.google.com/group/jquery-dev/browse_frm/thread/1240ad6bc98693af#). For that reason I am generally using manual delegation instead of live (). As far as I know I've also landed every patch you've submitted to the jQuery Github fork queue. Perhaps there's something else that you're not divulging? If I am still not divulging something, it is because it is still only a vague idea or it is not good enough to me (I am lazy). Although I am not liking everything in the API, I haven't pushed patches (making pull request) that would change the API. If I will do that, that will be only after discussing it, and with your agreement. Of course. -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Array.prototype.indexOf not fully utilized in jQuery.inArray
Already fixed. If Array.prototype.indexOf exists, then it is always used. On Dec 14, 10:38 am, helianthus project.heliant...@gmail.com wrote: This occurs when using jQuery.fn.index, which utilizes jQuery.inArray. Since the jQuery object does not have an indexOf method, it falls back to the for loop approach, while Array.prototype.indexOf could have been used. -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: attr() is still very broken in 1.4a1
I think one of the core problems is understanding what attr() is intended to do. Clearly it is not just a get/setAttribute wrapper. Clearly it is not just meant to access the properties of elements. It is a mixture of several different ways to access attributes of an element, and it apparently tries to pick the best approach and give the user what they want. Well, I have to admit that I am not too happy in which direction attr () is going. Adding to much magic is not simplifying the API to me. If we (John) wont an method that can do everything (including bindings!), than I would prefer it as an separate method (set() ?) leaving rest of API as much as possible consistent and well defined. Unfortunately, for me, it seams that jQuery API is going to prefer beginner users with cost of ignoring true potentials (i.e. live()). I love jQuery, and I hope will still love it in future. -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: enhancement for event delegation and the context-parameter
Well, I already had proposed this a month ago in the discussion
http://groups.google.com/group/jquery-dev/browse_frm/thread/588fe6d162845290/
(message #6).
There you will see that my solution (http://gist.github.com/227508)
was almost same as your, and that John at #12 was of idea that that
was easily to reproduce with no additional functionality...
Maybe it is time to reconsider if such level of control is wonted
enough to improve bind() or extending the API..
On Dec 12, 2:19 pm, alexander farkas a.farkas...@googlemail.com
wrote:
One week ago I wrote an article about the new possibility to use the
context-Parameter in conjunction with the live method (it´s in
german:http://www.protofunc.com/2009/12/08/jquery-live-methode-braucht-jquer...).
I think we need an additional method, wich gives the developer more
control over the element, to wich the eventlistener will be bound.
The current live-method, allows you to use the context-parameter, but
this option doesn´t really give you the possibility to decide, to wich
element(s) the listener is bound.
To make this more clear. Here are some examples:
1. The following code works and the eventlistener is bound to the
document
$('li', $('#nav')).live('click'
2. The following code works, as long as #nav is available, and the
eventlistener is bound to the #nav-element (very error-prone)
$('li', $('#nav')[0]).live('click'
If you have several elements, to wich the element should be bound,
jQuery doesn´t give you a straight forward method to do this:
1. The eventlistener is bound to the document
$('div.teaser', $('div.teaser-wrapper')).live('click'
2. The following code would be invalid
$( 'div.teaser', $('div.teaser-wrapper').get() ).live('click'
I came up with a very simple and short plugin, wich looks like this:
(function($){
var dummy = $([]);
$.each({addLive: 'live', removeLive: 'die'}, function(name,
jMethod){
$.fn[name] = function(sel){
var args = (this[0]) ? Array.prototype.slice.call
(arguments, 1) : [];
return this.each(function(){
dummy.selector = sel;
dummy.context = this;
$.fn[jMethod].apply(dummy, args);
});
};
});
})(jQuery);
With this plugin you can write code like this:
$('div.teaser-wrapper').addLive('div.teaser', 'click', function()
{...});
This gives you a clear and short way to setup event delegation on
specific elements.
Additionally the method could improve event delegation in two ways:
a) use of comma seperated selectors (buggy in jQuerys live-method):
$('div.teaser-wrapper').addLive('div.teaser, div.teaser-box', 'click',
function(){...});
b) add a (very) minimal performance-gain (only elements, wich are
needed to setup the listener are selected)
I know, that you have declined similiar suggestions in the past, but
event delegation gives you a lot of options, wich can´t be controlled
with the current live-method.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] jQuery.each(nodeList, ...)
Now that jQuery.makeArray(nodeList) is supported correctly, maybe it is wanted to make that also for jQuery.each, jQuery.map and jQuery.grep. There are mainly two reasons why I think it is worth of consideration: 1. $.each(nodeList) is already possible and I suppose that there are individuals that are considering that action legal because NodeLists are array like things too. Unfortunately it is not always true in IE and Opera where length expando can be overwrited. 2. Using $.each, $.map and $.grep directly with NodeLists can be still useful, not only for optimizing jQuery itself. I made a patch that would fix this http://github.com/rkatic/jquery/commit/7203092c23d5ddb623495f9145d2dab3edf1c529 If this change is welcome, than I will open a ticket... -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: $140(Array) twice as fast as $126(Array) ?
Thanks to http://dev.jquery.com/ticket/3995 On 15 stu, 11:22, DBJDBJ dbj...@gmail.com wrote: I noticed this by accident (I had a bug in some speed tests) If i give them both an array of size 1e5, the latest one is twice as fast as 1.2.6 ? var A[1e5], j=1e5; while(j--) A[j] = j ; $140(A), exits (on average) twice as fast as $126(A) ... --DBJ PS: $126 --- jQuery 1.2.6 $140 -- jQuery 1.4.pre -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=.
[jquery-dev] Re: jQuery.extend(true, ...)
Ah, yes, since options.nodes was already defined before extending, it
will not become jQuery(#content) (with all jQuery methods copied
inside itself), but something between jQuery(div) and jQuery
(#content) (with all jQuery methods copied inside itself). Even
worse.
I have to suppose that the author was drunk when he was writing it. :)
Am I missing something?
On Nov 11, 8:16 am, Robert Katić robert.ka...@gmail.com wrote:
I don't get your point. I am talking about what is extended
recursively, not what is passed as argument.
If you have something like this:
var options = {
nodes: jQuery(div),
num: 4,
date: new Date
};
jQuery.extend(true, options, {
nodes: jQuery(#content),
num: new Number(5),
date: new Date
});
then options.node would be the same jQuery(#content) object but now
with all jQuery methods copied inside itself, options.num will remain
4, options.date remain unchanged.
I think this behavior is not what someone would expect (I hope).
On Nov 11, 5:09 am, John Resig jere...@gmail.com wrote:
If someone wants to pass in a random object to be extended we won't
stop them. So yeah, someone could do:
jQuery.extend([1,2], [3]) and get [3,2] as a result - not sure why you
would want to, though. I can't think of a reason to explicitly prevent
this behavior, at least.
(On a related note I've renamed isObject to isObjectLiteral.)
--John
On Tue, Nov 10, 2009 at 9:10 PM, Robert Katić robert.ka...@gmail.com
wrote:
Wat a hell is going here?
// Recurse if we're merging object values
if ( deep copy typeof copy === object !copy.nodeType ) {
var clone;
if ( src ) {
clone = src;
} else if ( jQuery.isArray(copy) ) {
clone = [];
} else if ( jQuery.isObject(copy) ) {
clone = {};
} else {
clone = copy;
}
// Never move original objects, clone them
target[ name ] = jQuery.extend( deep, clone, copy );
You are going to extend with any object including a Date, a String, a
Number... (ah yes, excluding nodes).
You are going to extend (with) arrays? [1,2] and [4] to obtain [4,2].
Really?
If an object is not an array nor an object literal then extend object
with itself???
The only things to extend recursively are objects literals to me:
if ( deep copy jQuery.isObject(copy) (!src || jQuery.isObject
(src)) ) {
target[ name ] = jQuery.extend( deep, src || {}, copy );
}
Am I loosing my mind? :)
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/jquery-dev?hl=.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
[jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
PS: I do not see that Robert solution fails on empty function? aka :
function () { }
I think no one said that. I said that classes with no methods
(prototype with no properties) are not supported by my solution.
var Class = function(){};
var obj = new Class();
isObject( obj ) // true!
Class.prototype.someMethod = function(){};
isObject( obj ) // false
This is not so bed, because normally an class has at least one method.
If not, extending such object would not be so wrong...
Other thing to have in mind is that my solution is not immune by
Object.prototype extending, but for now jQuery is not immune on that
either.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
[jquery-dev] jQuery.extend(true, ...)
Wat a hell is going here?
// Recurse if we're merging object values
if ( deep copy typeof copy === object !copy.nodeType ) {
var clone;
if ( src ) {
clone = src;
} else if ( jQuery.isArray(copy) ) {
clone = [];
} else if ( jQuery.isObject(copy) ) {
clone = {};
} else {
clone = copy;
}
// Never move original objects, clone them
target[ name ] = jQuery.extend( deep, clone, copy );
You are going to extend with any object including a Date, a String, a
Number... (ah yes, excluding nodes).
You are going to extend (with) arrays? [1,2] and [4] to obtain [4,2].
Really?
If an object is not an array nor an object literal then extend object
with itself???
The only things to extend recursively are objects literals to me:
if ( deep copy jQuery.isObject(copy) (!src || jQuery.isObject
(src)) ) {
target[ name ] = jQuery.extend( deep, src || {}, copy );
}
Am I loosing my mind? :)
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
[jquery-dev] Re: jQuery.extend(true, ...)
I don't get your point. I am talking about what is extended
recursively, not what is passed as argument.
If you have something like this:
var options = {
nodes: jQuery(div),
num: 4,
date: new Date
};
jQuery.extend(true, options, {
nodes: jQuery(#content),
num: new Number(5),
date: new Date
});
then options.node would be the same jQuery(#content) object but now
with all jQuery methods copied inside itself, options.num will remain
4, options.date remain unchanged.
I think this behavior is not what someone would expect (I hope).
On Nov 11, 5:09 am, John Resig jere...@gmail.com wrote:
If someone wants to pass in a random object to be extended we won't
stop them. So yeah, someone could do:
jQuery.extend([1,2], [3]) and get [3,2] as a result - not sure why you
would want to, though. I can't think of a reason to explicitly prevent
this behavior, at least.
(On a related note I've renamed isObject to isObjectLiteral.)
--John
On Tue, Nov 10, 2009 at 9:10 PM, Robert Katić robert.ka...@gmail.com wrote:
Wat a hell is going here?
// Recurse if we're merging object values
if ( deep copy typeof copy === object !copy.nodeType ) {
var clone;
if ( src ) {
clone = src;
} else if ( jQuery.isArray(copy) ) {
clone = [];
} else if ( jQuery.isObject(copy) ) {
clone = {};
} else {
clone = copy;
}
// Never move original objects, clone them
target[ name ] = jQuery.extend( deep, clone, copy );
You are going to extend with any object including a Date, a String, a
Number... (ah yes, excluding nodes).
You are going to extend (with) arrays? [1,2] and [4] to obtain [4,2].
Really?
If an object is not an array nor an object literal then extend object
with itself???
The only things to extend recursively are objects literals to me:
if ( deep copy jQuery.isObject(copy) (!src || jQuery.isObject
(src)) ) {
target[ name ] = jQuery.extend( deep, src || {}, copy );
}
Am I loosing my mind? :)
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/jquery-dev?hl=.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
[jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
I noted that a test involves an myKlass with no methods. My solution of isObject will not pass that test. In isObjectLiteral gist there is no such test case, so I supposed that that case is negligible for reason: normally an class have methods, and detecting empty prototypes would complicate isObject a lot (http://gist.github.com/158651). So, I will suppose that unit test is wrong, for now, and I added an another patch to http://dev.jquery.com/ticket/5474 that corrects it. On Nov 8, 11:31 pm, John Resig jere...@gmail.com wrote: Thanks! On Sunday, November 8, 2009, Robert Katić robert.ka...@gmail.com wrote: http://dev.jquery.com/ticket/5474 On Nov 8, 2:13 pm, John Resig jere...@gmail.com wrote: constructor property is often changed. I hope you want isObject(jQuery()) == false. Yep, and that'll work as we expect it to. The one case where it won't is if you do obj.constructor = Object; If anyone thinks of an alternative solution please feel free to modify the gist and put your code up there - something that covers all the test cases would be great. --John -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/jquery-dev?hl=en. -- --John -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
Maybe something like http://gist.github.com/229188 would be enough.
On Nov 7, 12:57 am, John Resig jere...@gmail.com wrote:
Yehuda was working through that code and didn't get a chance to finish
it up. Yehuda, any thoughts?
--John
On Sat, Nov 7, 2009 at 12:05 AM, lrbabe lrb...@gmail.com wrote:
In the current implementation of jQuery.extend we can find the
following code:
// Recurse if we're merging object values
if ( deep copy typeof copy === object !copy.nodeType ) {
var clone;
if ( src ) {
clone = src;
} else if ( jQuery.isArray(copy) ) {
clone = [];
} else if ( jQuery.isObject(copy) ) {
clone = {};
} else {
clone = copy;
}
// Never move original objects, clone them
target[ name ] = jQuery.extend( deep, clone, copy );
}
If the first test passes, we know that copy is of type object. So what
is this jQuery.isObject exactly supposed to test?
It's probably meant to be more precise than the first test, excluding
objects such as new Date(). What is strange is that the current
implementation of isObject always returns false (and seems therefore
useless, as suggested inhttp://dev.jquery.com/ticket/4946) without
causing any test to fail, while replacing its code with
function( obj ) {
return Object.prototype.toString.call( obj );
}
will cause one test to fail (test 10 with custom objects)...
Could someone light me up?
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/jquery-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
Native functions in IE is not handled correctly by isFunction either, but it was decided that that cases are not significant... On Nov 8, 12:23 pm, DBJDBJ dbj...@gmail.com wrote: This version of isObject, in IE returns true, when tested with window.alert ... --DBJ -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
Right now the: return /^function Object/.test( obj.constructor ); solution works the best but it doesn't work in Opera Mini (which doesn't have function decompilation) - nor is it particularly fast. constructor property is often changed. I hope you want isObject(jQuery()) == false. -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
/^function Object/.test( jQuery().constructor ) == true You don't need to explicitly set constructor to change it. Redefining prototype, constructor is automatically altered (==Object). On Nov 8, 2:13 pm, John Resig jere...@gmail.com wrote: constructor property is often changed. I hope you want isObject(jQuery()) == false. Yep, and that'll work as we expect it to. The one case where it won't is if you do obj.constructor = Object; If anyone thinks of an alternative solution please feel free to modify the gist and put your code up there - something that covers all the test cases would be great. --John -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
http://gist.github.com/229254 On Nov 8, 2:13 pm, John Resig jere...@gmail.com wrote: constructor property is often changed. I hope you want isObject(jQuery()) == false. Yep, and that'll work as we expect it to. The one case where it won't is if you do obj.constructor = Object; If anyone thinks of an alternative solution please feel free to modify the gist and put your code up there - something that covers all the test cases would be great. --John -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
I thing so, but not sure 100%. This seam a good task for TestSwarms. On Nov 8, 4:38 pm, John Resig jere...@gmail.com wrote: http://gist.github.com/229254 Does this handle all the tests on that page? and in IE 6/7/8 as well? If so, let's land it. --John -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
http://browsershots.org/http://bender.fesb.hr/~robert/scripts/isObjectLiteral.html Let's see... On Nov 8, 4:42 pm, Robert Katić robert.ka...@gmail.com wrote: I thing so, but not sure 100%. This seam a good task for TestSwarms. On Nov 8, 4:38 pm, John Resig jere...@gmail.com wrote: http://gist.github.com/229254 Does this handle all the tests on that page? and in IE 6/7/8 as well? If so, let's land it. --John -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
Yes, it passes all these tests. On Nov 8, 4:57 pm, John Resig jere...@gmail.com wrote: I thing so, but not sure 100%. This seam a good task for TestSwarms. Well, we can do that eventually - but in the short term: Does it work on IE? --John -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Why use jQuery.isObject in jQuery.extend
http://dev.jquery.com/ticket/5474 On Nov 8, 2:13 pm, John Resig jere...@gmail.com wrote: constructor property is often changed. I hope you want isObject(jQuery()) == false. Yep, and that'll work as we expect it to. The one case where it won't is if you do obj.constructor = Object; If anyone thinks of an alternative solution please feel free to modify the gist and put your code up there - something that covers all the test cases would be great. --John -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Will the live() method be improved in 1.4?
I opened a ticket: http://dev.jquery.com/ticket/5470
with link on commit.
Commit also includes context inside liveHandler (it is a too small
change to make a separate commit).
Component is unfiled. Please tell me if I made mistakes opening this
ticket.
On Nov 6, 3:01 pm, John Resig jere...@gmail.com wrote:
1. Calling closest, context argument still is not used.
I was unable to find the proper ticket. Would I open one?
2. Storing how much a parent is close to an element with data API is
an big overhead. An jQuery.lastCloser or something similar would be
enough. Also it would speed up sorting inside liveHandler with
somethin like this:
...
elems.push({ elem: elem, fn: fn, closer: jQuery.lastCloser });
elems.sort(function( a, b ) {
return a.closer - b.closer;
});
I'd appreciate tickets/patches for both of these - they both sound
like great additions.
--John
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Will the live() method be improved in 1.4?
oops: evaluated without context
On Nov 8, 12:48 am, Robert Katić robert.ka...@gmail.com wrote:
I detect only now that in closest method the selector is evaluated
without selector.
I am not sure which context is more correct: (context || this.context)
or it have to be a document?
PS: It is not completely clear to me why selectors with positions can
not be handled by multiFilter in this situation.
On Nov 7, 5:58 pm, John Resig jere...@gmail.com wrote:
I've already landed the commits - looks great - thanks! (I'll close
the ticket once my network stops flaking out.)
--John
On Sat, Nov 7, 2009 at 5:47 PM, Robert Katić robert.ka...@gmail.com wrote:
I opened a ticket:http://dev.jquery.com/ticket/5470
with link on commit.
Commit also includes context inside liveHandler (it is a too small
change to make a separate commit).
Component is unfiled. Please tell me if I made mistakes opening this
ticket.
On Nov 6, 3:01 pm, John Resig jere...@gmail.com wrote:
1. Calling closest, context argument still is not used.
I was unable to find the proper ticket. Would I open one?
2. Storing how much a parent is close to an element with data API is
an big overhead. An jQuery.lastCloser or something similar would be
enough. Also it would speed up sorting inside liveHandler with
somethin like this:
...
elems.push({ elem: elem, fn: fn, closer: jQuery.lastCloser });
elems.sort(function( a, b ) {
return a.closer - b.closer;
});
I'd appreciate tickets/patches for both of these - they both sound
like great additions.
--John
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/jquery-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Will the live() method be improved in 1.4?
I wonder why there would be an $.live with document as the only interesting context. Something like $(document).zombi(selector, type, ...) would be more flexible (I know, zombi is not nice, but I have no inspirations about a more suitable name). To avoid to repeat selector on multiple bindings, I suggest something like: $(document).make(selector) .zombi(type, ...) .zombi(type, ...) An possible implementation of that: http://gist.github.com/227508 Maybe this is only a silly idea for majority of users (now), but I am really of idea that this have even more sense then the current $.fn.live. On Nov 5, 2:44 am, xwisdom xwis...@gmail.com wrote: Hello, Just wondering if version 1.4 will include improvements to live() events. See example here:http://www.zachleat.com/web/2009/05/08/performance-caveat-with-jquery... -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
Meyer, delegate was my first candidate too but I was worry that it was overused :). Seams that I was wrong. Will update it with delegate ASAP. --Robert On 6. stu. 2009., at 02:42, Justin Meyer justinbme...@gmail.com wrote: How about $(#something).delegate(.thing,click, func). It almost makes too much sense :). On Nov 5, 6:31 pm, Robert Katić robert.ka...@gmail.com wrote: I wonder why there would be an $.live with document as the only interesting context. Something like $(document).zombi(selector, type, ...) would be more flexible (I know, zombi is not nice, but I have no inspirations about a more suitable name). To avoid to repeat selector on multiple bindings, I suggest something like: $(document).make(selector) .zombi(type, ...) .zombi(type, ...) An possible implementation of that:http://gist.github.com/227508 Maybe this is only a silly idea for majority of users (now), but I am really of idea that this have even more sense then the current $.fn.live. On Nov 5, 2:44 am, xwisdom xwis...@gmail.com wrote: Hello, Just wondering if version 1.4 will include improvements to live() events. See example here:http://www.zachleat.com/web/2009/05/08/ performance-caveat-with-jquery... -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en . -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
$(#someRootTable).delegate(td.foo, click, function(e){
// Your code goes here.
});
Would be easer and safer because the event will be handlet only by
td.foo elements inside #someRootTable.
--Robert
On 6. stu. 2009., at 04:56, John Resig jere...@gmail.com wrote:
$(#someRootTable).click(function(e){
$(e.target).closest(td.foo).each(function(){
// Your code goes here.
});
});
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
I suppose you will need an return false; too at the end of the
handler...
--Robert
On 6. stu. 2009., at 05:29, John Resig jere...@gmail.com wrote:
If you want to limit, just do this (using the nightlies):
$(#someRootTable).click(function(e){
$(e.target).closest(td.foo, this).each(function(){
// Your code goes here.
});
});
Still pretty simple and requires no additional functionality. I may
just write this up as an example and add it to the live and closest
docs.
--John
On Fri, Nov 6, 2009 at 5:22 AM, Robert Katić robert.ka...@gmail.com
wrote:
$(#someRootTable).delegate(td.foo, click, function(e){
// Your code goes here.
});
Would be easer and safer because the event will be handlet only by
td.foo
elements inside #someRootTable.
--Robert
On 6. stu. 2009., at 04:56, John Resig jere...@gmail.com wrote:
$(#someRootTable).click(function(e){
$(e.target).closest(td.foo).each(function(){
// Your code goes here.
});
});
--
You received this message because you are subscribed to the Google
Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
You received this message because you are subscribed to the Google
Groups jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: Will the live() method be improved in 1.4?
No you will not. My Mistake
--Robert
On 6. stu. 2009., at 05:29, John Resig jere...@gmail.com wrote:
If you want to limit, just do this (using the nightlies):
$(#someRootTable).click(function(e){
$(e.target).closest(td.foo, this).each(function(){
// Your code goes here.
});
});
Still pretty simple and requires no additional functionality. I may
just write this up as an example and add it to the live and closest
docs.
--John
On Fri, Nov 6, 2009 at 5:22 AM, Robert Katić robert.ka...@gmail.com
wrote:
$(#someRootTable).delegate(td.foo, click, function(e){
// Your code goes here.
});
Would be easer and safer because the event will be handlet only by
td.foo
elements inside #someRootTable.
--Robert
On 6. stu. 2009., at 04:56, John Resig jere...@gmail.com wrote:
$(#someRootTable).click(function(e){
$(e.target).closest(td.foo).each(function(){
// Your code goes here.
});
});
--
You received this message because you are subscribed to the Google
Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
You received this message because you are subscribed to the Google
Groups jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Will the live() method be improved in 1.4?
Regarding improving live(), I would note two things about liveHandler:
1. Calling closest, context argument still is not used.
I was unable to find the proper ticket. Would I open one?
2. Storing how much a parent is close to an element with data API is
an big overhead. An jQuery.lastCloser or something similar would be
enough. Also it would speed up sorting inside liveHandler with
somethin like this:
...
elems.push({ elem: elem, fn: fn, closer: jQuery.lastCloser });
elems.sort(function( a, b ) {
return a.closer - b.closer;
});
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: $(0) inconsistent with $(1), $(2)
Well if $() is same as $([]), then instead of
if ( !selector ) {
return this;
}
in $.fn.init, we can put
if ( selector == null ) {
return this;
}
This would eliminate the $(0) unexpected behavior.
On Nov 1, 3:28 pm, John Resig jere...@gmail.com wrote:
This changed slightly in the latest nightlies - if you do $(0) it'll
be as if you did $() or $([]). As of now any false-ish value will give
you an empty jQuery set.
Considering that there is no intended behavior for passing in a number
to the jQuery object this seems fine to me.
I'm curious - why were you passing in a number to the jQuery object? I
could sort of, kind of, understand passing in an array of values - but
just one number doesn't make sense.
--John
On Sat, Oct 31, 2009 at 9:16 PM, Xavier Shay xavier.s...@gmail.com wrote:
$(0).get(0)
Document
$(1).get(0)
1
$(2).get(0)
2
Why does $(0) return a document? Is this intended behaviour? I would
expect it to return 0.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/jquery-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: $.fn.add(selector) and context
Ticket: http://dev.jquery.com/ticket/5434
On Oct 30, 3:33 pm, John Resig jere...@gmail.com wrote:
This seems reasonable, as well. Can you file a ticket? Thanks.
--John
On Fri, Oct 30, 2009 at 2:06 AM, Robert Katić robert.ka...@gmail.com wrote:
Sorry, I posted an old version of code. Here the new one:
jQuery.fn.add = function( selector, context ) {
return this.pushStack( jQuery.unique( jQuery.merge(
this.get(),
typeof selector === string ?
jQuery( selector, context
|| this.context (this.context.ownerDocument ||
this.context)
|| this[0] (this[0].ownerDocument || this[0]) ) :
jQuery.makeArray( selector )
)));
};
On Oct 30, 6:55 am, Robert Katić robert.ka...@gmail.com wrote:
Using $.fn.add(selector) the context property remains the same.
It's ok, but the given selector will be applied always with the
default context (document).
This is not correct for me if we are using jQuery with xml documents
for example.
$(user, xmlDoc).add(lusers);
There is no way to add lusers of the xmlDoc document!
Here an optional context argument would be useful:
$(user, xmlDoc).add(lusers, xmlDoc);
But even this is not ideal for me. If the context argument is not
given (first example), which document would be used?
I suppose the obvious answer is xmlDoc.
An corrected implementation of add() would be something like this:
jQuery.fn.add = function( selector ) {
return this.pushStack( jQuery.unique( jQuery.merge(
this.get(),
typeof selector === string ?
jQuery( selector, (this.context || this[0] ||
0).ownerDocument ) :
jQuery.makeArray( selector )
)));
};
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/jquery-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: $(nodeList) and comment nodes
The main culprit of these problems is probably jQuery.makeArray.
It is supposed to convert anything to an array, but how about
NodeLists?
Maybe jQuery.makeArray have to call jQuery.merge internally if a
NodeList is given?
If so, then an jQuery.isNodeList is needed, I suppose.
On Oct 30, 5:01 pm, John Resig jere...@gmail.com wrote:
Eww... It must've been accidentally cut in the last release - but we
didn't notice because the worst case is only a minor perf hit. Well,
it makes it pretty easy to actually just remove it then! (Especially
if the only place where it's being used internally is in this
soon-to-be-stripped method.)
I'll be sure to revise the docs when I make the cut as well.
--John
On Fri, Oct 30, 2009 at 11:52 AM, Karl Swedberg k...@englishrules.com wrote:
I came across an oddity with jQuery.merge from a completely different route
-- looking through jQuery.support properties. It looks like jQuery.merge is
testing for jQuery.support.getAll, but I can't for the life of me find
anywhere in the source where jQuery.support.getAll is being defined.
Since jQuery.support.getAll is never true (because it's not defined),
comments are always excluded ( if ( elem.nodeType !== 8 ) ).
Did jQuery at one point define jQuery.support.getAll? And if so, what was it
based on?
from core.js line 442 (in github version just pulled this morning):
merge: function( first, second ) {
// We have to loop this way because IE Opera overwrite the length
// expando of getElementsByTagName
var i = 0, elem, pos = first.length;
// Also, we need to make sure that the correct elements are being returned
// (IE returns comment nodes in a '*' query)
if ( !jQuery.support.getAll ) {
while ( (elem = second[ i++ ]) != null ) {
if ( elem.nodeType !== 8 ) {
first[ pos++ ] = elem;
}
}
} else {
while ( (elem = second[ i++ ]) != null ) {
first[ pos++ ] = elem;
}
}
return first;
}
--Karl
Karl Swedberg
www.englishrules.com
www.learningjquery.com
On Oct 30, 2009, at 10:31 AM, John Resig wrote:
I think you're right here - I'm not completely convinced that this
distinction still needs to exist. Could you file a ticket? Thanks.
--John
On Fri, Oct 30, 2009 at 7:47 AM, Robert Katić robert.ka...@gmail.com
wrote:
To be more accurate,
$([]).add( nodeList )
can not contains comment nodes only on IE.
This makes it even more ambiguous, with unexpected results.
Also it seams that the only expected NodeList is from an
getElementsByTagName.call.
I know that it is not explicitly supported by the API, but even then
it seams that there are some inconsistent logic.
On Oct 30, 6:28 am, Robert Katić robert.ka...@gmail.com wrote:
jQuery.merge() is the only function that discards comment nodes (?).
This means that
$( nodeList )
can contains comment nodes, but
$([]).add( nodeList )
can not.
Why such different behaviors?
Is the jQuery.makeArray() more appropriate to filter comment nodes?
Am I missing something here?
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: $.fn.add(selector) and context
Sorry, I posted an old version of code. Here the new one:
jQuery.fn.add = function( selector, context ) {
return this.pushStack( jQuery.unique( jQuery.merge(
this.get(),
typeof selector === string ?
jQuery( selector, context
|| this.context (this.context.ownerDocument ||
this.context)
|| this[0] (this[0].ownerDocument || this[0]) ) :
jQuery.makeArray( selector )
)));
};
On Oct 30, 6:55 am, Robert Katić robert.ka...@gmail.com wrote:
Using $.fn.add(selector) the context property remains the same.
It's ok, but the given selector will be applied always with the
default context (document).
This is not correct for me if we are using jQuery with xml documents
for example.
$(user, xmlDoc).add(lusers);
There is no way to add lusers of the xmlDoc document!
Here an optional context argument would be useful:
$(user, xmlDoc).add(lusers, xmlDoc);
But even this is not ideal for me. If the context argument is not
given (first example), which document would be used?
I suppose the obvious answer is xmlDoc.
An corrected implementation of add() would be something like this:
jQuery.fn.add = function( selector ) {
return this.pushStack( jQuery.unique( jQuery.merge(
this.get(),
typeof selector === string ?
jQuery( selector, (this.context || this[0] ||
0).ownerDocument ) :
jQuery.makeArray( selector )
)));
};
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Should $.map() also work for objects?
But making map() functions work on hashes makes sense, so why rule them out? There are at least three reasons why this is not a good idea: 1. $.map() is not a real general purpose map function. If callback returns an array then its items will be values because in same cases it is convenient that a callback can returns multiple values. So if you make $.map() generic for all hashes than you would $.map() generic for all sequences too. 2. If you make $.map() working with hashes too, then you have to detect which object is a hash and which is a sequence. The only think to do that is to check if the object.length is a number - weak! 3. for(var k in obj) newobj[k] = fn(obj[k]) -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Should $.map() also work for objects?
var hash = { a: 1, b: 2 }
$.map( hash, function( val, key ) {
if( key === 'a')
return { c: 3, d: 4 };
else
return val;
});
And now hash is { c: 3, d: 4, b: 2 }. It doesn't conflict with
anything.
Can you explain which objects you expect would extend the final
object, and which object would not?
(nodes are objects too)
Actually, you don't have to differentiate between hashes and sequences
in js:
if( typeof arr === 'object' )
for( var key in arr)
For sequences, the key will be 0, 1, 2 and so on. If you want to be
strict, you can rule out regexps:
if( typeof arr === 'object' arr.constructor !== RegExp )
This is so wrong.
Maybe you can expect indexes in numerical order for Arrays, but still
Array.prototype is to often extended.
Also we have to iterate like sequence any array-like object (jQuery
objects, NodeLists,...).
...
3. for(var k in obj) newobj[k] = fn(obj[k])
Like I said, it doesn't have the benefit of scoping.
If your argument is scoping, it is not enough.
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: $(nodeList) and comment nodes
To be more accurate, $([]).add( nodeList ) can not contains comment nodes only on IE. This makes it even more ambiguous, with unexpected results. Also it seams that the only expected NodeList is from an getElementsByTagName.call. I know that it is not explicitly supported by the API, but even then it seams that there are some inconsistent logic. On Oct 30, 6:28 am, Robert Katić robert.ka...@gmail.com wrote: jQuery.merge() is the only function that discards comment nodes (?). This means that $( nodeList ) can contains comment nodes, but $([]).add( nodeList ) can not. Why such different behaviors? Is the jQuery.makeArray() more appropriate to filter comment nodes? Am I missing something here? -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Should $.map() also work for objects?
I think it should make the following expression evaluate to true: object object.constructor === Object ( I'm not sure if it's strict enough, but what I mean is that the object should be constructed by Object ) This is technically a more complex problem then you think. There was an John initiative to evolve an isObjectLiteral(obj) http://gist.github.com/153271 I made an solution for it at http://gist.github.com/158651 that passes all tests, but that shows how it complex it is too. I think it would be an overhead. We have to avoid to make this stuffs.. I think Array.prototype should never be extended, if it does, $.extend () is the first one to be broken (at least for jQuery 1.3.2). No. It array-like objects and other ones in different ways. As for array-like objects, you can see how $.each() is implemented (I think it's like a convention that if an object conforms the condition I mentioned before, and has a length property, it should be treated like an array) I know exactly the $.each() implementation, and how I said, the only way to detect array-like objects is to check the length property. It is weak, but in case of $.each you normally know exactly witch proprieties has an object. -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Should $.map() also work for objects?
Be warned that $.map() is designed to work on a sequence of DOM
elements. Although it would work with other values too, callback
results are not handled as you probably expect: null and undefined
values are discarded and arrays are merged to the final array.
In your case an classic for(key in obj) would be more appropriate, I
think.
On Oct 29, 9:56 am, gMinuses gminu...@gmail.com wrote:
I'm not sure if it's necessary, but I feel It'd be nice that we can
pass an object to $.map(), so that jquery will iterate over it's
properties and modifies values by calling the callback function:
var obj = { a: function() { alert(1) }, b: function() { alert(2) } };
$.map( obj, function( value, key ) {
return function() {
// Call old function
value();
// Do something else;
};
})
If the idea is redundant because of my lack of knowledge, please let
me know how to do it natively, thanks. ( If you are going to suggest
for( in ) , I think it doesn't have the benefit of scoping )
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: Should $.map() also work for objects?
Be warned that $.map() is designed to work on a sequence of DOM
elements. Although it would work with other values too, callback
results are not handled as you probably expect: null and undefined
values are discarded and arrays are merged to the final array.
In your case an classic for(key in obj) would be more appropriate, I
think.
On Oct 29, 9:56 am, gMinuses gminu...@gmail.com wrote:
I'm not sure if it's necessary, but I feel It'd be nice that we can
pass an object to $.map(), so that jquery will iterate over it's
properties and modifies values by calling the callback function:
var obj = { a: function() { alert(1) }, b: function() { alert(2) } };
$.map( obj, function( value, key ) {
return function() {
// Call old function
value();
// Do something else;
};
})
If the idea is redundant because of my lack of knowledge, please let
me know how to do it natively, thanks. ( If you are going to suggest
for( in ) , I think it doesn't have the benefit of scoping )
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] $(nodeList) and comment nodes
jQuery.merge() is the only function that discards comment nodes (?). This means that $( nodeList ) can contains comment nodes, but $([]).add( nodeList ) can not. Why such different behaviors? Is the jQuery.makeArray() more appropriate to filter comment nodes? Am I missing something here? -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] $.fn.add(selector) and context
Using $.fn.add(selector) the context property remains the same.
It's ok, but the given selector will be applied always with the
default context (document).
This is not correct for me if we are using jQuery with xml documents
for example.
$(user, xmlDoc).add(lusers);
There is no way to add lusers of the xmlDoc document!
Here an optional context argument would be useful:
$(user, xmlDoc).add(lusers, xmlDoc);
But even this is not ideal for me. If the context argument is not
given (first example), which document would be used?
I suppose the obvious answer is xmlDoc.
An corrected implementation of add() would be something like this:
jQuery.fn.add = function( selector ) {
return this.pushStack( jQuery.unique( jQuery.merge(
this.get(),
typeof selector === string ?
jQuery( selector, (this.context || this[0] ||
0).ownerDocument ) :
jQuery.makeArray( selector )
)));
};
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: $.data(elem) API changed in 1.4pre ?
I played a little on some variations of $.data() API and concluded with these: $.data(elem, readOnly) - http://pastebin.com/f323becaa $.data(elem, name) - http://pastebin.com/f498f9a65 $.data(elem, name, data) - http://pastebin.com/f6b474da8 I didn't tested/profiled it yet, but if we consider $.data() a low level part of API, then I prefer firs version. Opinions? On Oct 18, 2:57 am, Robert Katić robert.ka...@gmail.com wrote: Yes there is a big error in my code. Here is new onehttp://pastebin.com/d66929de4 On Oct 18, 1:27 am, Robert Katić robert.ka...@gmail.com wrote: If I was not clear enough here are some codehttp://pastebin.com/m14c0aa3b PS: For now, I am not sure if new Number(...) is necessary and that it is safe enough. On Oct 18, 1:05 am, Robert Katić robert.ka...@gmail.com wrote: I am certainly in favor to that that $.data(elem) returns data object instead of id. I would like that $.data() will not handle getting/setting too, but then we would probably consider how to handle getting without generating the data object. Maybe an $.data(elem, true) to get data object without creating it? Because I wouldn't like to be forced to use $(elem).data(prop) only because $.fn.data() prevents unnecessary data creations and $.data() not. On Oct 17, 3:40 am, John Resig jere...@gmail.com wrote: Of course, although it would simplify the $.data() implementation (speed performances too) it would breaks compatibility with many existent plugins. However, $.data() in 1.4 will breaks it already... If developers want to switch to this style they're absolutely welcome to (in fact, we already have in jQuery core for performance advantages, in a number of places). I've done a quick search on Google Code Search and have only found a couple places where jQuery.data(elem) is used (outside of jQuery itself). Right now I'm leaning towards keeping the API change (especially since the alternative would be pretty lame - like doing jQuery.data(elem, true) or some such) but if the change is too bad then we can always reconsider. I should note that in jQuery 1.4 you can do $(elem).data() to get at the element's data, no problem (there was no API conflict for that method). --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.data(elem) API changed in 1.4pre ?
Andrea, IE is nor open source, so I can not be sure if new Number is 100% safe as element property. Some testing if it produces memory leak would help here. On Oct 18, 11:18 am, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Robert new Number is simply for a reason, in IE: var div = document.createElement(div); div.whatever = 1; alert(div.outerHTML); // DIV whatever=1/DIV div.removeAttribute(whatever); div.whatever = new Number(1); alert(div.outerHTML); // DIV/DIV if there are no side effects I can't see why DIV should be dirty in IE. Also via new Number the behavior is a bit more standard (Firefox and other like) On Sun, Oct 18, 2009 at 1:27 AM, Robert Katić robert.ka...@gmail.comwrote: If I was not clear enough here are some codehttp://pastebin.com/m14c0aa3b PS: For now, I am not sure if new Number(...) is necessary and that it is safe enough. On Oct 18, 1:05 am, Robert Katić robert.ka...@gmail.com wrote: I am certainly in favor to that that $.data(elem) returns data object instead of id. I would like that $.data() will not handle getting/setting too, but then we would probably consider how to handle getting without generating the data object. Maybe an $.data(elem, true) to get data object without creating it? Because I wouldn't like to be forced to use $(elem).data(prop) only because $.fn.data() prevents unnecessary data creations and $.data() not. On Oct 17, 3:40 am, John Resig jere...@gmail.com wrote: Of course, although it would simplify the $.data() implementation (speed performances too) it would breaks compatibility with many existent plugins. However, $.data() in 1.4 will breaks it already... If developers want to switch to this style they're absolutely welcome to (in fact, we already have in jQuery core for performance advantages, in a number of places). I've done a quick search on Google Code Search and have only found a couple places where jQuery.data(elem) is used (outside of jQuery itself). Right now I'm leaning towards keeping the API change (especially since the alternative would be pretty lame - like doing jQuery.data(elem, true) or some such) but if the change is too bad then we can always reconsider. I should note that in jQuery 1.4 you can do $(elem).data() to get at the element's data, no problem (there was no API conflict for that method). --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.data(elem) API changed in 1.4pre ?
I am certainly in favor to that that $.data(elem) returns data object instead of id. I would like that $.data() will not handle getting/setting too, but then we would probably consider how to handle getting without generating the data object. Maybe an $.data(elem, true) to get data object without creating it? Because I wouldn't like to be forced to use $(elem).data(prop) only because $.fn.data() prevents unnecessary data creations and $.data() not. On Oct 17, 3:40 am, John Resig jere...@gmail.com wrote: Of course, although it would simplify the $.data() implementation (speed performances too) it would breaks compatibility with many existent plugins. However, $.data() in 1.4 will breaks it already... If developers want to switch to this style they're absolutely welcome to (in fact, we already have in jQuery core for performance advantages, in a number of places). I've done a quick search on Google Code Search and have only found a couple places where jQuery.data(elem) is used (outside of jQuery itself). Right now I'm leaning towards keeping the API change (especially since the alternative would be pretty lame - like doing jQuery.data(elem, true) or some such) but if the change is too bad then we can always reconsider. I should note that in jQuery 1.4 you can do $(elem).data() to get at the element's data, no problem (there was no API conflict for that method). --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.data(elem) API changed in 1.4pre ?
If I was not clear enough here are some code http://pastebin.com/m14c0aa3b PS: For now, I am not sure if new Number(...) is necessary and that it is safe enough. On Oct 18, 1:05 am, Robert Katić robert.ka...@gmail.com wrote: I am certainly in favor to that that $.data(elem) returns data object instead of id. I would like that $.data() will not handle getting/setting too, but then we would probably consider how to handle getting without generating the data object. Maybe an $.data(elem, true) to get data object without creating it? Because I wouldn't like to be forced to use $(elem).data(prop) only because $.fn.data() prevents unnecessary data creations and $.data() not. On Oct 17, 3:40 am, John Resig jere...@gmail.com wrote: Of course, although it would simplify the $.data() implementation (speed performances too) it would breaks compatibility with many existent plugins. However, $.data() in 1.4 will breaks it already... If developers want to switch to this style they're absolutely welcome to (in fact, we already have in jQuery core for performance advantages, in a number of places). I've done a quick search on Google Code Search and have only found a couple places where jQuery.data(elem) is used (outside of jQuery itself). Right now I'm leaning towards keeping the API change (especially since the alternative would be pretty lame - like doing jQuery.data(elem, true) or some such) but if the change is too bad then we can always reconsider. I should note that in jQuery 1.4 you can do $(elem).data() to get at the element's data, no problem (there was no API conflict for that method). --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.data(elem) API changed in 1.4pre ?
Yes there is a big error in my code. Here is new one http://pastebin.com/d66929de4 On Oct 18, 1:27 am, Robert Katić robert.ka...@gmail.com wrote: If I was not clear enough here are some codehttp://pastebin.com/m14c0aa3b PS: For now, I am not sure if new Number(...) is necessary and that it is safe enough. On Oct 18, 1:05 am, Robert Katić robert.ka...@gmail.com wrote: I am certainly in favor to that that $.data(elem) returns data object instead of id. I would like that $.data() will not handle getting/setting too, but then we would probably consider how to handle getting without generating the data object. Maybe an $.data(elem, true) to get data object without creating it? Because I wouldn't like to be forced to use $(elem).data(prop) only because $.fn.data() prevents unnecessary data creations and $.data() not. On Oct 17, 3:40 am, John Resig jere...@gmail.com wrote: Of course, although it would simplify the $.data() implementation (speed performances too) it would breaks compatibility with many existent plugins. However, $.data() in 1.4 will breaks it already... If developers want to switch to this style they're absolutely welcome to (in fact, we already have in jQuery core for performance advantages, in a number of places). I've done a quick search on Google Code Search and have only found a couple places where jQuery.data(elem) is used (outside of jQuery itself). Right now I'm leaning towards keeping the API change (especially since the alternative would be pretty lame - like doing jQuery.data(elem, true) or some such) but if the change is too bad then we can always reconsider. I should note that in jQuery 1.4 you can do $(elem).data() to get at the element's data, no problem (there was no API conflict for that method). --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $.data(elem) API changed in 1.4pre ?
Hi Andrea. Nice solution. Using array instead of object is a nice speed boost (at least on Fx 3.5). However, I suppose that an _index will not be necessary in jQuery. Honestly I consider that $.data() would be exactly as your $.proxy() (the simpler one). Now that $.data returns the data object of an element, it doesn't need to handle setting/getting values too. $.data(node)[name] = value; is even more concise then: $.data(node, name, value); Of course, although it would simplify the $.data() implementation (speed performances too) it would breaks compatibility with many existent plugins. However, $.data() in 1.4 will breaks it already... On Oct 15, 3:43 am, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Hi John. This expando and node object relations is something I am kinda dealing with every day. I have not read jQuery 1.4 solution yet but I wonder if my latest post, created for this occasion, could give jQuery some good advice/suggestion. http://webreflection.blogspot.com/2009/10/dom-node-proxy.html Regards On Wed, Oct 14, 2009 at 5:40 PM, John Resig jere...@gmail.com wrote: Hi Mark - This was intentional. We could no longer guarantee that an ID would be attached for an element at all times (which is what was done before). Additionally calling that method would attach an expando and object to an empty element - even if no data needed to be stored (which is bad). Almost universally the use of $.data(elem) was used to get at the entirety of an element's data collection - which is what is now returned from $.data(elem) instead. Looking at the tabs code it looks like they're using it to generate a unique ID (but it's not clear as to why they need $.data for this - they could, just as easily, keep a global ID counter and assign it to the element if it doesn't have one, already. There's no need to attach an entire data object just to get at that information. As it stands the next version of jQuery UI will require jQuery 1.4 so this is definitely one place where we could make that clean break. If it does become problematic, though (especially for other plugins), then we could look into ways of changing it. --John On Wed, Oct 14, 2009 at 10:24 AM, Mark Gibson jollyt...@gmail.com wrote: Hi, I've noticed that the behaviour of $.data() has changed in 1.4pre, $.data(elem) no longer returns the cache id, it returns all the data items or null. this will probably break a lot of code (already breaks jQuery UI Tabs) Is this intentional, or a bug? - Mark. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: event.remove/handle() bug with namespaced events?
Ticked opened: http://dev.jquery.com/ticket/5303
On Sep 17, 5:31 pm, Robert Katić robert.ka...@gmail.com wrote:
?
On Aug 27, 4:32 am, Robert Katić robert.ka...@gmail.com wrote:
I suppose it is rear to use multiple namespaces to unbind aneventand
that it is the reason why no one spotted this bug (I spotted it by
examining code, not by using the feature).
This is the problem:
$(div).bind(click.aaa.bbb, function(){...});
$(div).unbind(click.a.bbb); //this is unbinding the previous
bind!!!
Now someone would suppose: Well it seams fine, there is .bbb so it
will unbind click.aaa.bbb too, but it is not true:
$(div).unbind(click.bbb.other) // will not unbind click.aaa.bbb
The problem seams to be the generated regexp intoevent.remove()
andevent.handle():
var namespace = RegExp((^|\\.) + namespaces.slice().sort().join(.*\
\.) + (\\.|$));
that for me would be:
var namespace = RegExp((^|\\.) + namespaces.slice().sort().join(\\.
(?:.*\\.)?) + (\\.|$));
Am I missing something here?
Here is a test-casehttp://jsbin.com/aledo
And here is the same case with the correctedevent.remove()
function:http://jsbin.com/eqofo
(I hope jsbin.com has no problems any more)
Will I open a ticket?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: event.remove/handle() bug with namespaced events?
?
On Aug 27, 4:32 am, Robert Katić robert.ka...@gmail.com wrote:
I suppose it is rear to use multiple namespaces to unbind aneventand
that it is the reason why no one spotted this bug (I spotted it by
examining code, not by using the feature).
This is the problem:
$(div).bind(click.aaa.bbb, function(){...});
$(div).unbind(click.a.bbb); //this is unbinding the previous
bind!!!
Now someone would suppose: Well it seams fine, there is .bbb so it
will unbind click.aaa.bbb too, but it is not true:
$(div).unbind(click.bbb.other) // will not unbind click.aaa.bbb
The problem seams to be the generated regexp intoevent.remove()
andevent.handle():
var namespace = RegExp((^|\\.) + namespaces.slice().sort().join(.*\
\.) + (\\.|$));
that for me would be:
var namespace = RegExp((^|\\.) + namespaces.slice().sort().join(\\.
(?:.*\\.)?) + (\\.|$));
Am I missing something here?
Here is a test-casehttp://jsbin.com/aledo
And here is the same case with the correctedevent.remove()
function:http://jsbin.com/eqofo
(I hope jsbin.com has no problems any more)
Will I open a ticket?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: detecting jQuery objects constructor property
if ( obj.jquery ) //obj is an jQuery object jquery property gives the jQuery version, that is always an non empty string On Sep 18, 1:50 am, lrbabe lrb...@gmail.com wrote: mmmh... overwriting the constructor property doesn't sound like a great idea to me. What about all the code that has been written by developers expecting the constructor to be what it is supposed to be: Object You could use other particular properties of any jQuery object: they are not arrays but they have a length property: !$.isArray($obj) ($obj.length !== undefined) It is not perfect but it can help. On Sep 17, 8:04 pm, Nico nicolas.deve...@gmail.com wrote: Hi, I first posted this message on the jquery-en group, but it should probably be posted here, so here am I. In some cases, I have to check if a variable is a jQuery object or not. Usually, to check a variable type, I use the constructor property (when I can't use typeof, which is not accurate). In case of jQuery, the constructor property equals Object, so I can't use it. When I create a jQuery Object, it's known by javascript as an object, and it behaves like a function. Would it be possible to add something so we could get a true with this example : $([]).constructor === jQuery This would be great, no ?? The only change to do is to add in the beginning of jQuery.fn.init method the line : this.constructor = jQuery; This way, all jQuery's objects constructor property equals jQuery. I quickly tried this, and I met no bugs. Any arguments against this ? Nico --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] event.remove() bug with multiple namespaces?
I suppose it is rear to use multiple namespaces to unbind an event and
that it is the reason why no one spotted this bug (I spotted it by
examining code, not by using the feature).
This is the problem:
$(div).bind(click.aaa.bbb, function(){...});
$(div).unbind(click.a.bbb); //this is unbinding the previous
bind!!!
Here is a test-case http://jsbin.com/aledo
And here is the same case with the corrected even.remove() function:
http://jsbin.com/eqofo
(I hope jsbin.com has no more problems)
Will I open a ticket?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] event.remove/handle() bug with namespaced events?
I suppose it is rear to use multiple namespaces to unbind an event and
that it is the reason why no one spotted this bug (I spotted it by
examining code, not by using the feature).
This is the problem:
$(div).bind(click.aaa.bbb, function(){...});
$(div).unbind(click.a.bbb); //this is unbinding the previous
bind!!!
Now someone would suppose: Well it seams fine, there is .bbb so it
will unbind click.aaa.bbb too, but it is not true:
$(div).unbind(click.bbb.other) // will not unbind click.aaa.bbb
The problem seams to be the generated regexp into event.remove() and
event.handle():
var namespace = RegExp((^|\\.) + namespaces.slice().sort().join(.*\
\.) + (\\.|$));
that for me would be:
var namespace = RegExp((^|\\.) + namespaces.slice().sort().join(\\.
(?:.*\\.)?) + (\\.|$));
Am I missing something here?
Here is a test-case http://jsbin.com/aledo
And here is the same case with the corrected event.remove() function:
http://jsbin.com/eqofo
(I hope jsbin.com has no problems any more)
Will I open a ticket?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: eq(-1) - negative numbers take from end of collection
Actually the ticket about .get(-1) (http://dev.jquery.com/ticket/4188) (opened by me), have changes about eq(-1) too. I was wondering why it was ignored. On Aug 14, 2:19 pm, John Resig jere...@gmail.com wrote: I don't see why not - we already support .get(-1), .eq(-1) makes sense. Want to file a feature ticket for it? --John On Fri, Aug 14, 2009 at 2:34 AM, James Padolsey jamespadol...@googlemail.com wrote: Would this be a possibility? It would be nice if it worked like JavaScript's Array methods, whereby passing a negative number indicates a position from the end of the array. So, with the following collection: [a/, div/, span/] eq(-1) would return span/, eq(-2) would return div/... This could be added for the .eq() method and the selector-expression (:eq(..)). Just an idea... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: prototypal inheritance as part of jQuery core?
Test http://pastebin.com/m5279ff23 jquery.ns.js http://pastebin.com/m36dd0f2 Testing it on other browsers http://browsershots.org/http://bender.fesb.hr/~robert/scripts/test-jquery.ns.js.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: prototypal inheritance as part of jQuery core?
@tres
You made me thinking about namespaces a lot today.
I implemented a solution.
http://bender.fesb.hr/~robert/scripts/jquery.ns.js
Namespaces are not equal to modules. Inner namespaces can access to
outer namespaces.
'That means that any namespace can directly do DOM stuff for
example...
Here some tests http://jsbin.com/oviri/edit.
Please, feel free to do testing and writing more tests.
I made some tests on Firefox3.5, Chrome, Safari4, IE8.
It would be great to test it on other platforms too...
I have no time to explain it in detail. Will find some time, I
promise.
On Aug 13, 5:45 am, tres treshug...@gmail.com wrote:
This discussion is about inheritance and not about namespacs
You are right. But when we talk about inheritance, we also have to
think about what is doing the inheriting. Which is why namespacing is
an issue. I hope I don't need to explain the caveats of a flat
namespace. Anyways take the following example:
var plugin = function() {};
plugin.prototype.alertHtml = function() { alert($(this).html(); };
$.fn.plugin = $.namespace(plugin); // call it $.inherit if you like
// and if you have a base object as per Robert's plugin; you could
also include _super here and whatever else you want
$.extend($.fn.plugin.fn, $.base);
$.namespace essentially creates a child object for jQuery. Just like
when you call jQuery(), it calls a separate function which
instantiates an object and converts 'this' to a jQuery array. $.extend
then inherits functions from a base object. I think that if your
$.plugin and my $.namespace were combined that we could get the best
of both worlds.
If you can not understand what a widget system would be, than I
suggest to look jQuery UI
Look, man, that really is unnecessary. I am sorry if I insulted you.
On Aug 13, 12:24 pm, Robert Katić robert.ka...@gmail.com wrote:
Tres, I know that you are not insulting me purposely.
Unfortunately that means that you really thinks that I have to learn
about private and namespaces stuff.
I am not sure why I give you the impression that I need to learn about
basic JavaScriptng. Is the my bad english?
Please, back to the actual topic...
This discussion is about inheritance and not about namespacs.
I mentioned my plugin authoring solution because it uses inheritance,
and if something would benefits from inheritance it would be a plugin/
widget system to me.
If you can not understand what a widget system would be, than I
suggest to look jQuery UI
On Aug 13, 3:54 am, tres treshug...@gmail.com wrote:
Not at all. We are not here to flame or insult anyone. This is a
development group discussion. Yes, tempers and passion flare, and
sometimes things can be mistaken for arrogance, but I think that a lot
of people will be with me on that we are actually here to discuss the
future of jQuery rather than insult people. Insulting people isn't
worth my time or anyone else's and doesn't get anyone anywhere.
Although we all want to help and have a hand in jQuery, I think our
end result should be to further the development and future of the
library as a team, not individuals. Just because we aren't part of the
core team doesn't mean we aren't a team.
Please, back to the actual topic...
On Aug 13, 11:49 am, Robert Katić robert.ka...@gmail.com wrote:
@tres
Haha. Are you insulting me?
On Aug 13, 3:05 am, tres treshug...@gmail.com wrote:
@robert
But widgets are all about DOM elements. So why shouldn't a widget
system be?
I don't know about you, but I want the ability to add a multi-method
API to jQuery without cluttering it's namespace. Namespace clutter is
bad practice.
http://www.javascripttoolbox.com/bestpractices/, scroll to: Avoid
Cluttering The Global Namespace, it also has links for closures and
private members
I know this talks about the global namespace, but this can very well
be applied to the jQuery namespace.
http://www.dustindiaz.com/namespace-your-javascript/, another way for
private members, but similar in practice
As for who expects .dialog() to return a namespace rather than display
something: When you call jQuery, what does it return? (Hint: a
namespace)
On Aug 13, 10:43 am, Robert Katić robert.ka...@gmail.com wrote:
@tres
An plugin/widget system is about widgets, not DOM elements.
If you have to extend jQuery adding some DOM related stuff, you will
continue to add that stuff to jQuery or jQuery.fn directly or with
extend().
Closures are great to make private things, but it requires that
public functions are defined inside that closure too. Good for
singletons, not for prototyping...
On Aug 13, 2:12 am, tres treshug...@gmail.com wrote:
And using:
this.$el
as the jQuery object array is cleaner than using just:
this
??
I think a big issue
[jquery-dev] Re: prototypal inheritance as part of jQuery core?
@tres
You made me thinking about namespaces a lot today.
I implemented a solution.
http://bender.fesb.hr/~robert/scripts/jquery.ns.js
Namespaces are not equal to modules. Inner namespaces can access to
outer namespaces.
'That means that any namespace can directly do DOM stuff for
example...
Here some tests http://jsbin.com/oviri/edit.
Please, feel free to do testing and writing more tests.
I made some tests on Firefox3.5, Chrome, Safari4, IE8.
It would be great to test it on other platforms too...
I have no time to explain it in detail. Will find some time, I
promise.
On Aug 13, 5:45 am, tres treshug...@gmail.com wrote:
This discussion is about inheritance and not about namespacs
You are right. But when we talk about inheritance, we also have to
think about what is doing the inheriting. Which is why namespacing is
an issue. I hope I don't need to explain the caveats of a flat
namespace. Anyways take the following example:
var plugin = function() {};
plugin.prototype.alertHtml = function() { alert($(this).html(); };
$.fn.plugin = $.namespace(plugin); // call it $.inherit if you like
// and if you have a base object as per Robert's plugin; you could
also include _super here and whatever else you want
$.extend($.fn.plugin.fn, $.base);
$.namespace essentially creates a child object for jQuery. Just like
when you call jQuery(), it calls a separate function which
instantiates an object and converts 'this' to a jQuery array. $.extend
then inherits functions from a base object. I think that if your
$.plugin and my $.namespace were combined that we could get the best
of both worlds.
If you can not understand what a widget system would be, than I
suggest to look jQuery UI
Look, man, that really is unnecessary. I am sorry if I insulted you.
On Aug 13, 12:24 pm, Robert Katić robert.ka...@gmail.com wrote:
Tres, I know that you are not insulting me purposely.
Unfortunately that means that you really thinks that I have to learn
about private and namespaces stuff.
I am not sure why I give you the impression that I need to learn about
basic JavaScriptng. Is the my bad english?
Please, back to the actual topic...
This discussion is about inheritance and not about namespacs.
I mentioned my plugin authoring solution because it uses inheritance,
and if something would benefits from inheritance it would be a plugin/
widget system to me.
If you can not understand what a widget system would be, than I
suggest to look jQuery UI
On Aug 13, 3:54 am, tres treshug...@gmail.com wrote:
Not at all. We are not here to flame or insult anyone. This is a
development group discussion. Yes, tempers and passion flare, and
sometimes things can be mistaken for arrogance, but I think that a lot
of people will be with me on that we are actually here to discuss the
future of jQuery rather than insult people. Insulting people isn't
worth my time or anyone else's and doesn't get anyone anywhere.
Although we all want to help and have a hand in jQuery, I think our
end result should be to further the development and future of the
library as a team, not individuals. Just because we aren't part of the
core team doesn't mean we aren't a team.
Please, back to the actual topic...
On Aug 13, 11:49 am, Robert Katić robert.ka...@gmail.com wrote:
@tres
Haha. Are you insulting me?
On Aug 13, 3:05 am, tres treshug...@gmail.com wrote:
@robert
But widgets are all about DOM elements. So why shouldn't a widget
system be?
I don't know about you, but I want the ability to add a multi-method
API to jQuery without cluttering it's namespace. Namespace clutter is
bad practice.
http://www.javascripttoolbox.com/bestpractices/, scroll to: Avoid
Cluttering The Global Namespace, it also has links for closures and
private members
I know this talks about the global namespace, but this can very well
be applied to the jQuery namespace.
http://www.dustindiaz.com/namespace-your-javascript/, another way for
private members, but similar in practice
As for who expects .dialog() to return a namespace rather than display
something: When you call jQuery, what does it return? (Hint: a
namespace)
On Aug 13, 10:43 am, Robert Katić robert.ka...@gmail.com wrote:
@tres
An plugin/widget system is about widgets, not DOM elements.
If you have to extend jQuery adding some DOM related stuff, you will
continue to add that stuff to jQuery or jQuery.fn directly or with
extend().
Closures are great to make private things, but it requires that
public functions are defined inside that closure too. Good for
singletons, not for prototyping...
On Aug 13, 2:12 am, tres treshug...@gmail.com wrote:
And using:
this.$el
as the jQuery object array is cleaner than using just:
this
??
I think a big issue
[jquery-dev] Re: prototypal inheritance as part of jQuery core?
I certainly would appreciate any collaborative effort.
For off-list discussions, feel you free to mail me.
Seams there are problems with http://jsbin.com.
Testes and html goes away.
Can you suggest any similar alternative service?
On Aug 14, 12:47 am, tres treshug...@gmail.com wrote:
Awesome, man. I'll take a look when I have time this weekend.
You think you might be up for a collaborative effort and maybe
throwing some ideas back and forth? Most likely off-list.
On Aug 14, 3:21 am, Robert Katić robert.ka...@gmail.com wrote:
@tres
You made me thinking about namespaces a lot today.
I implemented a solution.
http://bender.fesb.hr/~robert/scripts/jquery.ns.js
Namespaces are not equal to modules. Inner namespaces can access to
outer namespaces.
'That means that any namespace can directly do DOM stuff for
example...
Here some testshttp://jsbin.com/oviri/edit.
Please, feel free to do testing and writing more tests.
I made some tests on Firefox3.5, Chrome, Safari4, IE8.
It would be great to test it on other platforms too...
I have no time to explain it in detail. Will find some time, I
promise.
On Aug 13, 5:45 am, tres treshug...@gmail.com wrote:
This discussion is about inheritance and not about namespacs
You are right. But when we talk about inheritance, we also have to
think about what is doing the inheriting. Which is why namespacing is
an issue. I hope I don't need to explain the caveats of a flat
namespace. Anyways take the following example:
var plugin = function() {};
plugin.prototype.alertHtml = function() { alert($(this).html(); };
$.fn.plugin = $.namespace(plugin); // call it $.inherit if you like
// and if you have a base object as per Robert's plugin; you could
also include _super here and whatever else you want
$.extend($.fn.plugin.fn, $.base);
$.namespace essentially creates a child object for jQuery. Just like
when you call jQuery(), it calls a separate function which
instantiates an object and converts 'this' to a jQuery array. $.extend
then inherits functions from a base object. I think that if your
$.plugin and my $.namespace were combined that we could get the best
of both worlds.
If you can not understand what a widget system would be, than I
suggest to look jQuery UI
Look, man, that really is unnecessary. I am sorry if I insulted you.
On Aug 13, 12:24 pm, Robert Katić robert.ka...@gmail.com wrote:
Tres, I know that you are not insulting me purposely.
Unfortunately that means that you really thinks that I have to learn
about private and namespaces stuff.
I am not sure why I give you the impression that I need to learn about
basic JavaScriptng. Is the my bad english?
Please, back to the actual topic...
This discussion is about inheritance and not about namespacs.
I mentioned my plugin authoring solution because it uses inheritance,
and if something would benefits from inheritance it would be a plugin/
widget system to me.
If you can not understand what a widget system would be, than I
suggest to look jQuery UI
On Aug 13, 3:54 am, tres treshug...@gmail.com wrote:
Not at all. We are not here to flame or insult anyone. This is a
development group discussion. Yes, tempers and passion flare, and
sometimes things can be mistaken for arrogance, but I think that a lot
of people will be with me on that we are actually here to discuss the
future of jQuery rather than insult people. Insulting people isn't
worth my time or anyone else's and doesn't get anyone anywhere.
Although we all want to help and have a hand in jQuery, I think our
end result should be to further the development and future of the
library as a team, not individuals. Just because we aren't part of the
core team doesn't mean we aren't a team.
Please, back to the actual topic...
On Aug 13, 11:49 am, Robert Katić robert.ka...@gmail.com wrote:
@tres
Haha. Are you insulting me?
On Aug 13, 3:05 am, tres treshug...@gmail.com wrote:
@robert
But widgets are all about DOM elements. So why shouldn't a widget
system be?
I don't know about you, but I want the ability to add a
multi-method
API to jQuery without cluttering it's namespace. Namespace
clutter is
bad practice.
http://www.javascripttoolbox.com/bestpractices/, scroll to: Avoid
Cluttering The Global Namespace, it also has links for closures
and
private members
I know this talks about the global namespace, but this can very
well
be applied to the jQuery namespace.
http://www.dustindiaz.com/namespace-your-javascript/, another way
for
private members, but similar in practice
As for who expects .dialog() to return a namespace rather than
display
something: When you call jQuery, what
[jquery-dev] Re: prototypal inheritance as part of jQuery core?
I think you are right that jQuery needs an widget system, but $
(..).dialog().open() does not look better than $(..).dialog('open') to
me,
Namespaces doesn't fit well within jQuery. Implementation would be
really dirty.
I made an my solution for plugin authoring with inheritance
http://bender.fesb.hr/~robert/jquery-plugin-inheritance/.
Maybe someone will find it useful.
On Aug 6, 5:50 am, tres treshug...@gmail.com wrote:
I think if plugin developers were to start utilizing a prototypal
inheritance, it would make the most sense to put it into the core.
This doesn't mean the current way of extending jQuery needs to change,
this just adds to it and makes an api much easier to write, understand
and use. As a plugin developer who has written many plugins (not
necessarily released) I have found it very, very frustrating to write
a plugin with more than 1 function in jQuery. I don't want to pass
'this' as a parameter, nor do I want to use the .dialog('open')
method. The former isn't the jQuery way and the latter just seems
dirty.
On Aug 6, 1:14 pm, aHeckman aaron.heckm...@gmail.com wrote:
I too believe prototypal inheritance should be left out.
But, in general, I'd love to see a change like this in jquery.ui ...
On Aug 5, 10:36 pm, tres treshug...@gmail.com wrote:
// would now allow
$('div').dialog().open();
// instead of
$('div').dialog('open');
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: prototypal inheritance as part of jQuery core?
@tres
An plugin/widget system is about widgets, not DOM elements.
If you have to extend jQuery adding some DOM related stuff, you will
continue to add that stuff to jQuery or jQuery.fn directly or with
extend().
Closures are great to make private things, but it requires that
public functions are defined inside that closure too. Good for
singletons, not for prototyping...
On Aug 13, 2:12 am, tres treshug...@gmail.com wrote:
And using:
this.$el
as the jQuery object array is cleaner than using just:
this
??
I think a big issue we have right now - and I am also partially guilty
of this - is that we all want to have a part in this. In doing that we
get blinded by thinking that our way is the best way.
What I see a lot of people trying to do, is make JavaScript into
something that it isn't. Call me crazy, but I don't think this is the
proper way to go about this. Yes, it's a very, very flexible language,
but it doesn't mean we need to change it's core behavior. This will
come over time.
For what it's worth, in my $.namespace, I implement a very similar
method that jQuery's core does to implement its namespace and use
'this' as an array. You can apply objects to jQuery using the way ES
intended objects to be used and constructed. Extending these plugins
are done in the same exact way as ES intended: .prototype. Or if
you're used to jQuery: .fn. This will allow for inheriting methods
that will automate plugin configuration etc. if needed.
// create your plugin
$.fn.pluginName = $.namespace(constructor);
// It doesn't require any special $.extend method, but you can use it:
$.extend($.fn.pluginName.fn, {
method1 : function() {},
method2 : function() {}
});
// or inheritance from an object:
$.extend($.fn.pluginName.fn, constructor.prototype);
Introducing a whole new way to do something that you can already do
and adding special rules for readonly methods (i.e. _) immediately
will make developing a widget/plugin for jQuery much less accessible
and much less usable. You can already create private methods anyways:
;(function($) {
// yes, this is 'private'
function private() {};
// but this is public
$.fn.test = function() {
// but you can use private here
return private();
};
})(jQuery);
Look, I am not trying to say that everyone needs to use my way, or
that anyone does. I believe it is the best way to approach this -
currently. But that is my opinion based on certain facts. I am also
not trying to be arrogant or offensive, even though it may be. Sorry
for that.
On Aug 13, 9:29 am, DBJDBJ dbj...@gmail.com wrote:
The big picture
// this is so much more right
$('div').dialog().open();
// than this
$('div').dialog('open');
In more than one language, and there is more than one reason, too ...
Also. Are some obsessed with inheritance, here ?
This subject is done and dusted in the OO community, way way back,
in eighties.
If you have time, here is one balanced article (and also interesting
to this community ) :http://www.berniecode.com/writing/inheritance/
Etc ...
--DBJ
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: prototypal inheritance as part of jQuery core?
@DBJ
I am not sure who expects that $('div').dialog() gives a namespaces
instead of creating or displaying something..
On Aug 13, 1:29 am, DBJDBJ dbj...@gmail.com wrote:
The big picture
// this is so much more right
$('div').dialog().open();
// than this
$('div').dialog('open');
In more than one language, and there is more than one reason, too ...
Also. Are some obsessed with inheritance, here ?
This subject is done and dusted in the OO community, way way back,
in eighties.
If you have time, here is one balanced article (and also interesting
to this community ) :http://www.berniecode.com/writing/inheritance/
Etc ...
--DBJ
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: prototypal inheritance as part of jQuery core?
@tres
Haha. Are you insulting me?
On Aug 13, 3:05 am, tres treshug...@gmail.com wrote:
@robert
But widgets are all about DOM elements. So why shouldn't a widget
system be?
I don't know about you, but I want the ability to add a multi-method
API to jQuery without cluttering it's namespace. Namespace clutter is
bad practice.
http://www.javascripttoolbox.com/bestpractices/, scroll to: Avoid
Cluttering The Global Namespace, it also has links for closures and
private members
I know this talks about the global namespace, but this can very well
be applied to the jQuery namespace.
http://www.dustindiaz.com/namespace-your-javascript/, another way for
private members, but similar in practice
As for who expects .dialog() to return a namespace rather than display
something: When you call jQuery, what does it return? (Hint: a
namespace)
On Aug 13, 10:43 am, Robert Katić robert.ka...@gmail.com wrote:
@tres
An plugin/widget system is about widgets, not DOM elements.
If you have to extend jQuery adding some DOM related stuff, you will
continue to add that stuff to jQuery or jQuery.fn directly or with
extend().
Closures are great to make private things, but it requires that
public functions are defined inside that closure too. Good for
singletons, not for prototyping...
On Aug 13, 2:12 am, tres treshug...@gmail.com wrote:
And using:
this.$el
as the jQuery object array is cleaner than using just:
this
??
I think a big issue we have right now - and I am also partially guilty
of this - is that we all want to have a part in this. In doing that we
get blinded by thinking that our way is the best way.
What I see a lot of people trying to do, is make JavaScript into
something that it isn't. Call me crazy, but I don't think this is the
proper way to go about this. Yes, it's a very, very flexible language,
but it doesn't mean we need to change it's core behavior. This will
come over time.
For what it's worth, in my $.namespace, I implement a very similar
method that jQuery's core does to implement its namespace and use
'this' as an array. You can apply objects to jQuery using the way ES
intended objects to be used and constructed. Extending these plugins
are done in the same exact way as ES intended: .prototype. Or if
you're used to jQuery: .fn. This will allow for inheriting methods
that will automate plugin configuration etc. if needed.
// create your plugin
$.fn.pluginName = $.namespace(constructor);
// It doesn't require any special $.extend method, but you can use it:
$.extend($.fn.pluginName.fn, {
method1 : function() {},
method2 : function() {}
});
// or inheritance from an object:
$.extend($.fn.pluginName.fn, constructor.prototype);
Introducing a whole new way to do something that you can already do
and adding special rules for readonly methods (i.e. _) immediately
will make developing a widget/plugin for jQuery much less accessible
and much less usable. You can already create private methods anyways:
;(function($) {
// yes, this is 'private'
function private() {};
// but this is public
$.fn.test = function() {
// but you can use private here
return private();
};
})(jQuery);
Look, I am not trying to say that everyone needs to use my way, or
that anyone does. I believe it is the best way to approach this -
currently. But that is my opinion based on certain facts. I am also
not trying to be arrogant or offensive, even though it may be. Sorry
for that.
On Aug 13, 9:29 am, DBJDBJ dbj...@gmail.com wrote:
The big picture
// this is so much more right
$('div').dialog().open();
// than this
$('div').dialog('open');
In more than one language, and there is more than one reason, too ...
Also. Are some obsessed with inheritance, here ?
This subject is done and dusted in the OO community, way way back,
in eighties.
If you have time, here is one balanced article (and also interesting
to this community ) :http://www.berniecode.com/writing/inheritance/
Etc ...
--DBJ
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: prototypal inheritance as part of jQuery core?
Tres, I know that you are not insulting me purposely.
Unfortunately that means that you really thinks that I have to learn
about private and namespaces stuff.
I am not sure why I give you the impression that I need to learn about
basic JavaScriptng. Is the my bad english?
Please, back to the actual topic...
This discussion is about inheritance and not about namespacs.
I mentioned my plugin authoring solution because it uses inheritance,
and if something would benefits from inheritance it would be a plugin/
widget system to me.
If you can not understand what a widget system would be, than I
suggest to look jQuery UI
On Aug 13, 3:54 am, tres treshug...@gmail.com wrote:
Not at all. We are not here to flame or insult anyone. This is a
development group discussion. Yes, tempers and passion flare, and
sometimes things can be mistaken for arrogance, but I think that a lot
of people will be with me on that we are actually here to discuss the
future of jQuery rather than insult people. Insulting people isn't
worth my time or anyone else's and doesn't get anyone anywhere.
Although we all want to help and have a hand in jQuery, I think our
end result should be to further the development and future of the
library as a team, not individuals. Just because we aren't part of the
core team doesn't mean we aren't a team.
Please, back to the actual topic...
On Aug 13, 11:49 am, Robert Katić robert.ka...@gmail.com wrote:
@tres
Haha. Are you insulting me?
On Aug 13, 3:05 am, tres treshug...@gmail.com wrote:
@robert
But widgets are all about DOM elements. So why shouldn't a widget
system be?
I don't know about you, but I want the ability to add a multi-method
API to jQuery without cluttering it's namespace. Namespace clutter is
bad practice.
http://www.javascripttoolbox.com/bestpractices/, scroll to: Avoid
Cluttering The Global Namespace, it also has links for closures and
private members
I know this talks about the global namespace, but this can very well
be applied to the jQuery namespace.
http://www.dustindiaz.com/namespace-your-javascript/, another way for
private members, but similar in practice
As for who expects .dialog() to return a namespace rather than display
something: When you call jQuery, what does it return? (Hint: a
namespace)
On Aug 13, 10:43 am, Robert Katić robert.ka...@gmail.com wrote:
@tres
An plugin/widget system is about widgets, not DOM elements.
If you have to extend jQuery adding some DOM related stuff, you will
continue to add that stuff to jQuery or jQuery.fn directly or with
extend().
Closures are great to make private things, but it requires that
public functions are defined inside that closure too. Good for
singletons, not for prototyping...
On Aug 13, 2:12 am, tres treshug...@gmail.com wrote:
And using:
this.$el
as the jQuery object array is cleaner than using just:
this
??
I think a big issue we have right now - and I am also partially guilty
of this - is that we all want to have a part in this. In doing that we
get blinded by thinking that our way is the best way.
What I see a lot of people trying to do, is make JavaScript into
something that it isn't. Call me crazy, but I don't think this is the
proper way to go about this. Yes, it's a very, very flexible language,
but it doesn't mean we need to change it's core behavior. This will
come over time.
For what it's worth, in my $.namespace, I implement a very similar
method that jQuery's core does to implement its namespace and use
'this' as an array. You can apply objects to jQuery using the way ES
intended objects to be used and constructed. Extending these plugins
are done in the same exact way as ES intended: .prototype. Or if
you're used to jQuery: .fn. This will allow for inheriting methods
that will automate plugin configuration etc. if needed.
// create your plugin
$.fn.pluginName = $.namespace(constructor);
// It doesn't require any special $.extend method, but you can use it:
$.extend($.fn.pluginName.fn, {
method1 : function() {},
method2 : function() {}
});
// or inheritance from an object:
$.extend($.fn.pluginName.fn, constructor.prototype);
Introducing a whole new way to do something that you can already do
and adding special rules for readonly methods (i.e. _) immediately
will make developing a widget/plugin for jQuery much less accessible
and much less usable. You can already create private methods anyways:
;(function($) {
// yes, this is 'private'
function private() {};
// but this is public
$.fn.test = function() {
// but you can use private here
return private();
};
})(jQuery);
Look, I am not trying to say that everyone needs to use
[jquery-dev] Re: Widget system
I am of same idea that compositions is better way to isolate interface
from implementation in almost all languages. This is important for
component oriented software (XPCOM, COM) where high independency
between each component is required (in compiling and in developing).
In majority of scripting languages (like JS) composition is important
too, because there is no private members or explicit overriding.
However, for internal usage (to not expose in API), inheritance is
still THE solution to define an is-a relationship. Forced delegation
inside implementations requires redundant code (that makes code less
maintainable and error prone).
In a JS widget system, inheritance is not designed/recommended to use
to extend third part widgets, but for internal usage to implement a
set of widgets of same team/project.
Inside jQuery UI also it is used inheritance (mixing parent prototype)
to extend all their widgets from an base.
If inheritance brought problems, it is very likely that it is not used
properly or it is overused. With an good software architecture that
shouldn't happen.
PS: I da, dobro mi je poznat i C++ osim JS, C#, python, ... barem
bolje od engleskog.
On May 14, 11:35 am, DBJDBJ dbj...@gmail.com wrote:
GOOD :
interface X { } ;
class A implements X { } ;
BAD :
class Y { } ;
class B inherits Y { } ;
Also, please do not feel sorry for me, I use JavaScript only when
necessary ;o)
PS: Tvoj english uopste nije los ...
-- DBJ
On May 14, 6:17 am, Robert Katić robert.ka...@gmail.com wrote:
I suppose you ALWAYS use delegation to define an is-a class
relationship.
If so, I am sorry for you.
Inheritance is an easier way to define an is-a relationship.
Unfortunately it is often overused.
Unfortunately changes to super-class can easily break sub-classes,
specially in script languages where there is no good separation
between interfaces and implementations...
Mixins ($.extend) suffer same problems.
An possible solution of this problems is to implement explicit
overriding (like C#).
It's not hard to implement, but it would probably make inheritance
unnecessary harder to use, specially in JS, where it is probably that
sub-class and super-class is defined by same programmer.
However I think that inheritance is an powerful tool in hand of good
programmers.
Sorry for my English.
On May 14, 1:07 am, DBJDBJ dbj...@gmail.com wrote:
Inheritance is Evil ...
http://www.berniecode.com/writing/inheritance/
--DBJ
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $.each and JS 1.6's forEach
There is no need to take in consideration eventual length updates;
that slows considerably, and it is not garanted in any/each native
implementation:
https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Global_Objects/Array/ForEach
On May 21, 5:39 pm, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
IE8? obviously no, how can you pretend a browser that implemented
defineProperty only for Window and DOM can be so advanced with other
native constructors? :D
Anyway, the most legacy like forEach is something like this:
Array.forEach = Array.forEach || function(obj, callback, scope){
for(var
length = obj.length,
i = 0;
i length;
++i
){
if(i in obj){ // forEach does not loop over undefined indexes
callback.call(scope, obj[i], i, obj);
// the callback could have changed the Array/collection
length = obj.length;
};
};
};
Best regards,
Andrea Giammarchi
On Thu, May 21, 2009 at 4:11 PM, diogobaeder diogobae...@gmail.com wrote:
Hmmm... close, I agree, but still not cross-browser compliant... ;-)
Question: does IE8 support these methods (abstract and instance)
natively?
Diogo
On May 20, 3:37 pm, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
P.S. Array.forEach is standard in FireFox and some other browser, so it
is
still native one
On Wed, May 20, 2009 at 7:36 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
jQuery.forEach = Array.forEach || function(){ ... }
now you are close to vice-versa logic, where you can simply use
Array.forEach with every array like variable, DOM colelctions included
;-)
On Wed, May 20, 2009 at 6:39 PM, diogobaeder diogobae...@gmail.com
wrote:
Hmmm... almost there, in my opinion, Andrea... I think it could be
used in the main jQuery object (singleton), also, to minimize browser
dependance, if the user wants to use it with normal Array objects...
like:
jQuery.forEach(myArrayObject, , myCallback, myContext);
What do you think? This way, the client code can use it both with
Array objects and jQuery wrapped DOM objects...
Diogo
On May 20, 3:35 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
JQuery.fn.forEach = Array.prototype.forEach || function(){ ... };
easy?
:-)
On May 20, 2009 3:07 AM, diogobaeder diogobae...@gmail.com
wrote:
Matt,
I think your approach is usefull only if one wants to create a new
jQuery method... because checking everytime if forEach method exists
is not easily maintainable...
Maybe it could be a $.forEach, applying the Mozilla implementation
if
the browser doesn't support the method... what do you guys think of
it?
Diogo
On May 19, 11:29 am, Matt Kruse m...@thekrusefamily.com wrote:
On
May
19, 9:19 am, diogobaede...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Widget system
I made some drastic changes to the my solution (http://bender.fesb.hr/
~robert/jquery.plugin.js).
Some examples included.
I am conscious that it would be more elegant to provide this._super
feature, but i think it would make debugging more hard ('finally'
without 'catch' is not well supported by IE, and without it _super can
be inconsistent if an exception is raised...).
However, i putted 'call' helper method to make more elegant parent
calls...
I am not sure way benefits of inheritance are unattended here. I
suppose it would be useful in larger projects like jQuery UI or other
widget sets.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Widget system
I suppose you ALWAYS use delegation to define an is-a class relationship. If so, I am sorry for you. Inheritance is an easier way to define an is-a relationship. Unfortunately it is often overused. Unfortunately changes to super-class can easily break sub-classes, specially in script languages where there is no good separation between interfaces and implementations... Mixins ($.extend) suffer same problems. An possible solution of this problems is to implement explicit overriding (like C#). It's not hard to implement, but it would probably make inheritance unnecessary harder to use, specially in JS, where it is probably that sub-class and super-class is defined by same programmer. However I think that inheritance is an powerful tool in hand of good programmers. Sorry for my English. On May 14, 1:07 am, DBJDBJ dbj...@gmail.com wrote: Inheritance is Evil ... http://www.berniecode.com/writing/inheritance/ --DBJ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: Widget system
Well, I wrote an solution that would be simple to use but with
inheritance that is in my opinion is nice to have in larger projects.
Simple use:
$.plugin(simple_plugin, {
options: {
className: simple_plugin,
opt1: false
},
init: function( options ) {
$(this.node).addClass(options.className);
if ( options.opt1 ) {
//...
}
}
});
To have an alternative simple_plugin but with some different default
options we can simply:
$.plugin(simple_plugin_2, {
base: $.simple_plugin,
options: {
opt1: true
}
});
Later, we can change some default options to simple_plugin that will
also apply to simple_plugin_2 if not overrided.
$.simple_plugin.setOptions({
className: sim_plugin
});
$.simple_plugin_2.options.className == sim_plugin; // TRUE!
JQuery UI would inherit $.plugin.base to define $.widget:
$.widget = $.plugin.base.extended({
init: function( options ) {
//$.plugin.base.fn.init.call(this, options);
this.call($.plugin.base, 'init', options);
//...
},
fn: {
enable: function() {
//...
}
//...
}
});
$.plugin(tabs, {
base: $.widget
//...
});
$.base is an generic base class (not plugin).
class in my implementation is an object (not function) to provide
static property inheritance too. Instead of the new operator, you
will use $ static method to create an instance...
Hope this short intro will make my solution more clear to understand.
On May 5, 3:30 am, John Resig jere...@gmail.com wrote:
It's not completely clear what your code does or how it would be used, from
looking at it - do you have any examples?
--John
On Mon, May 4, 2009 at 7:43 PM, Robert Katić robert.ka...@gmail.com wrote:
After some readings on the A Modest Proposal: jQuery Enterprise
discussion at
http://groups.google.com/group/jquery-dev/browse_frm/thread/1ec4dca6e...
,
it is clear that jQuery needs an own widget system that will expose an
standard way to write widgets/plugins. This need is more evident on
larger projects. JQuery UI implements an own.
Some ideas:
jQuery UI:http://jquery-ui.googlecode.com/svn/trunk/ui/ui.core.js
John:http://dev.jquery.com/~john/plugins/widget/widget.jshttp://dev.jquery.com/%7Ejohn/plugins/widget/widget.js
my try with
inheritance:http://bender.fesb.hr/~robert/jquery.plugin.jshttp://bender.fesb.hr/%7Erobert/jquery.plugin.js
Thoughts?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Dean Edwards: Callbacks vs Events
Thanks John to clarify me what I missed.
The problem with your code is that you're re-throwing the event -
which means that debuggers/command-lines will think that the error
originated from the second throw point in the catch, and not the
original location.
I was in hope that there is an good JS debugger that will report
entire stack (Firebug sometime have problems with doing that - in that
cases, instead of re-throwing, console.error works better to me).
I can understand if this is not enough for many users, so I have to
agree with you.
Additionally, using setTimeout is no good because the return results
from the functions need to be handled synchronously.
Not sure why it would not be possible to synchronize the return
results.
I guess that it would be more difficult to implement, so I will not
insist about this.
I have to worry if you will implement something that will not throw
ALL errors, because it would hide some errors if an required third-
part plug-in already throws some.
If it is too hard to ensure all throws, than I certainly prefer the
current solution.
--John
On Wed, Mar 25, 2009 at 12:32 AM, Robert Katić robert.ka...@gmail.com wrote:
What about this:
function runHandlers(){
var h;
try {
while ( (h = handlers.shift()) ) {
h();
}
} catch (e) {
setTimeout(runHandlers);
throw e;
}
}
var handlers = [
function(){
throw A;
},
function(){
throw B;
}
];
This one will throw both (all) errors.
Am I missing something?
On Mar 24, 10:13 pm, John Resig jere...@gmail.com wrote:
I don't think it is the resposibility of the dispatcher to handle
exceptions.
I think it it is the resposibility of the dispatcher to dispatch
events. :-)
An error in one handler should not prevent another handler from
executing.
Nor should a dispatcher suppress errors so that it can complete its
task.
Why not just use try/finally, then?
Online here, as well:http://ejohn.org/files/handler.html
script
function runHandlers(i){
i = i || 0;
try {
while ( i handlers.length ) {
handlers[i]();
i++;
}
} finally {
if ( i handlers.length ) {
runHandlers( i + 1 );
}
}
}
var handlers = [
function(){
document.write(testAbr);
throw A;
},
function(){
document.write(testBbr);
}
];
try {
runHandlers();} catch(e){
document.write(ERROR: + e + br);}
/script
Output:
testA
testB
ERROR: A
I don't think the order of the error is terribly important in this
case. At the very least, though, you get the best of all worlds: All
handlers execute, exceptions are thrown, and performance isn't
sacrificed.
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Dean Edwards: Callbacks vs Events
Is something like this enough?
var _errors = [];
function flushErrors() {
if ( _errors.length 0 ) {
e = _errors;
errors = [];
throw e;
}
}
function pushError( e ) {
if ( console console.error )
console.error( e );
//if ( ... )
//...
else
_errors.push( e );
}
function runHandlers(){
var h;
try {
while ( (h = handlers.shift()) ) {
h();
}
} catch (e) {
pushError(e);
if ( h )
runHandlers();
}
flushErrors();
}
var handlers = [
function(){
throw new Error(A);
},
function(){
throw new Error(B);
}
];
On Mar 25, 5:39 am, John Resig jere...@gmail.com wrote:
The problem with your code is that you're re-throwing the event -
which means that debuggers/command-lines will think that the error
originated from the second throw point in the catch, and not the
original location.
Additionally, using setTimeout is no good because the return results
from the functions need to be handled synchronously.
--John
On Wed, Mar 25, 2009 at 12:32 AM, Robert Katić robert.ka...@gmail.com wrote:
What about this:
function runHandlers(){
var h;
try {
while ( (h = handlers.shift()) ) {
h();
}
} catch (e) {
setTimeout(runHandlers);
throw e;
}
}
var handlers = [
function(){
throw A;
},
function(){
throw B;
}
];
This one will throw both (all) errors.
Am I missing something?
On Mar 24, 10:13 pm, John Resig jere...@gmail.com wrote:
I don't think it is the resposibility of the dispatcher to handle
exceptions.
I think it it is the resposibility of the dispatcher to dispatch
events. :-)
An error in one handler should not prevent another handler from
executing.
Nor should a dispatcher suppress errors so that it can complete its
task.
Why not just use try/finally, then?
Online here, as well:http://ejohn.org/files/handler.html
script
function runHandlers(i){
i = i || 0;
try {
while ( i handlers.length ) {
handlers[i]();
i++;
}
} finally {
if ( i handlers.length ) {
runHandlers( i + 1 );
}
}
}
var handlers = [
function(){
document.write(testAbr);
throw A;
},
function(){
document.write(testBbr);
}
];
try {
runHandlers();} catch(e){
document.write(ERROR: + e + br);}
/script
Output:
testA
testB
ERROR: A
I don't think the order of the error is terribly important in this
case. At the very least, though, you get the best of all worlds: All
handlers execute, exceptions are thrown, and performance isn't
sacrificed.
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Odd error in IE 7 with $.each
I am wondering if it would be necessary to check if (i in object) too,
in future (with i length). I hope not :).
On Mar 17, 2:29 pm, John Resig jere...@gmail.com wrote:
Would you be open to filing a bug on this? Thanks.
What a stupid behavior on the part of IE.
--John
On Tue, Mar 17, 2009 at 3:35 AM, Danny d.wac...@prodigy.net wrote:
$.each(document.styleSheets... fails with the error:
Line: 692
Character: 11
Code: 0
Error Message: Invalid procedure call or argument
The simplest page with the error is:
script type=text/javascript src=http://ajax.googleapis.com/ajax/
libs/jquery/1.3.2/jquery.jshttp://ajax.googleapis.com/ajax/%0Alibs/jquery/1.3.2/jquery.js
/script
script
$.each (document.styleSheets, function(){});
/script
(making the markup valid and adding a DOCTYPE don't help).
A regular for loop works fine.
It seems the problem is the object[++i] at the end of the loop;
instead of returning undefined it throws the error.
Danny
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: 1st array element $('input[value='+$(this).text()+']'
This is more nicer (less confusions with parenthesis):
$('input[value='+$(this).text()+']').eq(0).remove();
Also, this has the advantage to preserve the query in the chain:
$('input[value='+$(this).text()+']')
.eq(0)
.remove()
.end()
.slice(1)
.addClass('.survived');
On Mar 11, 5:24 am, Bas basvdlustgr...@gmail.com wrote:
this was the correct one
$($('input[value='+$(this).text()+']')[0]).remove();
thank you guys
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: 1st array element $('input[value='+$(this).text()+']'
This is more nicer (less confusions with parenthesis):
$('input[value='+$(this).text()+']').eq(0).remove();
Also, this has the advantage to preserve the query in the chain:
$('input[value='+$(this).text()+']')
.eq(0)
.remove()
.end()
.slice(1)
.addClass('.survived');
Also this would not try to remove the document in case the query
doesn't returns any element.
On Mar 11, 5:24 am, Bas basvdlustgr...@gmail.com wrote:
this was the correct one
$($('input[value='+$(this).text()+']')[0]).remove();
thank you guys
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $( $(el)[x] ) is faster than $(el).eq(x)
eq: function( i ) {
var el = [ this[ i0 ? i+this.length : i] ];
if (el[0] === undefined) el.length = 0;
return this.pushStack( el, 'eq', i );
};
Yes, I supposed it was an mistyping. Now this is safe in case of out
of range but is not in case with an undefined value as element. ( +i
+ this.length is to make eq(i) safe in cases where i is an string )
It doesn't seem possible to pass the undefined object along. Anyone
doing that? $(undefined) and $(null) are also unsupported.
Of course it is possible, even if jquery is mainly an container of
elements.
I saw usages of $.fn.map which callback returns non-element values. I
know that in that cases an $.map is more appropriate, but the current
implementation allows both approaches.
$(undefined) and $(null) works fine and are equally to $() and $
(document). Does these are supported or not is not relevant here, I
think.
I would like to have an John opinion if we have to support undefined
values inside an jquery object, and would it be dangerous to break
this support.
On Mar 3, 5:47 pm, Robert Katić robert.ka...@gmail.com wrote:
jQuery([undefined])[0] === jQuery([])[0]
Yes, but
jQuery([undefined]).length !== jQuery([]).length
eq() always returns a single element, so you'd only need to allow null/
NaN//etc to pass through, I guess:
In the current implementation, eq(i) returns the value (not only
nodes) at index i, if i is not out of range.
In case of out of range it returns an empty jquery.
eq: function( i ) {
var el = [ this[ i0 ? i+this.length : i] ];
if (el === undefined) el = [];
return this.pushStack( el, 'eq', i )
}
Your solution will return jQuery([undefined]) in case of out of
range insted of an jQuery([]),
and el will always be an array, so (el === undefined) will never be
true.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $( $(el)[x] ) is faster than $(el).eq(x)
eq: function( i ) {
var el = [ this[ i0 ? i+this.length : i] ];
if (el[0] === undefined) el.length = 0;
return this.pushStack( el, 'eq', i );
};
Yes, I supposed it was an mistyping. Now this is safe in case of out
of range but is not in case with an undefined value as element. ( +i
+ this.length is to make eq(i) safe in cases where i is an string )
It doesn't seem possible to pass the undefined object along. Anyone
doing that? $(undefined) and $(null) are also unsupported.
Of course it is possible, even if jquery is mainly an container of
elements.
I saw usages of $.fn.map which callback returns non-element values. I
know that in that cases an $.map is more appropriate, but the current
implementation allows both approaches.
$(undefined) and $(null) works fine and are equally to $() and $
(document). Does these are supported form the API or not is not
relevant here, I
think.
I would like to have an John opinion if we have to support undefined
values in this cases, and would it be dangerous to break this
support.
On Mar 4, 5:02 pm, ricardobeat ricardob...@gmail.com wrote:
Mistyped:
eq: function( i ) {
var el = [ this[ i0 ? i+this.length : i] ];
if (el[0] === undefined) el.length = 0;
return this.pushStack( el, 'eq', i );
};
It doesn't seem possible to pass the undefined object along. Anyone
doing that? $(undefined) and $(null) are also unsupported.
- ricardo
On Mar 3, 5:47 pm, Robert Katić robert.ka...@gmail.com wrote:
jQuery([undefined])[0] === jQuery([])[0]
Yes, but
jQuery([undefined]).length !== jQuery([]).length
eq() always returns a single element, so you'd only need to allow null/
NaN//etc to pass through, I guess:
In the current implementation, eq(i) returns the value (not only
nodes) at index i, if i is not out of range.
In case of out of range it returns an empty jquery.
eq: function( i ) {
var el = [ this[ i0 ? i+this.length : i] ];
if (el === undefined) el = [];
return this.pushStack( el, 'eq', i )
}
Your solution will return jQuery([undefined]) in case of out of
range insted of an jQuery([]),
and el will always be an array, so (el === undefined) will never be
true.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $( $(el)[x] ) is faster than $(el).eq(x)
eq: function( i ) {
var el = [ this[ i0 ? i+this.length : i] ];
if (el[0] === undefined) el.length = 0;
return this.pushStack( el, 'eq', i );
};
Yes, I supposed it was an mistyping. Now this is safe in case of out
of range but is not in case with an undefined value as element. ( +i
+ this.length is to make eq(i) safe in cases where i is an string )
It doesn't seem possible to pass the undefined object along. Anyone
doing that? $(undefined) and $(null) are also unsupported.
$(undefined) and $(null) works fine and are equally to $() and $
(document). Does these are supported form the API or not is not
relevant here, I
think.
I would like to have an John opinion if we have to support undefined
values in this cases, and would it be dangerous to break this
support.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $( $(el)[x] ) is faster than $(el).eq(x)
Since no one is correcting me, I will do it myself, again :)
We always have to pass an array to pushStack because it will ensure
that the value will not processed as an selector or html or document,
but simply as an array with values to set.
eq: function( i ) {
var j = i 0 ? +i + this.length : i,
el = j in this ? [ this[j] ] : [];
return this.pushStack( el, 'eq', i )
}
We maybe can make an exception if the value is a node:
eq: function( i ) {
var j = i 0 ? +i + this.length : i,
el = this[ j ];
el = ( j in this ) ? ( el el.nodeType ? el : [el] ) : [];
return this.pushStack( el, 'eq', i )
}
However, not sure if this solutions are significantly faster then the
solution with slicing.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $( $(el)[x] ) is faster than $(el).eq(x)
jQuery([undefined])[0] === jQuery([])[0]
Yes, but
jQuery([undefined]).length !== jQuery([]).length
eq() always returns a single element, so you'd only need to allow null/
NaN//etc to pass through, I guess:
In the current implementation, eq(i) returns the value (not only
nodes) at index i, if i is not out of range.
In case of out of range it returns an empty jquery.
eq: function( i ) {
var el = [ this[ i0 ? i+this.length : i] ];
if (el === undefined) el = [];
return this.pushStack( el, 'eq', i )
}
Your solution will return jQuery([undefined]) in case of out of
range insted of an jQuery([]),
and el will always be an array, so (el === undefined) will never be
true.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $( $(el)[x] ) is faster than $(el).eq(x)
Your solution resolves the out of range problem, but doesn't
resolves the problem where el is not true.
Although, jquery object is usually an array-like object of nodes, it
can contains other values too, including: false, undefined, null and
0. In that cases your solution will return an empty jquery, instead
of one with the wonted value.
On Mar 3, 2:03 am, ricardobeat ricardob...@gmail.com wrote:
Now this is getting dirty - this should do (split for readability):
eq: function( i ) {
var el = this[ i0 ? i+this.length : i];
return this.pushStack( el || [], 'eq', i )
}
No loss of performance with this one.
- ricardo
On Mar 2, 6:10 pm, Robert Katić robert.ka...@gmail.com wrote:
I figured out (unfortunately not before) that the main reason why the
current implementation uses slicing is to ensure correct behavior in
case of index out of range and in case of !this[i].
Here proposed solutions will not return an empty jquery in that cases,
but an jquery with the document element.
Maybe this would be more appropriate:
eq: function( i ) {
return this.pushStack( i == -1 ? arraySlice.call(this, i) :
arraySlice.call(this, i, +i + 1), 'eq', i )
}
Unfortunately this looks dirty with no significant performance
improvements in respect of the first solution I purposed
onhttp://dev.jquery.com/ticket/4188.
Any better idea?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $( $(el)[x] ) is faster than $(el).eq(x)
Yes, I made an writing error. The second case (!his[i]) would return
an jquery with the not-true value instead of an empty one. This was
the reason of Ricardo's not entirely correct solution, I suppose.
On Mar 2, 10:10 pm, Robert Katić robert.ka...@gmail.com wrote:
I figured out (unfortunately not before) that the main reason why the
current implementation uses slicing is to ensure correct behavior in
case of index out of range and in case of !this[i].
Here proposed solutions will not return an empty jquery in that cases,
but an jquery with the document element.
Maybe this would be more appropriate:
eq: function( i ) {
return this.pushStack( i == -1 ? arraySlice.call(this, i) :
arraySlice.call(this, i, +i + 1), 'eq', i )
}
Unfortunately this looks dirty with no significant performance
improvements in respect of the first solution I purposed
onhttp://dev.jquery.com/ticket/4188.
Any better idea?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $( $(el)[x] ) is faster than $(el).eq(x)
Making inline calling would be avoided if not really necessary.
Is the speed difference of two solutions relevant at this point?
However, I am sure that John will consider this optimization too if
needed.
On Mar 1, 8:01 pm, ricardobeat ricardob...@gmail.com wrote:
We can preserve the index without resorting to get (and without
affecting performance) by using a ternary:
jQuery.fn.eq = function( i ) {
return this.pushStack( this[i0 ? i+this.length : i], 'eq', i )
}
cheers,
- ricardo
On Feb 28, 8:42 pm, Robert Katić robert.ka...@gmail.com wrote:
An slightly slower but more robust solution would be:
eq: function( i ) {
return this.pushStack( this.get(i), 'eq', i )
}
The main difference is that the ret.selector would preserve the
initial index (relative if negative).
On Feb 28, 9:44 pm, Robert Katić robert.ka...@gmail.com wrote:
If this solution seems ok, I would update the
tickethttp://dev.jquery.com/ticket/4188.
On Feb 28, 8:50 pm, ricardobeat ricardob...@gmail.com wrote:
Nice catch, that makes sense. Added it to the test page, it has no
significant impact on performance.
cheers,
- ricardo
On Feb 27, 7:27 pm, Robert Katić robert.ka...@gmail.com wrote:
Since .get(-1) will be supported, eq(-1) would be supported too (?).
So your implementation needs some extra code:
eq: function( i ) {
if ( i 0 )
i += this.length;
return this.pushStack( this[i], 'eq', i )
}
However this solution would be still faster then the one
onhttp://dev.jquery.com/ticket/4188, I suppose.
On Feb 26, 11:02 pm, ricardobeat ricardob...@gmail.com wrote:
Right, thanks!
Using pushStack seems ok, it's still chainable and keeps the
selector
state, while still being at least twice faster.
http://dev.jquery.com/ticket/4262http://jquery.nodnod.net/cases/177/run
cheers,
- ricardo
On Feb 26, 11:28 am, John Resig jere...@gmail.com wrote:
Well, first I would argue that the two are not equivalent.
$($(...)[x]) doesn't maintain the stack. You can no longer do:
$(...).eq(1).addClass(test).end().appendTo(#foo);
$($(...)[x]) doesn't maintain the internal selector state for
plugins.
For example if you checked $(...).eq(1).selector you'd see:
.slice(1,
2)
So, with that in mind, if there were ways to maintain that
functionality and still get a performance speed-up, I'd
definitely be
open to it.
--John
On Wed, Feb 25, 2009 at 11:41 PM, Ricardo Tomasi
ricardob...@gmail.com wrote:
Creating two jQuery objects + a lookup $( $(...)[x] ) is faster
than a
simple $(...).eq(x). That doesn't make much sense.
Currently the eq function looks like this:
eq: function( i ) {
return this.slice( i, +i + 1 );
},
Are there any downsides to changing it to this (object unique
IDs,
chaining)?
eq: function( i ) {
return jQuery(this[i]);
},
That offers a 25% to 40% speed improvement across all browsers.
http://jquery.nodnod.net/cases/177
cheers,
- ricardo
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $( $(el)[x] ) is faster than $(el).eq(x)
If this solution seems ok, I would update the ticket
http://dev.jquery.com/ticket/4188.
On Feb 28, 8:50 pm, ricardobeat ricardob...@gmail.com wrote:
Nice catch, that makes sense. Added it to the test page, it has no
significant impact on performance.
cheers,
- ricardo
On Feb 27, 7:27 pm, Robert Katić robert.ka...@gmail.com wrote:
Since .get(-1) will be supported, eq(-1) would be supported too (?).
So your implementation needs some extra code:
eq: function( i ) {
if ( i 0 )
i += this.length;
return this.pushStack( this[i], 'eq', i )
}
However this solution would be still faster then the one
onhttp://dev.jquery.com/ticket/4188, I suppose.
On Feb 26, 11:02 pm, ricardobeat ricardob...@gmail.com wrote:
Right, thanks!
Using pushStack seems ok, it's still chainable and keeps the selector
state, while still being at least twice faster.
http://dev.jquery.com/ticket/4262http://jquery.nodnod.net/cases/177/run
cheers,
- ricardo
On Feb 26, 11:28 am, John Resig jere...@gmail.com wrote:
Well, first I would argue that the two are not equivalent.
$($(...)[x]) doesn't maintain the stack. You can no longer do:
$(...).eq(1).addClass(test).end().appendTo(#foo);
$($(...)[x]) doesn't maintain the internal selector state for plugins.
For example if you checked $(...).eq(1).selector you'd see: .slice(1,
2)
So, with that in mind, if there were ways to maintain that
functionality and still get a performance speed-up, I'd definitely be
open to it.
--John
On Wed, Feb 25, 2009 at 11:41 PM, Ricardo Tomasi
ricardob...@gmail.com wrote:
Creating two jQuery objects + a lookup $( $(...)[x] ) is faster than a
simple $(...).eq(x). That doesn't make much sense.
Currently the eq function looks like this:
eq: function( i ) {
return this.slice( i, +i + 1 );
},
Are there any downsides to changing it to this (object unique IDs,
chaining)?
eq: function( i ) {
return jQuery(this[i]);
},
That offers a 25% to 40% speed improvement across all browsers.
http://jquery.nodnod.net/cases/177
cheers,
- ricardo
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $( $(el)[x] ) is faster than $(el).eq(x)
An slightly slower but more robust solution would be:
eq: function( i ) {
return this.pushStack( this.get(i), 'eq', i )
}
The main difference is that the ret.selector would preserve the
initial index (relative if negative).
On Feb 28, 9:44 pm, Robert Katić robert.ka...@gmail.com wrote:
If this solution seems ok, I would update the
tickethttp://dev.jquery.com/ticket/4188.
On Feb 28, 8:50 pm, ricardobeat ricardob...@gmail.com wrote:
Nice catch, that makes sense. Added it to the test page, it has no
significant impact on performance.
cheers,
- ricardo
On Feb 27, 7:27 pm, Robert Katić robert.ka...@gmail.com wrote:
Since .get(-1) will be supported, eq(-1) would be supported too (?).
So your implementation needs some extra code:
eq: function( i ) {
if ( i 0 )
i += this.length;
return this.pushStack( this[i], 'eq', i )
}
However this solution would be still faster then the one
onhttp://dev.jquery.com/ticket/4188, I suppose.
On Feb 26, 11:02 pm, ricardobeat ricardob...@gmail.com wrote:
Right, thanks!
Using pushStack seems ok, it's still chainable and keeps the selector
state, while still being at least twice faster.
http://dev.jquery.com/ticket/4262http://jquery.nodnod.net/cases/177/run
cheers,
- ricardo
On Feb 26, 11:28 am, John Resig jere...@gmail.com wrote:
Well, first I would argue that the two are not equivalent.
$($(...)[x]) doesn't maintain the stack. You can no longer do:
$(...).eq(1).addClass(test).end().appendTo(#foo);
$($(...)[x]) doesn't maintain the internal selector state for plugins.
For example if you checked $(...).eq(1).selector you'd see: .slice(1,
2)
So, with that in mind, if there were ways to maintain that
functionality and still get a performance speed-up, I'd definitely be
open to it.
--John
On Wed, Feb 25, 2009 at 11:41 PM, Ricardo Tomasi
ricardob...@gmail.com wrote:
Creating two jQuery objects + a lookup $( $(...)[x] ) is faster
than a
simple $(...).eq(x). That doesn't make much sense.
Currently the eq function looks like this:
eq: function( i ) {
return this.slice( i, +i + 1 );
},
Are there any downsides to changing it to this (object unique IDs,
chaining)?
eq: function( i ) {
return jQuery(this[i]);
},
That offers a 25% to 40% speed improvement across all browsers.
http://jquery.nodnod.net/cases/177
cheers,
- ricardo
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $( $(el)[x] ) is faster than $(el).eq(x)
Since .get(-1) will be supported, eq(-1) would be supported too (?).
So your implementation needs some extra code:
eq: function( i ) {
if ( i 0 )
i += this.length;
return this.pushStack( this[i], 'eq', i )
}
However this solution would be still faster then the one on
http://dev.jquery.com/ticket/4188, I suppose.
On Feb 26, 11:02 pm, ricardobeat ricardob...@gmail.com wrote:
Right, thanks!
Using pushStack seems ok, it's still chainable and keeps the selector
state, while still being at least twice faster.
http://dev.jquery.com/ticket/4262http://jquery.nodnod.net/cases/177/run
cheers,
- ricardo
On Feb 26, 11:28 am, John Resig jere...@gmail.com wrote:
Well, first I would argue that the two are not equivalent.
$($(...)[x]) doesn't maintain the stack. You can no longer do:
$(...).eq(1).addClass(test).end().appendTo(#foo);
$($(...)[x]) doesn't maintain the internal selector state for plugins.
For example if you checked $(...).eq(1).selector you'd see: .slice(1,
2)
So, with that in mind, if there were ways to maintain that
functionality and still get a performance speed-up, I'd definitely be
open to it.
--John
On Wed, Feb 25, 2009 at 11:41 PM, Ricardo Tomasi ricardob...@gmail.com
wrote:
Creating two jQuery objects + a lookup $( $(...)[x] ) is faster than a
simple $(...).eq(x). That doesn't make much sense.
Currently the eq function looks like this:
eq: function( i ) {
return this.slice( i, +i + 1 );
},
Are there any downsides to changing it to this (object unique IDs,
chaining)?
eq: function( i ) {
return jQuery(this[i]);
},
That offers a 25% to 40% speed improvement across all browsers.
http://jquery.nodnod.net/cases/177
cheers,
- ricardo
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: .get() vs .toArray(), .get(index) vs [index]
I made an update of the ticket 1 week ago (http://dev.jquery.com/ ticket/3999). Since .get(N) would not be deprecated, maybe it would be nice to be able to use it with negative (relative) indexes too. This would increase the chainability that makes jQuery so concise... I have already opened an ticket about this enhancement on http://dev.jquery.com/ticket/4188. On Feb 19, 8:46 pm, Justin Beasley justin.m.beas...@gmail.com wrote: I agre with this course of action also. I think it offers the best of both worlds, plus an extra dose of clarity. On Jan 26, 3:27 pm, Robert Katić robert.ka...@gmail.com wrote: Although, I think he's just saying leave in .get(N), deprecate .get(), add .toArray(). This sounds great to me. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $(a, b, c) and Elements in document order
Hm, how implemented, usage of the third argument would not guarantee
that the results will be sorted.
Take for example: Sizzle('foo.barr', null, anArray) - there is no
extra selector, so no sorting too.
On Feb 16, 2:22 pm, John Resig jere...@gmail.com wrote:
If I am right, with this implementation, with a, b, c the results
will be sorted twice.
If so, would it be enough to replace line 115 with this one?
if ( sortOrder !arguments[2] ) {
Maybe it looks dirty... but anyway sorting is not an cheap
operation...
That wouldn't be sufficient since it's possible to pass in a result
set to Sizzle itself (jQuery does this, for example, to get some
speed-ups).
I'm not hugely worried since the checks are pretty fast - but yeah,
eventually figuring out a way to optimize it would be fine.
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $(a, b, c) and Elements in document order
I know, but adding other elements to the results (given as argument)
will probably make the results array unsorted (even with duplicates).
On Feb 16, 2:47 pm, John Resig jere...@gmail.com wrote:
Hm, how implemented, usage of the third argument would not guarantee
that the results will be sorted.
Take for example: Sizzle('foo.barr', null, anArray) - there is no
extra selector, so no sorting too.
That's fine - since selectors that don't have a comma in them are
already in document order - no need to sort them again.
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $(a, b, c) and Elements in document order
So, if I understand you, the third argument is exposed to the API but
not like an set that will be filled with additional query, but like an
simple array which the new elements will be simply appended.
So if the user would use the third argument, later, he will eventually
resort and removes the duplicates too. Am I corect?
On Feb 16, 3:04 pm, Robert Katić robert.ka...@gmail.com wrote:
Maybe I was not clear. I don't think it is wrong to live results
unsorted if given as argument (if it was planed), but then we can take
this in consideration to do optimizations...
On Feb 16, 2:53 pm, Robert Katić robert.ka...@gmail.com wrote:
I know, but adding other elements to the results (given as argument)
will probably make the results array unsorted (even with duplicates).
On Feb 16, 2:47 pm, John Resig jere...@gmail.com wrote:
Hm, how implemented, usage of the third argument would not guarantee
that the results will be sorted.
Take for example: Sizzle('foo.barr', null, anArray) - there is no
extra selector, so no sorting too.
That's fine - since selectors that don't have a comma in them are
already in document order - no need to sort them again.
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $(a, b, c) and Elements in document order
To ensure order and uniqueness with XML and non current documents too,
we have to ensure that the NodeList allSort is the correct one.
Maybe something like this:
function sortNodes( array ) {
if ( array.length === 0 )
return;
if ( allSort allSort._document !== array[0].ownerDocument ) {
var doc = array[0].ownerDocument;
allSort = doc.getElementsByTagName(*);
allSort._document = doc;
}
hasDuplicate = false;
array.sort(sortOrder);
if ( hasDuplicate ) {
var i = array.length;
while ( i-- ) {
if ( array[i] === array[i-1] ) {
array.splice(i--, 1);
}
}
}
}
You will notice that this sorting function removes duplicates too. The
reason way I putted all inside, is the possibility to easily expose
this functionality to the API.
So in function Sizzle (line 115) it can be used like this:
if ( sortOrder arguments.callee !== arguments.callee.caller ) {
sortNodes( results );
}
Of course, in that case you will add this on line 689:
allSort._document = document;
or simply replace line 688 with:
allSort = true;
Or is there something that I haven't catch?
On Feb 14, 7:11 pm, John Resig jere...@gmail.com wrote:
Nice job John, I like your solution very much.
Thanks!
But if I am right, the querySelectorAll will always fall with no
standard filters, so we have to ensure order and uniqueness on all
browsers (?).
Ah - so you mean the case where someone does: div:first, p:first
Hmm - good point. I just landed a solution for this that seems to work
well:http://github.com/jeresig/sizzle/commit/c2f4a8a68f59409e86d6b0c01edea...
--John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $(a, b, c) and Elements in document order
Looks fine to me. Thx. On Feb 14, 7:11 pm, John Resig jere...@gmail.com wrote: Nice job John, I like your solution very much. Thanks! But if I am right, the querySelectorAll will always fall with no standard filters, so we have to ensure order and uniqueness on all browsers (?). Ah - so you mean the case where someone does: div:first, p:first Hmm - good point. I just landed a solution for this that seems to work well:http://github.com/jeresig/sizzle/commit/c2f4a8a68f59409e86d6b0c01edea... --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: $(a, b, c) and Elements in document order
Looks fine to me. Thx. On Feb 14, 7:11 pm, John Resig jere...@gmail.com wrote: Nice job John, I like your solution very much. Thanks! But if I am right, the querySelectorAll will always fall with no standard filters, so we have to ensure order and uniqueness on all browsers (?). Ah - so you mean the case where someone does: div:first, p:first Hmm - good point. I just landed a solution for this that seems to work well:http://github.com/jeresig/sizzle/commit/c2f4a8a68f59409e86d6b0c01edea... --John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] $(a, b, c) and Elements in document order
The querySelectorAll returns elements in documents order, but Sizzle
(for now?) treat each selector separately.
Maybe this can be easily resolved joining each result array in one
with nodes in documents order?
If so, maybe something like this would help (not tested). Or you are
thinking to sort results all together?
var precedes = ( document.documentElement.sourceIndex == 0 )
function( a, b ) {
return a.sourceIndex b.sourceIndex;
}
|| ( document.documentElement.compareDocumentPosition )
function( a, b ) {
return !!( a.compareDocumentPosition(b) 4 );
}
|| function( a, b ) {
if ( a === b || b.contains(a) )
return false
if ( a.contains(b) )
return true;
var c = a.parentNode;
while ( !c.contains(b) ) {
a = c;
c = c.parentNode;
}
var p = b.parentNode;
while ( p !== c ) {
b = p;
p = p.parentNode;
}
var nodes = c.childNodes;
for ( var i = 0, node = nodes[0]; node; node = nodes[+
+i] ) {
if ( node === a )
return true;
if ( node === b )
return false;
}
return false;
};
function joinResultsHelper( res, a, i, b, j ) {
if ( b[j] ) {
for ( var l = a.length; i l; ++i ) {
if ( a[i] === b[j] )
++j;
else if ( precedes(a[i], b[j]) )
res.push( a[i] );
else {
res.push( b[j++] );
joinResultsHelper( res, b, j, a, i );
break;
}
}
} else {
for ( var l = a.length; i l; ++i )
res.push( a[i] );
}
return res;
}
function joinResults( a, b ) {
if ( a.length === 0 )
return b;
if ( b.length === 0 )
return a;
return joinResultsHelper( [], a, 0, b, 0 );
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: $(a, b, c) and Elements in document order
Reasons why maybe an joinResults would be better/faster instead of an
sort are this:
1) Single selector (without comma) will easily return nodes in
document order and with no duplicates, so we have not to worry about
single selector results order and duplicates.
2) If we sort the final array we have to remove duplicates too (?).
However I am not sure if all this is true, so here an cmp function to
sort nodes in document order:
var cmpOrder = ( document.documentElement.sourceIndex == 0 )
function( a, b ) {
return a.sourceIndex - b.sourceIndex;
}
|| ( document.documentElement.compareDocumentPosition )
function( a, b ) {
var t = a.compareDocumentPosition(b);
return t ? ( t 4 ? -1 : 1 ) : 0;
}
|| function( a, b ) {
if ( a === b )
return 0;
if ( b.contains(a) )
return 1;
if ( a.contains(b) )
return -1;
var c = a.parentNode;
while ( !c.contains(b) ) {
a = c;
c = c.parentNode;
}
var p = b.parentNode;
while ( p !== c ) {
b = p;
p = p.parentNode;
}
var nodes = c.childNodes;
for ( var i = 0, node = nodes[0]; node; node = nodes[+
+i] ) {
if ( node === a )
return -1;
if ( node === b )
return 1;
}
return -1;
};
I also corrected again the joinResultsHelper (hope this one is ok):
function joinResultsHelper( res, a, i, b, j ) {
if ( b b[j] ) {
for ( var l = a.length; i l; ++i ) {
if ( a[i] === b[j] ) {
if ( !b[++j] )
return joinResultsHelper( res, a, i );
}
else if ( precedes(a[i], b[j]) )
res.push( a[i] );
else {
res.push( b[j++] );
return joinResultsHelper( res, b, j, a, i );
}
}
} else {
for ( var l = a.length; i l; ++i )
res.push( a[i] );
}
return res;
}
I doesn't know that Sizzle has an separate discussion group, so I
apologize.
On Feb 14, 2:33 am, Diego Perini diego.per...@gmail.com wrote:
Robert,
I have also needed this bit of help from jQuery...for extracting texts
from HTML code.
I proposed this similar solution on the Sizzle group some time ago:
http://groups.google.com/group/sizzlejs/browse_thread/thread/44d2b3fd...
which probably solves with a simpler sort() on the result set, maybe
only done when a comma (group separator) is found in the selector.
Maybe your code adds some way to do it faster or are there other
reasons to not use .sort() ?
Diego
On 14 Feb, 01:47, Robert Katić robert.ka...@gmail.com wrote:
I corrected the joinResultsHelper:
function joinResultsHelper( res, a, i, b, j ) {
if ( b b[j] ) {
for ( var l = a.length; i l; ++i ) {
if ( a[i] === b[j] !b[++j] )
return joinResultsHelper( res, a, i )
else if ( precedes(a[i], b[j]) )
res.push( a[i] );
else {
res.push( b[j++] );
joinResultsHelper( res, b, j, a, i );
break;
}
}
} else {
for ( var l = a.length; i l; ++i )
res.push( a[i] );
}
return res;
}
On Feb 14, 12:26 am, Robert Katić robert.ka...@gmail.com wrote:
The querySelectorAll returns elements in documents order, but Sizzle
(for now?) treat each selector separately.
Maybe this can be easily resolved joining each result array in one
with nodes in documents order?
If so, maybe something like this would help (not tested). Or you are
thinking to sort results all together?
var precedes = ( document.documentElement.sourceIndex == 0 )
function( a, b ) {
return a.sourceIndex b.sourceIndex;
}
|| ( document.documentElement.compareDocumentPosition )
function( a, b ) {
return !!( a.compareDocumentPosition(b) 4 );
}
|| function( a, b ) {
if ( a === b || b.contains(a) )
return false
if ( a.contains(b) )
return true;
var c = a.parentNode;
while ( !c.contains(b) ) {
a = c;
c = c.parentNode;
}
var p = b.parentNode;
while ( p !== c ) {
b = p;
p = p.parentNode;
}
var nodes = c.childNodes;
for ( var i = 0, node = nodes[0]; node; node = nodes[+
+i] ) {
if ( node === a )
return true;
if ( node
[jquery-dev] .get() vs .toArray(), .get(index) vs [index]
My English is not so good so will be short.
I am not sure why the get() function exists. Because it is shorter
then toArray()? But my code would by more clear with an toArray
instead, An foo.get(index) is not clearer nor shorter then foo[index]
for me.
In my opinion the get function is not really necessary and would by
deprecated if an more explicit toArray would exists.
The implementation of toArray() would be banal:
jQuery.fn.toArray = function() { return Array.prototype.slice.apply
(this, arguments) };
or even:
jQuery.fn.toArray = Array.prototype.slice;
Thoughts? Am I disregarding something here?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: .get() vs .toArray(), .get(index) vs [index]
Ticket about this is http://dev.jquery.com/ticket/3999.
On Jan 26, 8:10 pm, John Resig jere...@gmail.com wrote:
We can consider it - you should file an enhancement
bug.http://dev.jquery.com/newticket
--John
On Mon, Jan 26, 2009 at 10:14 AM, Robert Katić robert.ka...@gmail.com wrote:
My English is not so good so will be short.
I am not sure why the get() function exists. Because it is shorter
then toArray()? But my code would by more clear with an toArray
instead, An foo.get(index) is not clearer nor shorter then foo[index]
for me.
In my opinion the get function is not really necessary and would by
deprecated if an more explicit toArray would exists.
The implementation of toArray() would be banal:
jQuery.fn.toArray = function() { return Array.prototype.slice.apply
(this, arguments) };
or even:
jQuery.fn.toArray = Array.prototype.slice;
Thoughts? Am I disregarding something here?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: .get() vs .toArray(), .get(index) vs [index]
@Már The reason of posting here, is because, in my opinion, the get() makes code less readable. If an considerable number of developers think the same, maybe it is time to resolve this in jQuery directly, because it is better then encourage developers to create own dialects (bunch of aliases). On Jan 26, 11:44 pm, Már Örlygsson mar.orlygs...@gmail.com wrote: Robert: while I agree with you that the whole .get() thing has always seemed kind of weird, it's now part of jQuery history and cannot be easily changed. If it bugs you, just write your own alias: jQuery.fn.toArray = jQuery.fn.get; ...and make sure to always access single element with collection[index]; rather than collection.get(index); And you'll never notice the difference. -- Már Örlygsson --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: .index() enhancement
Maybe it would be better to return the index of the element in a new
jQuery obj from selector only if elem === undefined
Regardin jQuery.inArray maybe it would be useful to heve an
jQuery.lastInArray too. Maybe with start/end index as the thrd
argument?
Something like this:
jQuery.inArray = Array.indexOf ? //some browsers have this
function(elem, array, i) {
return Array.indexOf(array, elem, i);
} :
function(array, elem, i) {
var l = array.length;
i = i === undefined ? 0 :
i 0 ? Math.ceil(i) + l :
Math.floor(i);
for (; i l; ++i)
if (array[i] === elem)
return i;
return -1;
};
jQuery.lastInArray = Array.lastIndexOf ? //some browsers have this
function(elem, array, i) {
return Array.lastIndexOf(array, elem, i);
} :
function(elem, array, i) {
var l = array.length
i = i === undefined ? l-1 :
i 0 ? Math.ceil(i) + l :
Math.floor(i);
while ( i )
if ( seq[--i] === value )
return i;
return -1;
}
Thoughts?
On Jan 23, 3:21 am, John Resig jere...@gmail.com wrote:
Yeah, I can dig this. You should file an enhancement ticket.
--John
On Thu, Jan 22, 2009 at 9:10 PM, ajpiano ajpi...@gmail.com wrote:
It would be useful to be able to use the .index() method to find the
index of the current element in a given set, rather than the current
implementation (searching the current set for a given element), which
forces the developer to do gyrations in order to find out a simple
piece of info.
For instance
$(#sometable th img).click(function() {
//find out index of img's parent th in its own tr
var $th = $(this).parent();
//now we have a few not so great choices
//1.
var index = $(#sometable thead tr).index($th);
//2.
var index = $th.parent().children().index($th);
//3. doesn't even work, but many would assume it would, and it
doesn't!)
// because the desired element is always the last one in the set.
var index = $th.siblings().andSelf().index($th);
});
Paul Irish and I propose the following enhancement, which is rough and
we welcome any suggestions...
jQuery.fn.index = function(elem){
// legacy implementation
if ( typeof elem === 'object'){
return jQuery.inArray(
elem elem.jquery ? elem[0] : elem
, this );
}
//return the index of the element in a new jQuery obj from selector,
or by default, amongst its own siblings.
return jQuery.inArray(this[0],
elem ? jQuery(elem) : this.parent().children() );
};
which would allow for the following.
$(#sometable th img).click(function() {
//find out index of img's parent th in its own tr
var index = $(this).parent().index();
//for sake of example, index of image in set of all images.
var imgIndex = $(this).index(img);
});
If people think this is worthwhile, we will post an enhancement
ticket. Thoughts?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: .index() enhancement
I noticed some errors in my code (it was written directly...), so here
is the corrected one:
jQuery.inArray = Array.indexOf ?
function(elem, array, i) {
return Array.indexOf(array, elem, i);
} :
function(elem, array, i) {
var l = array.length;
i = i === undefined ? 0 :
i 0 ? Math.ceil(i) + l :
Math.floor(i);
for (; i l; ++i)
if ( array[i] === elem )
return i;
return -1;
};
jQuery.lastInArray = Array.lastIndexOf ?
function(elem, array, i) {
return Array.lastIndexOf(array, elem, i);
} :
function(elem, array, i) {
var l = array.length
i = i === undefined ? l-1 :
i 0 ? Math.ceil(i) + l :
Math.floor(i);
for (; i -1; --i)
if ( array[i] === value )
return i;
return -1;
}
Hope it is ok now...
On Jan 23, 9:45 am, Robert Katić robert.ka...@gmail.com wrote:
Maybe it would be better to return the index of the element in a new
jQuery obj from selector only if elem === undefined
Regardin jQuery.inArray maybe it would be useful to heve an
jQuery.lastInArray too. Maybe with start/end index as the thrd
argument?
Something like this:
jQuery.inArray = Array.indexOf ? //some browsers have this
function(elem, array, i) {
return Array.indexOf(array, elem, i);
} :
function(array, elem, i) {
var l = array.length;
i = i === undefined ? 0 :
i 0 ? Math.ceil(i) + l :
Math.floor(i);
for (; i l; ++i)
if (array[i] === elem)
return i;
return -1;
};
jQuery.lastInArray = Array.lastIndexOf ? //some browsers have this
function(elem, array, i) {
return Array.lastIndexOf(array, elem, i);
} :
function(elem, array, i) {
var l = array.length
i = i === undefined ? l-1 :
i 0 ? Math.ceil(i) + l :
Math.floor(i);
while ( i )
if ( seq[--i] === value )
return i;
return -1;
}
Thoughts?
On Jan 23, 3:21 am, John Resig jere...@gmail.com wrote:
Yeah, I can dig this. You should file an enhancement ticket.
--John
On Thu, Jan 22, 2009 at 9:10 PM, ajpiano ajpi...@gmail.com wrote:
It would be useful to be able to use the .index() method to find the
index of the current element in a given set, rather than the current
implementation (searching the current set for a given element), which
forces the developer to do gyrations in order to find out a simple
piece of info.
For instance
$(#sometable th img).click(function() {
//find out index of img's parent th in its own tr
var $th = $(this).parent();
//now we have a few not so great choices
//1.
var index = $(#sometable thead tr).index($th);
//2.
var index = $th.parent().children().index($th);
//3. doesn't even work, but many would assume it would, and it
doesn't!)
// because the desired element is always the last one in the set.
var index = $th.siblings().andSelf().index($th);
});
Paul Irish and I propose the following enhancement, which is rough and
we welcome any suggestions...
jQuery.fn.index = function(elem){
// legacy implementation
if ( typeof elem === 'object'){
return jQuery.inArray(
elem elem.jquery ? elem[0] : elem
, this );
}
//return the index of the element in a new jQuery obj from selector,
or by default, amongst its own siblings.
return jQuery.inArray(this[0],
elem ? jQuery(elem) : this.parent().children() );
};
which would allow for the following.
$(#sometable th img).click(function() {
//find out index of img's parent th in its own tr
var index = $(this).parent().index();
//for sake of example, index of image in set of all images.
var imgIndex = $(this).index(img);
});
If people think this is worthwhile, we will post an enhancement
ticket. Thoughts?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
