[jquery-dev] Re: about iterators, closures and scope
I make always an a reference to my instance with var self = this; and
using always 'self' namespace after that, at this way you can be
always sure accessing the right object.
I think jQuery is alwas referencing 'this' to current elements set, so
jquery can't and won't to do any exception in case of each method.
Its the style of jquery, because almost all methods you are using by
jquery are bounded to elements.
On Aug 11, 12:37 am, Tarini tarin...@gmail.com wrote:
thanks guys for you answer but I know how to use $.each in OO context...
I would like to understand why jQuery works in this way..
What are the advantage using this inside closure instead of using a temp
arguments like the index? I see only disadvantage...
I also created a plugin (http://code.google.com/p/jquerycallback/) to
manage callback using OO but this remain one of the (few) aspects of
jQuery I don't like and I would like to get a reason :)
Also...
Thinking about OOP... are you really sure that jQuery isn't a OO library
(or framework as you prefer)?
Two considerations about this relationship between jQuery and OOP:
- jQuery selectors are a strange way to construct an object, an
alternative constructor starting from a dollar sign and not with new
keyword ( var divs = $(div) should be written as var divs = new
jQuery(div) )
- jQuery function (events, attributes, traversing, ecc...) are a lot of
methods of jQuery object... they aren't simple namespaced function in a
functional paradigm.
(alternative) constructor + a lot of methods = object oriented
programming
why not?
I hope to get some reply ;)
On Fri, 2009-08-07 at 07:37 -0700, aHeckman wrote:
@ludovic, javascript IS an object oriented language. There is no need
for simulation. It's just a different type of oop than classical.
function Person (name) {
this.name = name || 'Nobody';
}
Person.prototype = {
sayName: function () {
alert('Hi my name is ' + this.name);
}
};
var ludovic = new Person('ludovic')
On Aug 7, 8:13 am, ludovic ludothebe...@gmail.com wrote:
If you want to keep you function's context, you can still do
$('div').each( function() {
Context.myFunction( this );
} );
Anyway, I'm not sure it's a good idea to try to simulate object
oriented syntax with javascript.
It isn't an object oriented language and trying to make a language in
a foreign paradigm is always heavy.
But it is a personal opinion...
---
Ludovic
--~--~-~--~~~---~--~~
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: about iterators, closures and scope
I think you guys are missing the point. This isn't a question about object-oriented programming (in JavaScript or otherwise). It's about jQuery's handling of this within the context of each. To answer the original question, I don't think there's any real reason for it. It was an unfortunate blunder (probably intended for convenience) that will probably remain (for backwards compatibility). As said, you can store the reference to this in a variable, so you can work around it. --~--~-~--~~~---~--~~ 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: about iterators, closures and scope
There definitely is a reason for it. jQuery is a library for working with the DOM, it is not a library meant to fix every problem with JavaScript or to try to extend JavaScript in every possible way. When using jQuery specifically to work with the DOM (probably 90% of what you're using it for, and 100% of what the average user uses it for), it makes perfect sense to set the context to the current item. Also, native event handlers set the context to the event target, so jQuery had an existing model to follow. On Aug 11, 6:09 am, Pauan pcxunlimi...@gmail.com wrote: I think you guys are missing the point. This isn't a question about object-oriented programming (in JavaScript or otherwise). It's about jQuery's handling of this within the context of each. To answer the original question, I don't think there's any real reason for it. It was an unfortunate blunder (probably intended for convenience) that will probably remain (for backwards compatibility). As said, you can store the reference to this in a variable, so you can work around it. --~--~-~--~~~---~--~~ 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: hide() with 0ms with not call callback
.hide(0) should have exactly the same behavior as .hide(1000) with $.fx.off = true; On Aug 10, 9:43 pm, Dave Methvin dave.meth...@gmail.com wrote: There's already an open ticket on this, it does seem like the callback should be called. http://dev.jquery.com/ticket/2542 --~--~-~--~~~---~--~~ 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: about iterators, closures and scope
And how is it inferior to set the current item as an argument to the callback? This is how Array.prototype.forEach works. It causes less problems while providing the exact same functionality. Also, event handlers are not the same as functions used to iterate over an object, nor do they serve the same purpose, so one model doesn't necessarily apply to the other. On Aug 11, 6:10 am, Scott González scott.gonza...@gmail.com wrote: There definitely is a reason for it. jQuery is a library for working with the DOM, it is not a library meant to fix every problem with JavaScript or to try to extend JavaScript in every possible way. When using jQuery specifically to work with the DOM (probably 90% of what you're using it for, and 100% of what the average user uses it for), it makes perfect sense to set the context to the current item. Also, native event handlers set the context to the event target, so jQuery had an existing model to follow. --~--~-~--~~~---~--~~ 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: Object is undefined - any insight appreciated.
Sorry, I could not resist ;o)
// enclosure
(function () {
// key elements selected only once
var $THAT = $(that) , // must be valid dom node
$verb_content = $(#verb-content) ,
$adj_content = $(#adj-content) ,
$subj_content = $(#subj-content) ;
// core logic
function loop ( ARR, $C, TC )
{
var verbTime = ~~(Math.random()*TC);
for(var i = 0; iARR.length; i++){
$C.fadeOut(
verbTime,
function(){$THAT.text(ARR[i]).fadeIn(verbTime);}
);
}
}
jQuery.ajax({
type : POST,
dataType : json,
url : js/tsbtw-object.js,
success : function(data, statusText){
loop( data.verbs, $verb_content, 1000 ) ;
loop( data.adjectives, $adj_content, 2000 ) ;
loop( data.subjects, $subj_content, 3000 ) ;
},
error: function (xhr, ajaxOptions, thrownError){
your_logger(xhr.statusText, thrownError);
}
}) ; // eof ajax()
})() ;
--~--~-~--~~~---~--~~
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: Object is undefined - any insight appreciated.
And I am the one who writes obfuscated code ... *var verbTime = ~~(Math.random()*TC);* two operations just to obtain a floor? try again: *var verbTime = (Math.random()*TC) 0;* Regards --~--~-~--~~~---~--~~ 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: about iterators, closures and scope
Event callback: function(eventObject) { this = domnode }// Because
that's the way events have always worked
each() callback: function(index, sameAsThis) { this = item/domnode } //
Keeping the pattern
map() callback: function(index, sameAsThis) { this = item/domnode } //
Keeping the pattern
filter() callback: function(index) { this = item/domnode } // sorta
keeping the pattern
vs.
Event callback: function(eventObject) { this = domnode } // event
callbacks MUST use this as domnode, otherwise you destroy the api it was
based on
each() callback: function(item, index?) { ... }
map() callback: function(item, index?) { ... }
filter() callback: function(item, index?) { ... }
Whether you like it or not, jQuery is a library for working with the
dom. Thus when created each/map/filter had nothing to do with the array
methods that have only been put into browsers recently (yes, recently...
you are comparing standards set by new features, with decisions that
were made years ago; not the best comparison), they were created to give
control over the jQuery object's list of dom nodes. Thus, since all the
other apis which worked with dom nodes used `this` to refer to the dom
node that same api was used when writing those methods.
It's only a side effect that these methods happen to be usable on
non-domlist arrays. Though frankly, imho that is abuse, these methods
are not meant for that purpose, you can plainly see that in how $.fn.map
differs from Array.prototype.map in how it folds arrays into the list
rather than adding them as items.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Pauan wrote:
And how is it inferior to set the current item as an argument to the
callback? This is how Array.prototype.forEach works. It causes less
problems while providing the exact same functionality. Also, event
handlers are not the same as functions used to iterate over an object,
nor do they serve the same purpose, so one model doesn't necessarily
apply to the other.
On Aug 11, 6:10 am, Scott González scott.gonza...@gmail.com wrote:
There definitely is a reason for it. jQuery is a library for working
with the DOM, it is not a library meant to fix every problem with
JavaScript or to try to extend JavaScript in every possible way. When
using jQuery specifically to work with the DOM (probably 90% of what
you're using it for, and 100% of what the average user uses it for),
it makes perfect sense to set the context to the current item. Also,
native event handlers set the context to the event target, so jQuery
had an existing model to follow.
--~--~-~--~~~---~--~~
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: Bug: selectors with commas in IE 7
I have confirmed that this is happening for other people in the IRC channel, and added some more information to the bug report. Most importantly, this bug is not present in Internet Explorer 8 running in Internet Explorer 7 developer mode, only in the real Internet Explorer 7. http://dev.jquery.com/ticket/4999#comment:1 -matt On Aug 7, 11:57 am, Matt Chisholm glypho...@gmail.com wrote: I recently posted this bug regarding selectors with commas in IE 7. It includes a minimal test case. http://dev.jquery.com/ticket/4999 I was just wondering if anybody had had the time to look into it. :) -matt --~--~-~--~~~---~--~~ 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: Bug: selectors with commas in IE 7
Unfortunately I haven't had a chance to look in to this yet, but thanks for your reduction - it'll certainly help! --John On Tue, Aug 11, 2009 at 1:55 PM, glyphobet glypho...@gmail.com wrote: I have confirmed that this is happening for other people in the IRC channel, and added some more information to the bug report. Most importantly, this bug is not present in Internet Explorer 8 running in Internet Explorer 7 developer mode, only in the real Internet Explorer 7. http://dev.jquery.com/ticket/4999#comment:1 -matt On Aug 7, 11:57 am, Matt Chisholm glypho...@gmail.com wrote: I recently posted this bug regarding selectors with commas in IE 7. It includes a minimal test case. http://dev.jquery.com/ticket/4999 I was just wondering if anybody had had the time to look into it. :) -matt --~--~-~--~~~---~--~~ 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] Recursive $.extend should manage loops
Hi,
I've got loops in my objects relations. Example :
var father = {
child : {}
}
father.child.father = father;
$.extends( true, {}, father ) causes a infinite loop.
Jquery should reproduce loops.
Regards,
Ludovic
--~--~-~--~~~---~--~~
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: Recursive $.extend should manage loops
jQuery does reproduce loops:
var father = {
child : {}
}
father.child.father = father;
$.extends( {}, father )
The problem here is you are telling jQuery to recurse into things it
shouldn't be recursing into.
$.extends( true, .. ); is for when you want to duplicate nested objects,
rather than reference the same objects.
By definition, you are asking jQuery to:
Take {}
Take the keys in father:
for the child key:
create an object to make a duplicate using and place that onto {}.child
recurse into child:
for the father key:
create an object to make a duplicate using and place that onto
child.father
recurse into father:
for the child key:
create an object to make a duplicate using and place
that onto father.child
recurse into child:
...
There is no problem here, jQuery is following your orders just as you
give them.
If jQuery were to try and track circular references it would:
A) Make .extends extremely inefficient because it would have to store
just about everything it touches and make sure it doesn't recurse
B) No longer create duplicate objects as it was told to
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
ludovic wrote:
Hi,
I've got loops in my objects relations. Example :
var father = {
child : {}
}
father.child.father = father;
$.extends( true, {}, father ) causes a infinite loop.
Jquery should reproduce loops.
Regards,
Ludovic
--~--~-~--~~~---~--~~
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: Recursive $.extend should manage loops
If jQuery were to try and track circular references it would:
A) Make .extends extremely inefficient because it would have to store
just about everything it touches and make sure it doesn't recurse
B) No longer create duplicate objects as it was told to
For B), it would create duplicates objects as it wouldn't be the same
objects as source, but it would conserve cycles inside an object
graph.
It don't think it causes a semantical problem, as when you copy a
graph, it would be normal to copy relations between nodes too.
For A), this is another problem. Yes, it could reduce performances as
we would have to create a mapping object and we would have to test and
add every object on it.
But,
- after all, it is only a condition to add
if( typeof mapping[ copy ] != 'undefined' ) {
target[ name ] = mapping[ copy ];
}
where copy would be the object inside a cycle. In fact, it is a bit
more complex, but not more costly
- When I see the complexity of some functions to have exactly the
exact rendering we want, I don't understand why it causes a problem to
add one or two conditions and store temporarily data.
Ludovic
--~--~-~--~~~---~--~~
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: Recursive $.extend should manage loops
- after all, it is only a condition to add
if( typeof mapping[ copy ] != 'undefined' ) {
target[ name ] = mapping[ copy ];
}
where copy would be the object inside a cycle. In fact, it is a bit
more complex, but not more costly
Well, except you have to hash the object to get an accurate key for the
object property.
I don't particularly think that this is something worth pursuing.
--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: prototypal inheritance as part of jQuery core?
Of course, if you optimize it in this way to share a single constructor
function, you can't find the prototype of an object created with beget()
with o.constructor.prototype. Not sure how important that is, but there
is a downside to the optimization.
David
Andrea Giammarchi wrote:
Dunno how many times that bedge has been optimized ;-)
(function(){
var F = function(){};
jQuery.beget = function (proto, props) {
F.prototype = proto;
return props ? $.extend(new F, props) : new F;
};
})();
Regards
On Thu, Jul 30, 2009 at 3:48 PM, Már Örlygsson mar.orlygs...@gmail.com
mailto:mar.orlygs...@gmail.com wrote:
Hi.
If it hasn't been already considered (and rejected), I'd like to float
the idea of adding support for prototypal inheritance into the jQuery
core library.
Something like this...
jQuery.beget = function (proto, props) {
var F = function () {};
F.prototype = proto;
var instance = new F();
return props ? $.extend(instance, props) : instance;
};
...becomes immensely powerful - especially during plugin development
when allowing users to extend/override default options
options = $.beget($.myplugin.defaults, options || {});
...and in various other common use cases - including $.fn.data()
assignments, etc.
I for one would love to see this feature added.
--
Már
--~--~-~--~~~---~--~~
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?
David, read carefully, think, and try again On Tue, Aug 11, 2009 at 11:16 PM, David Flanagan da...@davidflanagan.comwrote: Of course, if you optimize it in this way to share a single constructor function, you can't find the prototype of an object created with beget() with o.constructor.prototype. Not sure how important that is, but there is a downside to the optimization. David --~--~-~--~~~---~--~~ 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?
Or better, demonstrate that the constructor will not simply be the one associated with the proto object in my function or try to retrieve that function in whatever way you want. After that, have a look here: http://www.3site.eu/doc/ Regards On Tue, Aug 11, 2009 at 11:50 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: David, read carefully, think, and try again On Tue, Aug 11, 2009 at 11:16 PM, David Flanagan da...@davidflanagan.comwrote: Of course, if you optimize it in this way to share a single constructor function, you can't find the prototype of an object created with beget() with o.constructor.prototype. Not sure how important that is, but there is a downside to the optimization. David --~--~-~--~~~---~--~~ 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?
Umm, dunno if you guys read my posts above, but you might want to. On Aug 12, 8:51 am, Andrea Giammarchi andrea.giammar...@gmail.com wrote: Or better, demonstrate that the constructor will not simply be the one associated with the proto object in my function or try to retrieve that function in whatever way you want. After that, have a look here:http://www.3site.eu/doc/ Regards On Tue, Aug 11, 2009 at 11:50 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: David, read carefully, think, and try again On Tue, Aug 11, 2009 at 11:16 PM, David Flanagan da...@davidflanagan.comwrote: Of course, if you optimize it in this way to share a single constructor function, you can't find the prototype of an object created with beget() with o.constructor.prototype. Not sure how important that is, but there is a downside to the optimization. David --~--~-~--~~~---~--~~ 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?
ES5 + .extend is not necessary for this simple chunk.
(function($){
if (!Object.create)
var F = function(){};
$.beget = function (proto, props) {
if(Object.create)
var o = Object.create(proto);
else {
F.prototype = proto;
var o = new F;
}
for ( var k in props )
o[k] = props[k];
return o;
};
})(jQuery);
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Andrea Giammarchi wrote:
Dunno how many times that bedge has been optimized ;-)
(function(){
var F = function(){};
jQuery.beget = function (proto, props) {
F.prototype = proto;
return props ? $.extend(new F, props) : new F;
};
})();
Regards
On Thu, Jul 30, 2009 at 3:48 PM, Már Örlygsson
mar.orlygs...@gmail.com mailto:mar.orlygs...@gmail.com wrote:
Hi.
If it hasn't been already considered (and rejected), I'd like to float
the idea of adding support for prototypal inheritance into the jQuery
core library.
Something like this...
jQuery.beget = function (proto, props) {
var F = function () {};
F.prototype = proto;
var instance = new F();
return props ? $.extend(instance, props) : instance;
};
...becomes immensely powerful - especially during plugin development
when allowing users to extend/override default options
options = $.beget($.myplugin.defaults, options || {});
...and in various other common use cases - including $.fn.data()
assignments, etc.
I for one would love to see this feature added.
--
Már
--~--~-~--~~~---~--~~
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?
that is why I already use Obejct.create in vice-versa only if not defined
and when it will be standard the jQuery way will be simply this one:
$.extends(Object.create(proto), props);
the bedge callback was just an optimized suggestion over a snipped based on
a dated proposal.
Regards
P.S. not sure if Object.create will support directly the extra argument, I
have implemented it without classic toString and other failures
On Wed, Aug 12, 2009 at 12:15 AM, Daniel Friesen
nadir.seen.f...@gmail.comwrote:
ES5 + .extend is not necessary for this simple chunk.
(function($){
if (!Object.create)
var F = function(){};
$.beget = function (proto, props) {
if(Object.create)
var o = Object.create(proto);
else {
F.prototype = proto;
var o = new F;
}
for ( var k in props )
o[k] = props[k];
return o;
};
})(jQuery);
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Andrea Giammarchi wrote:
Dunno how many times that bedge has been optimized ;-)
(function(){
var F = function(){};
jQuery.beget = function (proto, props) {
F.prototype = proto;
return props ? $.extend(new F, props) : new F;
};
})();
Regards
On Thu, Jul 30, 2009 at 3:48 PM, Már Örlygsson
mar.orlygs...@gmail.com mailto:mar.orlygs...@gmail.com wrote:
Hi.
If it hasn't been already considered (and rejected), I'd like to
float
the idea of adding support for prototypal inheritance into the jQuery
core library.
Something like this...
jQuery.beget = function (proto, props) {
var F = function () {};
F.prototype = proto;
var instance = new F();
return props ? $.extend(instance, props) : instance;
};
...becomes immensely powerful - especially during plugin development
when allowing users to extend/override default options
options = $.beget($.myplugin.defaults, options || {});
...and in various other common use cases - including $.fn.data()
assignments, etc.
I for one would love to see this feature added.
--
Már
--~--~-~--~~~---~--~~
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?
I'm not seeing any functionality that can't already be done. It might
take off a few lines of code, but this doesn't really add anything
useful. If it allowed namespaces and the ability to use 'this' inside
the namespaces as you would in jQuery, then I, for one, would find it
very useful.
On Aug 12, 9:40 am, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
that is why I already use Obejct.create in vice-versa only if not defined
and when it will be standard the jQuery way will be simply this one:
$.extends(Object.create(proto), props);
the bedge callback was just an optimized suggestion over a snipped based on
a dated proposal.
Regards
P.S. not sure if Object.create will support directly the extra argument, I
have implemented it without classic toString and other failures
On Wed, Aug 12, 2009 at 12:15 AM, Daniel Friesen
nadir.seen.f...@gmail.comwrote:
ES5 + .extend is not necessary for this simple chunk.
(function($){
if (!Object.create)
var F = function(){};
$.beget = function (proto, props) {
if(Object.create)
var o = Object.create(proto);
else {
F.prototype = proto;
var o = new F;
}
for ( var k in props )
o[k] = props[k];
return o;
};
})(jQuery);
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Andrea Giammarchi wrote:
Dunno how many times that bedge has been optimized ;-)
(function(){
var F = function(){};
jQuery.beget = function (proto, props) {
F.prototype = proto;
return props ? $.extend(new F, props) : new F;
};
})();
Regards
On Thu, Jul 30, 2009 at 3:48 PM, Már Örlygsson
mar.orlygs...@gmail.com mailto:mar.orlygs...@gmail.com wrote:
Hi.
If it hasn't been already considered (and rejected), I'd like to
float
the idea of adding support for prototypal inheritance into the jQuery
core library.
Something like this...
jQuery.beget = function (proto, props) {
var F = function () {};
F.prototype = proto;
var instance = new F();
return props ? $.extend(instance, props) : instance;
};
...becomes immensely powerful - especially during plugin development
when allowing users to extend/override default options
options = $.beget($.myplugin.defaults, options || {});
...and in various other common use cases - including $.fn.data()
assignments, etc.
I for one would love to see this feature added.
--
Már
--~--~-~--~~~---~--~~
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: Object is undefined - any insight appreciated.
for(var i = 0; iARR.length; i++){
$C.fadeOut(
verbTime,
function(){$THAT.text(ARR[i]).fadeIn(verbTime);}
);
}
}
That code has the same problem as the original, though. It is going to
queue up ARR.length-1 fadeOut operations that all have i==ARR.length
and fail. To get the code to work you need to create a closure
*within* the loop that captures the current loop value, which
jQuery.each does for you. Or 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-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?
Well! Maybe you *should* read a good book on JavaScript before you go making careless posts again. All we know about here is jQuery, but the guys on comp.lang.javascript said there's only one good JavaScript book. Definitive something or other. It shouldn't be too hard to track down. I hear it's pretty good, maybe you could learn something from it! -Mike From: David Flanagan My carelessness, however, is not sufficient reason for you to accuse me of posting without reading or thinking. This is a -dev level mailing list. You must assume that all posters here are well-read and thoughtful. Otherwise you sound paternalistic! --~--~-~--~~~---~--~~ 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?
Haha, you guys crack me up. --John On Tue, Aug 11, 2009 at 9:23 PM, Michael Geary m...@mg.to wrote: Well! Maybe you *should* read a good book on JavaScript before you go making careless posts again. All we know about here is jQuery, but the guys on comp.lang.javascript said there's only one good JavaScript book. Definitive something or other. It shouldn't be too hard to track down. I hear it's pretty good, maybe you could learn something from it! -Mike From: David Flanagan My carelessness, however, is not sufficient reason for you to accuse me of posting without reading or thinking. This is a -dev level mailing list. You must assume that all posters here are well-read and thoughtful. Otherwise you sound paternalistic! --~--~-~--~~~---~--~~ 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: about iterators, closures and scope
I agree. As said, it was an unfortunate blunder that will probably
remain for the forseeable future.
On the plus side, it's not terribly hard to work around, and if it's a
major problem you can overwrite the jQuery.fn.each function, or even
jQuery.each (it shouldn't be that big of a deal, though).
On Aug 11, 9:31 am, Daniel Friesen nadir.seen.f...@gmail.com wrote:
Event callback: function(eventObject) { this = domnode }// Because
that's the way events have always worked
each() callback: function(index, sameAsThis) { this = item/domnode } //
Keeping the pattern
map() callback: function(index, sameAsThis) { this = item/domnode } //
Keeping the pattern
filter() callback: function(index) { this = item/domnode } // sorta
keeping the pattern
vs.
Event callback: function(eventObject) { this = domnode } // event
callbacks MUST use this as domnode, otherwise you destroy the api it was
based on
each() callback: function(item, index?) { ... }
map() callback: function(item, index?) { ... }
filter() callback: function(item, index?) { ... }
Whether you like it or not, jQuery is a library for working with the
dom. Thus when created each/map/filter had nothing to do with the array
methods that have only been put into browsers recently (yes, recently...
you are comparing standards set by new features, with decisions that
were made years ago; not the best comparison), they were created to give
control over the jQuery object's list of dom nodes. Thus, since all the
other apis which worked with dom nodes used `this` to refer to the dom
node that same api was used when writing those methods.
It's only a side effect that these methods happen to be usable on
non-domlist arrays. Though frankly, imho that is abuse, these methods
are not meant for that purpose, you can plainly see that in how $.fn.map
differs from Array.prototype.map in how it folds arrays into the list
rather than adding them as items.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
--~--~-~--~~~---~--~~
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: Is jquery still not handling namespaces?
I have looked a little more, and found some behavior that puzzles me.
Desespite the claim that jquery doesn't support namespaces,
$([x:\\name]) or $('[x:\\name=value]')
_does_ work to select nodes in the original dom.
however,
$(document).find([x:\\name])
does not.
I had assume that find() used the same code as the basic selector, so
what is causing this difference?
Also, if I use jquery to _construct_ a document fragment with a
namespaced attribute, then the $([attrib],fragment) selector fails to
find it.
So to summarize, namespaced attributes work if and only if they are
defined in the dom and found using $([attrib]) instead of $().find
([attrib]). Why is this?
Test code enclosed:
html
head
titleTest/title
script src=http://jqueryjs.googlecode.com/files/
jquery-1.3.2.js/script
/head
body
BFragments for tests:/B
div id=fragments
div id=indom
div ex:method=indom
this was a namespaced in-DOM div
/div
/div
div id=indom-safe
div safe=indom
this was a safe in-DOM div
/div
/div
/div
BTesting $('[attrib]'):/B
div id=select-exist/div
BTesting $(#id).find([attrib]) etc:/B
div id=find-exist/div
script
var written=$('divdiv id=writtendiv ex:method=writtenthis
was a namespaced jquery-written fragment/div/div/div');
var writtenSafe=$('divdiv id=written-safediv
safe=writtenthis was a safe jquery-written fragment/div/div/
div');
var selectInSafe=$('[safe]');
var selectIn=$('[ex\\:method]');
var selectWrittenSafe=$('[safe]',writtenSafe);
var selectWritten=$('[ex\\:method]',written);
var findInSafe=$(#indom-safe).find('[safe]');
var findIn=$(#indom).find('[ex\\:method]');
var findWrittenSafe=writtenSafe.find('[safe]');
var findWritten=written.find('[ex\\:method]');
$(#select-exist)
.append(selectInSafe.clone())
.append(selectWrittenSafe.clone())
.append(selectIn.clone())
.append(selectWritten.clone());
$(#find-exist)
.append(findInSafe.clone())
.append(findWrittenSafe.clone())
.append(findIn.clone())
.append(findWritten.clone());
written.children().clone().appendTo(#fragments);
writtenSafe.children().clone().appendTo(#fragments);
/script
/body
On Aug 10, 11:15 am, David kar...@csail.mit.edu wrote:
thanks; this is helpful.
On Aug 10, 3:52 am, DBJDBJ dbj...@gmail.com wrote:
var $xml = $(x:root xmlns:x='uri' xmlns:y='uir2' x:node
x:name='n1'No /x:nodey:nodenamespaces/y:node/x:root);
$xml.find(*[x:name=n1]).length 1
/*
Syntax error, unrecognized expression: [x:name=n1]
*/
$xml.find(*[x\\:name=n1]).length 1
/*
true
*/
$xml.find(*[name=n1]).length 1
/*
true
*/
Therefore :
1. *Sizzle* does not support namespaces in selector syntax
2. for node selectors namespaces will be ignored
3. for attribute selectors namespaces are provoking error . silent or
not.
Please see this
too:http://groups.google.com/group/sizzlejs/browse_thread/thread/48ef4372...
--~--~-~--~~~---~--~~
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] Autocomplete Flush Cache
hi I m using that jquery autocomplete library. http://docs.jquery.com/Plugins/Autocomplete It works fine. I wanted to know how long cache will keep a suggestion for a particular pattern. Ex: Say I typed d.After that there will be an Ajax request and a suggestion list is displayed then matched list for d is cached.Which means if I delete the first letter again and type d,It will not generate ajax request.But I found out that , after typing some letters, again if I type d it ll cause an Ajax request. This may because cache is flushed after certain period of time?? --~--~-~--~~~---~--~~ 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] Drag and Drop - Div Position
Hi All, I developing an asp.net application where i allow user to design the layout and save his settings into database. User can drag and drop objects on the page. I wonder how can i get the position of the DIV object before Drag and the new position after the drop. I hope you have some hints can help to solve my problem. Kind Regards Tamer Ibrahim --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
