[jquery-dev] Re: about iterators, closures and scope
The requirement of "new" to create new js objects is an unnecessary
piece of the language, in fact the need to use it disappears in ES5 as
it's no longer the only way to create new objects with a set prototype.
There's nothing strange about having a $ function and creating an object
from it, in fact it's closer to real prototype-based programming than
the `new Class` you see inside of JavaScript.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Tarini 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 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: hide() with 0ms with not call callback
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] hide() with 0ms with not call callback
If you call hide() on an element with a 0ms animation time the callback will not be called. Now, I know this doesn't make sense in application as a $e.hide(0, callback) would imply a synchronous action, but it was inconvenient that I was just debugging hide/show timers and noticed that a 0-ms animation time yields a hide() without the callback. Here is an example: http://pastebin.com/m3cb285b2 --~--~-~--~~~---~--~~ 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
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 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: RFC on Bug 4834: Don't set window.$ until the outro
That's a good point, actually. I know for a while jQuery was included one file at a time (without the intro/outro). Although, uses of jQuery(foo) will still work since var jQuery = ... still exists in core.js. Perhaps var $ = jQuery; could be added, as well. It wouldn't have a use in the normal jQuery but would benefit those that include jQuery file-by-file. Of course, if someone is doing that then they're also severely polluting the global namespace. It seems like the minimum build of jQuery is intro + core + outro, then. I'll try and think of a good way to document it. --John On Mon, Aug 10, 2009 at 5:31 PM, Paul Bakaus wrote: > I would be careful about this change, and at the very least document it > somewhere - a few people pack jQuery themselves in custom build scripts, and > since the intro/outro files never did something significant before, they > might have been ignored. On the other hand of course, we never officially > supported such a use of the library :) > > On Mon, Aug 10, 2009 at 11:23 PM, John Resig wrote: > >> I agree that this is an exceedingly rare situation in which this occurs >> (e.g. it only seems to occur with a 2 year old version of Prototype - the >> problem has been fixed in Prorotype 1.6+). >> >> Although, the change seems pretty painless, so I've just landed it: >> http://dev.jquery.com/changeset/6529 >> >> --John >> >> >> >> On Sat, Aug 8, 2009 at 5:27 PM, Aaron Pfeifer wrote: >> >>> >>> Hey all, >>> >>> I was wondering if anyone had any feedback, comments, or concerns >>> about the fix proposed in Bug 4834 http://dev.jquery.com/ticket/4834). >>> This bug describes a situation where jQuery introduces global >>> variables resulting in possible conflicts with other javascript >>> libraries on the page. The proposed solution is to defer the >>> assignment of global variables until the end of the jQuery library >>> definition. >>> >>> Thanks! >>> >>> >>> >> >> >> > > > -- > Paul Bakaus > UI Architect @ smart.fm > -- > http://paulbakaus.com > http://www.linkedin.com/in/paulbakaus > > > > > --~--~-~--~~~---~--~~ 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: RFC on Bug 4834: Don't set window.$ until the outro
I would be careful about this change, and at the very least document it somewhere - a few people pack jQuery themselves in custom build scripts, and since the intro/outro files never did something significant before, they might have been ignored. On the other hand of course, we never officially supported such a use of the library :) On Mon, Aug 10, 2009 at 11:23 PM, John Resig wrote: > I agree that this is an exceedingly rare situation in which this occurs > (e.g. it only seems to occur with a 2 year old version of Prototype - the > problem has been fixed in Prorotype 1.6+). > > Although, the change seems pretty painless, so I've just landed it: > http://dev.jquery.com/changeset/6529 > > --John > > > > On Sat, Aug 8, 2009 at 5:27 PM, Aaron Pfeifer wrote: > >> >> Hey all, >> >> I was wondering if anyone had any feedback, comments, or concerns >> about the fix proposed in Bug 4834 http://dev.jquery.com/ticket/4834). >> This bug describes a situation where jQuery introduces global >> variables resulting in possible conflicts with other javascript >> libraries on the page. The proposed solution is to defer the >> assignment of global variables until the end of the jQuery library >> definition. >> >> Thanks! >> >> >> > > > > -- Paul Bakaus UI Architect @ smart.fm -- http://paulbakaus.com http://www.linkedin.com/in/paulbakaus --~--~-~--~~~---~--~~ 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: RFC on Bug 4834: Don't set window.$ until the outro
I agree that this is an exceedingly rare situation in which this occurs (e.g. it only seems to occur with a 2 year old version of Prototype - the problem has been fixed in Prorotype 1.6+). Although, the change seems pretty painless, so I've just landed it: http://dev.jquery.com/changeset/6529 --John On Sat, Aug 8, 2009 at 5:27 PM, Aaron Pfeifer wrote: > > Hey all, > > I was wondering if anyone had any feedback, comments, or concerns > about the fix proposed in Bug 4834 http://dev.jquery.com/ticket/4834). > This bug describes a situation where jQuery introduces global > variables resulting in possible conflicts with other javascript > libraries on the page. The proposed solution is to defer the > assignment of global variables until the end of the jQuery library > definition. > > Thanks! > > > > --~--~-~--~~~---~--~~ 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: Changes to closest (#6507) breaks $(event.target).closest(...) in event handlers
The download page of the jQuery site instructs you on how to make your own builds: http://docs.jquery.com/Downloading_jQuery#Subversion_.28SVN.29 --John On Mon, Aug 10, 2009 at 3:38 PM, mike.helgeson wrote: > > (again) > > > Could someone please update the nightly? > > http://code.jquery.com/jquery-nightly.js > > It still contains this closest issue (rev. 6507). > > Is there some other place I should look? A resource that will instruct > me to make my own builds? > > > --~--~-~--~~~---~--~~ 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: Changes to closest (#6507) breaks $(event.target).closest(...) in event handlers
(again) > Could someone please update the nightly? > http://code.jquery.com/jquery-nightly.js > It still contains this closest issue (rev. 6507). Is there some other place I should look? A resource that will instruct me to make my own builds? --~--~-~--~~~---~--~~ 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.
Thanks for not posting this to the bug tracker! A test case is helpful
even in the forums though.
> FireBug is reporting this error.
> jquery.js (line 3633)
> object is undefined
> [Break on this error] var name, i = 0, length = object.length;\n
> I am using jQuery 1.3.2
That looks like the first line of jQuery.each, although the line
number you gave doesn't seem to match. It's line 672 of my
uncompressed jQuery 1.3.2 right off the site. I think it makes sense
for that line to be the one where it dies. Because...
> for(var i = 0; ivar verbTime = Math.floor(Math.random()*1000);
>jQuery("#verb-content").fadeOut(verbTime, function(){
> jQuery(that).text(verbArray[i]).fadeIn(verbTime);
>});
> }
Each time through the loop you're queueing up a fadeOut animation.
Each animation has a *callback* that uses the variable i from the
closure. By the time any of those callbacks execute sometime in the
future, the loop has long since finished; at that point
i==verbArray.length and verbArray[i] is undefined for every one of
them.
As a result, if DBJDBJ is right and "that" is actually the window
object, then inside .text() it's trying to call jQuery.each
(window.childNodes, ...) which would give the error you saw
because...well, because window.childNodes is undefined! You should be
able to see the call stack in Firebug to verify that's what is
happening.
If you converted your for loops to jQuery.each loops, you should be
able to get the closure you need to make this work properly.
--~--~-~--~~~---~--~~
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?
thanks; this is helpful.
On Aug 10, 3:52 am, DBJDBJ wrote:
> var $xml = $(" x:name='n1'>No namespaces");
>
> $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] Re: jQuery.domManip - script tag will be removed
I think the second way you named is much better 1. By removing this script tag - you are changing html, the user has inserted, without to ask him :) 2. Standard dom implementation of innerHTML doesn't removes script tags, in spite of it ignores them ( It looks like a bug, because according to w3c is script tag inside of body is allowed, so I whould expect that the browser will execute it) 3. You are removing the point of isertion if the user want to insert something after this tag P.S. thanks for a such fast answer :) On Aug 10, 3:12 pm, John Resig wrote: > When a script node is inserted into the document it is also executed (by > jQuery). To avoid re-executing it later (this happens a lot, as it turns > out) the script is simply removed from the document. > > Naturally, this causes some issues when you actually want to see the > contents of the script element (as you do). However I think the trade-off is > better in this case. > > The one alternative solution that I can think of is to use the internal > .data() API to attach information to the script element, informing it that > shouldn't be executed again at a later time. I'm not sure how unexpected > that is, though. > > --John > > On Mon, Aug 10, 2009 at 5:45 AM, Kof wrote: > > > Does anybody know why jQuery removes script tags added to body ? > > > The problem is if you want to insert dom elements after the own script > > tag you can't select the script node any more, because it was removed > > by jquery. > > > It is important by widgets because if I insert dynamically a script > > tag and the widget is using document.write - the whole document will > > be overwritten. > > > So I want to insert widget html code after original script tag by > > using insertAfter instead of document.write. > > > Of course I could also isert any div and then access it to insert the > > widget code, it is just not so pretty. > > > I think jquerys domManip method shouldn't remove original script tag, > > or it should be possible to add parameter to avoid this. --~--~-~--~~~---~--~~ 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: jQuery.domManip - script tag will be removed
When a script node is inserted into the document it is also executed (by jQuery). To avoid re-executing it later (this happens a lot, as it turns out) the script is simply removed from the document. Naturally, this causes some issues when you actually want to see the contents of the script element (as you do). However I think the trade-off is better in this case. The one alternative solution that I can think of is to use the internal .data() API to attach information to the script element, informing it that shouldn't be executed again at a later time. I'm not sure how unexpected that is, though. --John On Mon, Aug 10, 2009 at 5:45 AM, Kof wrote: > > Does anybody know why jQuery removes script tags added to body ? > > The problem is if you want to insert dom elements after the own script > tag you can't select the script node any more, because it was removed > by jquery. > > It is important by widgets because if I insert dynamically a script > tag and the widget is using document.write - the whole document will > be overwritten. > > So I want to insert widget html code after original script tag by > using insertAfter instead of document.write. > > Of course I could also isert any div and then access it to insert the > widget code, it is just not so pretty. > > I think jquerys domManip method shouldn't remove original script tag, > or it should be possible to add parameter to avoid this. > > > > --~--~-~--~~~---~--~~ 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] jQuery.domManip - script tag will be removed
Does anybody know why jQuery removes script tags added to body ? The problem is if you want to insert dom elements after the own script tag you can't select the script node any more, because it was removed by jquery. It is important by widgets because if I insert dynamically a script tag and the widget is using document.write - the whole document will be overwritten. So I want to insert widget html code after original script tag by using insertAfter instead of document.write. Of course I could also isert any div and then access it to insert the widget code, it is just not so pretty. I think jquerys domManip method shouldn't remove original script tag, or it should be possible to add parameter to avoid this. --~--~-~--~~~---~--~~ 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?
var $xml = $("No namespaces");
$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/48ef43723989de57
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
