Re: [jquery-dev] Re: $.ajax feature matrix
isPlainObject sounds perfect. It evokes Plain Old JavaScript Object, which
applies equally to {} and 'new Object' but not to 'new Foobar' or a String.
John, sorry I was cranky about this last night, but trust me, it matters.
Any experienced JavaScript programmer will do a double-take on
isObjectLiteral just like I did, thinking, Huh? That's impossible! What
does the function *really* do?
The performance of this function may catch people by surprise, though. It's
going to be pretty slow if the object has many properties. It would be
useful if there were a comment in the code indicating *why* it has to have
that for loop that iterates through every property of the object. There's
some commentary about the order of enumeration in that for loop, but I
didn't see anything about why the loop is needed in the first place. (And
whew - talk about undocumented browser behavior! A bit scary...)
Sorry this is a bit OT for this thread... :-)
-Mike
On Wed, Dec 2, 2009 at 6:43 PM, Julian Aubourg aubourg.jul...@gmail.comwrote:
isPlainObject?
Anyway, progress again on the transport front. Transport definition reduced
to 2 functions (the response headers are now passed to the complete callback
which is simpler and more elegant). Also, the new architecture didn't
prevent the infamous memory leak when using onreadystatechange under IE, so
I re-introduced the setInterval trick.
2009/12/3 John Resig jere...@gmail.com
Well, we don't want isObject (or isJavaScriptObject or
isNativeObject) since that'll allow things like 'new String'. We
explicitly want the case where people are using {} or new Object in
their code, adding on some properties, and passing it around. It sound
like you're worried about some sort of semantic difference between
isObjectLiteral and wasDefinedUsingAnObjectLiteral - but I don't think
that really matters.
--John
On Wed, Dec 2, 2009 at 7:36 PM, Michael Geary m...@mg.to wrote:
isObjectLiteral is a really poor name for that function. It makes no
sense
at all. An object *literal* is text. It's not an object until it's
parsed,
and then it's not an object literal any more, it's just an Object.
Case in point: jQuery.isObjectLiteral({}) and jQuery.isObjectLiteral(new
Object) both return true. I don't think there is any way to distinguish
between a '{}' and a 'new Object', is there?
This function definitely needs to be renamed. What does it actually do?
Is
its purpose to distinguish between a JavaScript object and a DOM object?
Then it could be called isJavaScriptObject or isNativeObject or some
such.
Not isObjectLiteral please.
Sorry, this is one of my pet peeves - the Google Maps API documentation
describes many of its option objects as object literals, which is
quite
misleading and confusing. (Maps newbies sometimes think they *have* to
use
an object literal and can't use an object that they build on the fly.)
-Mike
--
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: $.ajax feature matrix
I started cleaning the code and I think it's already in a good enough shape now for some code reviews/remarks/ideas, etc. All tests pass under webkit browsers, Opera Firefox (only latest versions tested). IE8 has two failing tests (3 but the third doesn't fail if the 2 previous ones aren't ran) I haven't tested in previous versions. This bug is quite fun in fact. It seems there is a problem in the deep copy algorithm when there is an object of type DispHTMLDocument (according to IE's debugger) when trying to access its fileCreatedDate field (line 268 of core.js) : we get a marvellous unspecified error. Anyway, it means putting a context option in the ajax option object makes it fail at the very first line of $.ajax. Can anybody confirm it also happens on the master under IE8? At first I thought it was because of the new options I put in ajaxSettings but, unless there's some crazy side-effect involved here, it's quite unlikely. I suppose this is related to the discussion regarding spotting real object litterals to avoid this kind of mess. Strange thing is, only IE has a problem with it and I was wondering if there was a non-standard way to spot built-in types to circumvent it? Anyway, I need to implement cross-domain tests (so that I can confirm the addition of XDomainRequest support). -- Julian 2009/12/2 John Resig jere...@gmail.com Phew - this is a beast of a patch indeed! In general though I'm liking the feel of the resulting code, a lot. This would be much more extensible, which is quite nice. I say we try to pursue this post-1.4. In the meantime you can start to apply some of the jQuery Core Style Guidelines to your code to get it ready for inclusion: http://docs.jquery.com/JQuery_Core_Style_Guidelines Naturally, making sure that all the tests pass as well is a great way to make sure that the code lands. --John On Tue, Dec 1, 2009 at 8:21 PM, Julian Aubourg aubourg.jul...@gmail.com wrote: Thanks Dave but I think I kinda figured it out! Anyway, the code has been comitted at http://github.com/jaubourg/jquery I don't have time to write everything about it down right now but you can all have a look at least. 2009/12/2 Dave Methvin dave.meth...@gmail.com OK, so I have implemented my solution: Anyway, for the time being, my branch is sitting on my harddrive. Why? Well, I've been practicing source control for years now but I have to admit I never encountered something as cryptic and unfriendly as git. So, if anyone has clear step in order to commit with this zealot, please do share before I commit suicide. I made a fork of jQuery on github btw. Julian, I'm still coming up to speed with Git on Windows myself, and stuck at trying to push my changes back to my fork on Github. I'm going to start a new thread here about 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-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@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.comjquery-dev%2bunsubscr...@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.comjquery-dev%2bunsubscr...@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: $.ajax feature matrix
I confirm that jQuery.isObjectLiteral(document.createElement(div)) returns true under IE8. 2009/12/2 Julian Aubourg aubourg.jul...@gmail.com I started cleaning the code and I think it's already in a good enough shape now for some code reviews/remarks/ideas, etc. All tests pass under webkit browsers, Opera Firefox (only latest versions tested). IE8 has two failing tests (3 but the third doesn't fail if the 2 previous ones aren't ran) I haven't tested in previous versions. This bug is quite fun in fact. It seems there is a problem in the deep copy algorithm when there is an object of type DispHTMLDocument (according to IE's debugger) when trying to access its fileCreatedDate field (line 268 of core.js) : we get a marvellous unspecified error. Anyway, it means putting a context option in the ajax option object makes it fail at the very first line of $.ajax. Can anybody confirm it also happens on the master under IE8? At first I thought it was because of the new options I put in ajaxSettings but, unless there's some crazy side-effect involved here, it's quite unlikely. I suppose this is related to the discussion regarding spotting real object litterals to avoid this kind of mess. Strange thing is, only IE has a problem with it and I was wondering if there was a non-standard way to spot built-in types to circumvent it? Anyway, I need to implement cross-domain tests (so that I can confirm the addition of XDomainRequest support). -- Julian 2009/12/2 John Resig jere...@gmail.com Phew - this is a beast of a patch indeed! In general though I'm liking the feel of the resulting code, a lot. This would be much more extensible, which is quite nice. I say we try to pursue this post-1.4. In the meantime you can start to apply some of the jQuery Core Style Guidelines to your code to get it ready for inclusion: http://docs.jquery.com/JQuery_Core_Style_Guidelines Naturally, making sure that all the tests pass as well is a great way to make sure that the code lands. --John On Tue, Dec 1, 2009 at 8:21 PM, Julian Aubourg aubourg.jul...@gmail.com wrote: Thanks Dave but I think I kinda figured it out! Anyway, the code has been comitted at http://github.com/jaubourg/jquery I don't have time to write everything about it down right now but you can all have a look at least. 2009/12/2 Dave Methvin dave.meth...@gmail.com OK, so I have implemented my solution: Anyway, for the time being, my branch is sitting on my harddrive. Why? Well, I've been practicing source control for years now but I have to admit I never encountered something as cryptic and unfriendly as git. So, if anyone has clear step in order to commit with this zealot, please do share before I commit suicide. I made a fork of jQuery on github btw. Julian, I'm still coming up to speed with Git on Windows myself, and stuck at trying to push my changes back to my fork on Github. I'm going to start a new thread here about 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-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@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.comjquery-dev%2bunsubscr...@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.comjquery-dev%2bunsubscr...@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: $.ajax feature matrix
I confirm that jQuery.isObjectLiteral(document.createElement(div)) returns true under IE8. I was actually just exploring issues with isObjectLiteral and extend as you wrote this email. I'll check in to that today and hopefully post a solution. --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.
Re: [jquery-dev] Re: $.ajax feature matrix
On Tue, Dec 1, 2009 at 8:21 PM, Julian Aubourg aubourg.jul...@gmail.com wrote:
Anyway, the code has been comitted at http://github.com/jaubourg/jquery
Just started looking at this, and it makes a great deal of sense to
me. As to the extension API, would this be simpler?:
jQuery.transport.install(script, {
factory: function() { /* ... */ },
optionsFilter: function(s) { /* ... */) //optional
});
It's a bit more explicit, at the cost, I guess of some additional
bytes per transport (although it would save some in transport.js.)
But I'm still trying to wrap my head around everything, and maybe I'm
missing something fundamental.
-- Scott
--
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: $.ajax feature matrix
No, you're actually right... I just realized I made an awful signature with
two functions in a row and I'm puzzled John didn't notice it yet... quick
quick, to refactor it :P
The main problem I have with optionsFilter and the way it works is that I
still need a main function to select the correct transport. I thought about
associating a transport to one or more dataTypes but the thing is you have
priority issues (for instance you have to specify which transport has the
priority for jsonp between the script tag hack and the xhr ones). As it is
now, there is too much logic into the filters and the way they redirect to
other transports. With the goal of making the installation of a new
transport as painless as possible, I'm thinking about some override
possibility in addition to a pure install and maybe three functions (one to
confirm the transport is the correct one to use, one to pre-treat options
and the factory). As for the priority issue, I'm thinking about it but I'm
wondering if there wouldn't be something similar in another open-source
project, no matter the field of application and/or language: what
architecture is more suited to select the correct agent given a type and how
do you handle priority so that overriding your agents is easy?
2009/12/2 Scott Sauyet scott.sau...@gmail.com
On Tue, Dec 1, 2009 at 8:21 PM, Julian Aubourg aubourg.jul...@gmail.com
wrote:
Anyway, the code has been comitted at http://github.com/jaubourg/jquery
Just started looking at this, and it makes a great deal of sense to
me. As to the extension API, would this be simpler?:
jQuery.transport.install(script, {
factory: function() { /* ... */ },
optionsFilter: function(s) { /* ... */) //optional
});
It's a bit more explicit, at the cost, I guess of some additional
bytes per transport (although it would save some in transport.js.)
But I'm still trying to wrap my head around everything, and maybe I'm
missing something fundamental.
-- Scott
--
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.comjquery-dev%2bunsubscr...@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: $.ajax feature matrix
Yep, like I said earlier jQuery.isObjectLiteral(document.createElement(div)) returns true in IE8 (dunno for earlier versions) but John seems to be working on it. Can't believe how difficult to get right these type controlling codes can be. Seems like magic to me sometimes. 2009/12/3 George Adamson george.jqu...@softwareunity.com Hi Julian, re the deep copy bug you experienced. I presume you are referring to $.extend(deep...) ? FWIW I hit this when a document object is among the options passed into a plugin that uses extend deep to merge the options with it's defaults. For some reason it worked fine when I passed window.document instead. George On Dec 2, 4:03 pm, Julian Aubourg aubourg.jul...@gmail.com wrote: I started cleaning the code and I think it's already in a good enough shape now for some code reviews/remarks/ideas, etc. All tests pass under webkit browsers, Opera Firefox (only latest versions tested). IE8 has two failing tests (3 but the third doesn't fail if the 2 previous ones aren't ran) I haven't tested in previous versions. This bug is quite fun in fact. It seems there is a problem in the deep copy algorithm when there is an object of type DispHTMLDocument (according to IE's debugger) when trying to access its fileCreatedDate field (line 268 of core.js) : we get a marvellous unspecified error. Anyway, it means putting a context option in the ajax option object makes it fail at the very first line of $.ajax. Can anybody confirm it also happens on the master under IE8? At first I thought it was because of the new options I put in ajaxSettings but, unless there's some crazy side-effect involved here, it's quite unlikely. I suppose this is related to the discussion regarding spotting real object litterals to avoid this kind of mess. Strange thing is, only IE has a problem with it and I was wondering if there was a non-standard way to spot built-in types to circumvent it? Anyway, I need to implement cross-domain tests (so that I can confirm the addition of XDomainRequest support). -- Julian 2009/12/2 John Resig jere...@gmail.com Phew - this is a beast of a patch indeed! In general though I'm liking the feel of the resulting code, a lot. This would be much more extensible, which is quite nice. I say we try to pursue this post-1.4. In the meantime you can start to apply some of the jQuery Core Style Guidelines to your code to get it ready for inclusion: http://docs.jquery.com/JQuery_Core_Style_Guidelines Naturally, making sure that all the tests pass as well is a great way to make sure that the code lands. --John On Tue, Dec 1, 2009 at 8:21 PM, Julian Aubourg aubourg.jul...@gmail.com wrote: Thanks Dave but I think I kinda figured it out! Anyway, the code has been comitted athttp:// github.com/jaubourg/jquery I don't have time to write everything about it down right now but you can all have a look at least. 2009/12/2 Dave Methvin dave.meth...@gmail.com OK, so I have implemented my solution: Anyway, for the time being, my branch is sitting on my harddrive. Why? Well, I've been practicing source control for years now but I have to admit I never encountered something as cryptic and unfriendly as git. So, if anyone has clear step in order to commit with this zealot, please do share before I commit suicide. I made a fork of jQuery on github btw. Julian, I'm still coming up to speed with Git on Windows myself, and stuck at trying to push my changes back to my fork on Github. I'm going to start a new thread here about 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-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com jquery-dev%2bunsubscr...@googlegroups.comjquery-dev%252bunsubscr...@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.comjquery-dev%2bunsubscr...@googlegroups.com jquery-dev%2bunsubscr...@googlegroups.comjquery-dev%252bunsubscr...@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
Re: [jquery-dev] Re: $.ajax feature matrix
Yep, like I said earlier jQuery.isObjectLiteral(document.createElement(div)) returns true in IE8 (dunno for earlier versions) but John seems to be working on it. Can't believe how difficult to get right these type controlling codes can be. Seems like magic to me sometimes. I actually landed the fix for it earlier today. We should be all good now. --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.
Re: [jquery-dev] Re: $.ajax feature matrix
Unfortunately this type of change will break plugins such as jquery.ui.tabs but judging by other changes you've been discussing, it seems that there will be many breaking changes. I'm doing my best so that it doesn't break anything, hence my current focus on unit testing right now. -- 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: $.ajax feature matrix
And here I ask the git newb question? How do I sync my branch with your latest changes? 2009/12/3 John Resig jere...@gmail.com Yep, like I said earlier jQuery.isObjectLiteral(document.createElement(div)) returns true in IE8 (dunno for earlier versions) but John seems to be working on it. Can't believe how difficult to get right these type controlling codes can be. Seems like magic to me sometimes. I actually landed the fix for it earlier today. We should be all good now. --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.comjquery-dev%2bunsubscr...@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: $.ajax feature matrix
Nevermind I found the way ;) So, 100% tests passing in IE8, latest safari, latest chrome, latest Opera and latest Firefox. Still searching for a decent solution to the pluggable aspect of transports. 2009/12/3 Julian Aubourg aubourg.jul...@gmail.com And here I ask the git newb question? How do I sync my branch with your latest changes? 2009/12/3 John Resig jere...@gmail.com Yep, like I said earlier jQuery.isObjectLiteral(document.createElement(div)) returns true in IE8 (dunno for earlier versions) but John seems to be working on it. Can't believe how difficult to get right these type controlling codes can be. Seems like magic to me sometimes. I actually landed the fix for it earlier today. We should be all good now. --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.comjquery-dev%2bunsubscr...@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: $.ajax feature matrix
isObjectLiteral is a really poor name for that function. It makes no sense
at all. An object *literal* is text. It's not an object until it's parsed,
and then it's not an object literal any more, it's just an Object.
Case in point: jQuery.isObjectLiteral({}) and jQuery.isObjectLiteral(new
Object) both return true. I don't think there is any way to distinguish
between a '{}' and a 'new Object', is there?
This function definitely needs to be renamed. What does it actually do? Is
its purpose to distinguish between a JavaScript object and a DOM object?
Then it could be called isJavaScriptObject or isNativeObject or some such.
Not isObjectLiteral please.
Sorry, this is one of my pet peeves - the Google Maps API documentation
describes many of its option objects as object literals, which is quite
misleading and confusing. (Maps newbies sometimes think they *have* to use
an object literal and can't use an object that they build on the fly.)
-Mike
On Wed, Dec 2, 2009 at 3:36 PM, John Resig jere...@gmail.com wrote:
Yep, like I said earlier
jQuery.isObjectLiteral(document.createElement(div)) returns true in IE8
(dunno for earlier versions) but John seems to be working on it. Can't
believe how difficult to get right these type controlling codes can be.
Seems like magic to me sometimes.
I actually landed the fix for it earlier today. We should be all good now.
--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.comjquery-dev%2bunsubscr...@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: $.ajax feature matrix
Well, we don't want isObject (or isJavaScriptObject or
isNativeObject) since that'll allow things like 'new String'. We
explicitly want the case where people are using {} or new Object in
their code, adding on some properties, and passing it around. It sound
like you're worried about some sort of semantic difference between
isObjectLiteral and wasDefinedUsingAnObjectLiteral - but I don't think
that really matters.
--John
On Wed, Dec 2, 2009 at 7:36 PM, Michael Geary m...@mg.to wrote:
isObjectLiteral is a really poor name for that function. It makes no sense
at all. An object *literal* is text. It's not an object until it's parsed,
and then it's not an object literal any more, it's just an Object.
Case in point: jQuery.isObjectLiteral({}) and jQuery.isObjectLiteral(new
Object) both return true. I don't think there is any way to distinguish
between a '{}' and a 'new Object', is there?
This function definitely needs to be renamed. What does it actually do? Is
its purpose to distinguish between a JavaScript object and a DOM object?
Then it could be called isJavaScriptObject or isNativeObject or some such.
Not isObjectLiteral please.
Sorry, this is one of my pet peeves - the Google Maps API documentation
describes many of its option objects as object literals, which is quite
misleading and confusing. (Maps newbies sometimes think they *have* to use
an object literal and can't use an object that they build on the fly.)
-Mike
On Wed, Dec 2, 2009 at 3:36 PM, John Resig jere...@gmail.com wrote:
Yep, like I said earlier
jQuery.isObjectLiteral(document.createElement(div)) returns true in
IE8
(dunno for earlier versions) but John seems to be working on it. Can't
believe how difficult to get right these type controlling codes can be.
Seems like magic to me sometimes.
I actually landed the fix for it earlier today. We should be all good now.
--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.
--
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: $.ajax feature matrix
isPlainObject?
Anyway, progress again on the transport front. Transport definition reduced
to 2 functions (the response headers are now passed to the complete callback
which is simpler and more elegant). Also, the new architecture didn't
prevent the infamous memory leak when using onreadystatechange under IE, so
I re-introduced the setInterval trick.
2009/12/3 John Resig jere...@gmail.com
Well, we don't want isObject (or isJavaScriptObject or
isNativeObject) since that'll allow things like 'new String'. We
explicitly want the case where people are using {} or new Object in
their code, adding on some properties, and passing it around. It sound
like you're worried about some sort of semantic difference between
isObjectLiteral and wasDefinedUsingAnObjectLiteral - but I don't think
that really matters.
--John
On Wed, Dec 2, 2009 at 7:36 PM, Michael Geary m...@mg.to wrote:
isObjectLiteral is a really poor name for that function. It makes no
sense
at all. An object *literal* is text. It's not an object until it's
parsed,
and then it's not an object literal any more, it's just an Object.
Case in point: jQuery.isObjectLiteral({}) and jQuery.isObjectLiteral(new
Object) both return true. I don't think there is any way to distinguish
between a '{}' and a 'new Object', is there?
This function definitely needs to be renamed. What does it actually do?
Is
its purpose to distinguish between a JavaScript object and a DOM object?
Then it could be called isJavaScriptObject or isNativeObject or some
such.
Not isObjectLiteral please.
Sorry, this is one of my pet peeves - the Google Maps API documentation
describes many of its option objects as object literals, which is quite
misleading and confusing. (Maps newbies sometimes think they *have* to
use
an object literal and can't use an object that they build on the fly.)
-Mike
On Wed, Dec 2, 2009 at 3:36 PM, John Resig jere...@gmail.com wrote:
Yep, like I said earlier
jQuery.isObjectLiteral(document.createElement(div)) returns true in
IE8
(dunno for earlier versions) but John seems to be working on it. Can't
believe how difficult to get right these type controlling codes can
be.
Seems like magic to me sometimes.
I actually landed the fix for it earlier today. We should be all good
now.
--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.comjquery-dev%2bunsubscr...@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.comjquery-dev%2bunsubscr...@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.comjquery-dev%2bunsubscr...@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: $.ajax feature matrix
Since I remembered this :
http://groups.google.com/group/jquery-dev/browse_thread/thread/5e63ab0adf17aabc?pli=1
I implemented a common poller for all xhr based requests. So, no matter how
many concurrent requests you have, there will only be *1* timer used.
See top of the file:
http://github.com/jaubourg/jquery/blob/7980f80181262ba65dc9de19d254deb0752d7269/src/transports/xhr.js
Definitively back-portable into current implementation.
2009/12/3 Julian Aubourg aubourg.jul...@gmail.com
isPlainObject?
Anyway, progress again on the transport front. Transport definition reduced
to 2 functions (the response headers are now passed to the complete callback
which is simpler and more elegant). Also, the new architecture didn't
prevent the infamous memory leak when using onreadystatechange under IE, so
I re-introduced the setInterval trick.
2009/12/3 John Resig jere...@gmail.com
Well, we don't want isObject (or isJavaScriptObject or
isNativeObject) since that'll allow things like 'new String'. We
explicitly want the case where people are using {} or new Object in
their code, adding on some properties, and passing it around. It sound
like you're worried about some sort of semantic difference between
isObjectLiteral and wasDefinedUsingAnObjectLiteral - but I don't think
that really matters.
--John
On Wed, Dec 2, 2009 at 7:36 PM, Michael Geary m...@mg.to wrote:
isObjectLiteral is a really poor name for that function. It makes no
sense
at all. An object *literal* is text. It's not an object until it's
parsed,
and then it's not an object literal any more, it's just an Object.
Case in point: jQuery.isObjectLiteral({}) and jQuery.isObjectLiteral(new
Object) both return true. I don't think there is any way to distinguish
between a '{}' and a 'new Object', is there?
This function definitely needs to be renamed. What does it actually do?
Is
its purpose to distinguish between a JavaScript object and a DOM object?
Then it could be called isJavaScriptObject or isNativeObject or some
such.
Not isObjectLiteral please.
Sorry, this is one of my pet peeves - the Google Maps API documentation
describes many of its option objects as object literals, which is
quite
misleading and confusing. (Maps newbies sometimes think they *have* to
use
an object literal and can't use an object that they build on the fly.)
-Mike
On Wed, Dec 2, 2009 at 3:36 PM, John Resig jere...@gmail.com wrote:
Yep, like I said earlier
jQuery.isObjectLiteral(document.createElement(div)) returns true in
IE8
(dunno for earlier versions) but John seems to be working on it.
Can't
believe how difficult to get right these type controlling codes can
be.
Seems like magic to me sometimes.
I actually landed the fix for it earlier today. We should be all good
now.
--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.comjquery-dev%2bunsubscr...@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.comjquery-dev%2bunsubscr...@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.comjquery-dev%2bunsubscr...@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: $.ajax feature matrix
OK, so I have implemented my solution: - all unit tests pass in safari, chrome firefox - 3 tests fail in IE but I have no clue why - all tests fail in Opera (I'm guessing I'm doing something wrong in the code early but hell if I know what). I added several tests for the jQuery.ajax(...).complete().success().error() that pass and a test demonstrating requesting xml over jsonp. Timeout abort are possible for all the transport types. I also coded a XDomainRequest transport but it's totally untested as of now. Source code has grown quite a bit but I didn't want to get into code shrinking before I had something stable in reasonable browsers. Also, I suppose it's not always jQuery-like. Also, coding a new transport is as easy as implementing 2 or 3 functions (depending if it has response headers support or not). It takes something like 5 minutes. Anyway, for the time being, my branch is sitting on my harddrive. Why? Well, I've been practicing source control for years now but I have to admit I never encountered something as cryptic and unfriendly as git. Hell if I know how to commit in this labyrinth of obtuse wording... and as you can propably read, I'm quite pissed off right now. This tool represents everything I fought against in 25 years of programming. I guess it can frie chicken for those in the know-how... once you understood mystical notions and typed a gazillion command lines. Yep, I'm under Windows Evil Vista but I had no problem using ant, updating the ant build file and the makefile. Go figure. So, if anyone has clear step in order to commit with this zealot, please do share before I commit suicide. I made a fork of jQuery on github btw. -- Julian 2009/11/19 Julian Aubourg aubourg.jul...@gmail.com Well, I was thinking about separating things into different files (ajax-something.js -- main, transport, etc) but I haven't looked into jQuery's building process and I'm *that* bad with anything that needs configuration, I'll will definitely need a hand on this. I'm all for post 1.4 actually. I think it would be wrong to push this change too early especially given 1.4 release is getting damn close and the changes we're talking about will require extensive regression testing. It can always be introduced in a 1.4.x release as soon as backward compatibility is ensured. Also, I admit I don't have as much time as I'd like to work on it right now and I'm pretty sure I'll also have to rework things before it's good for production. 2009/11/19 John Resig jere...@gmail.com Github works for me - and editing ajax.js (and test/unit/ajax.js) would be ideal - that way we could just merge it directly in. If there's any way to make your changes piece-by-piece that'd be excellent as it would make the full scope of the changes easier to understand. Also, don't feel entirely bad if this gets bumped until after 1.4 - it sounds like a lot of code might be changing and I'd rather do it right, once, then badly twice. --John On Wed, Nov 18, 2009 at 10:52 PM, Julian Aubourg aubourg.jul...@gmail.com wrote: Not yet, I'll wait to have at least one transport made (I'm working on the xhr one atm) and all the layers tested... wouldn't like to put some code with obvious mistakes that some rough testing will get rid of. I thought about unit testing early, but truth is the amount of refactoring at each iteration makes it impossible to cope with. Once I have something stable codewise and roughly tested, I'll put it on github. OK with you? btw, do you prefer I edit ajax.js or that I upload a plugin (which is the format I'm using right now)? 2009/11/19 John Resig jere...@gmail.com All of this sounds pretty good - do you have a link to the code? (Preferably in a fork up on Github - makes it easy to do a code review.) --John On Wed, Nov 18, 2009 at 10:10 PM, Julian Aubourg aubourg.jul...@gmail.com wrote: OK, just a post to keep you all updated since I didn't get as much time as I expected though I have progress, mind you. Also, I recommend a good understanding of the internals of $.ajax to follow everything. First, let me start with some design decisions I came up with: 1) the fake XHR returned by $.ajax only emulates header related methods abort The rational behind the decision is as follows: - the onreadystatechange callback was already used by jQuery internally on the old implementation, meaning that using it was pointless if not plain wrong. - same goes for open send, it doesn't make sense for external code to use them On a sidenote, readyState could be emulated but I fail to see the point. I *could* emulate onreadystatechange but is there really a use case for this? Of course, the complete(), success() error() methods are implemented. If you do something like jQuery.ajax(options).complete(completeCallback); in async=false mode, the completeCallback method WILL be called with correct arguments even though the request already completed.
Re: [jquery-dev] Re: $.ajax feature matrix
Thanks Dave but I think I kinda figured it out! Anyway, the code has been comitted at http://github.com/jaubourg/jquery I don't have time to write everything about it down right now but you can all have a look at least. 2009/12/2 Dave Methvin dave.meth...@gmail.com OK, so I have implemented my solution: Anyway, for the time being, my branch is sitting on my harddrive. Why? Well, I've been practicing source control for years now but I have to admit I never encountered something as cryptic and unfriendly as git. So, if anyone has clear step in order to commit with this zealot, please do share before I commit suicide. I made a fork of jQuery on github btw. Julian, I'm still coming up to speed with Git on Windows myself, and stuck at trying to push my changes back to my fork on Github. I'm going to start a new thread here about 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-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@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: $.ajax feature matrix
Phew - this is a beast of a patch indeed! In general though I'm liking the feel of the resulting code, a lot. This would be much more extensible, which is quite nice. I say we try to pursue this post-1.4. In the meantime you can start to apply some of the jQuery Core Style Guidelines to your code to get it ready for inclusion: http://docs.jquery.com/JQuery_Core_Style_Guidelines Naturally, making sure that all the tests pass as well is a great way to make sure that the code lands. --John On Tue, Dec 1, 2009 at 8:21 PM, Julian Aubourg aubourg.jul...@gmail.com wrote: Thanks Dave but I think I kinda figured it out! Anyway, the code has been comitted at http://github.com/jaubourg/jquery I don't have time to write everything about it down right now but you can all have a look at least. 2009/12/2 Dave Methvin dave.meth...@gmail.com OK, so I have implemented my solution: Anyway, for the time being, my branch is sitting on my harddrive. Why? Well, I've been practicing source control for years now but I have to admit I never encountered something as cryptic and unfriendly as git. So, if anyone has clear step in order to commit with this zealot, please do share before I commit suicide. I made a fork of jQuery on github btw. Julian, I'm still coming up to speed with Git on Windows myself, and stuck at trying to push my changes back to my fork on Github. I'm going to start a new thread here about 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-...@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: $.ajax feature matrix
OK, just a post to keep you all updated since I didn't get as much time as I
expected though I have progress, mind you.
Also, I recommend a good understanding of the internals of $.ajax to follow
everything.
First, let me start with some design decisions I came up with:
1) the fake XHR returned by $.ajax only emulates header related methods
abort
The rational behind the decision is as follows:
- the onreadystatechange callback was already used by jQuery internally on
the old implementation, meaning that using it was pointless if not plain
wrong.
- same goes for open send, it doesn't make sense for external code to use
them
On a sidenote, readyState could be emulated but I fail to see the point. I
*could* emulate onreadystatechange but is there really a use case for this?
Of course, the complete(), success() error() methods are implemented. If
you do something like jQuery.ajax(options).complete(completeCallback); in
async=false mode, the completeCallback method WILL be called with correct
arguments even though the request already completed.
Each callback family handled return false; in callbacks, meaning no
further callbacks of that family will be called later on.
For backward compatibility, the complete, success error callbacks provided
in the options object are also called (they are actually added to the list
of callbacks before issuing the request).
2) I added the notion of transport which is the actual implementation that
will send the request
ajaxSettings has two new properties:
- transportSelector, a function that will take an options object and
determine what transport type is more suited for the request,
- transportDefinitions which is a hashmap of transport definitions
(obviously).
Transport definitions contains two functions:
- filter which takes the options object returns a new transport type if it
deems it more suited than itself
- factory which takes no argument returns a new transport of the desired
type
The idea in having the filter function is:
- to set s.global as false if the transport cannot ensure completion
(cross-domain script / jsonp),
- to keep differentiating code as close to the implementation as possible. A
good example are scripts which wont be handled the same if they are cross
domain or not (first will use xhr, second will use a script tag). If
s.transportDefinitions[transportType] is not an object but a function, it is
considered a filter. Following previous example, transportSelector would
just return script no matter what, and the script transport definition
would look like this:
s.transportDefinitions[script] = function (s) { return isCrossDomain(s) ?
script-tag : xhr }
Filters get called until a final transportType is found, then the
corresponding transport factory gets called.
By changing transportSelector transportDefinitions, a user can completely
I also added some options into the ajax options object beside
transportSelector transportDefinition:
- transport: which can be used to bypass transportSelector (filters called
until final type is found are not bypassed)
- transportDataType: it's the data type used to determine which transport to
use (in transportSelector), if not provided it's equivalent to dataType. The
idea came when I was refactoring and realized that it was no reason why you
couldn't ask for xml through jsonp. So you would have something like
$.ajax({ dataType: xml, transportDataType: jsonp, ...}) and the request
will be made through jsonp and the resulting json object will be parsed as
xml (I already implemented the logic). As a consequence dataFilter gets 3
arguments:
- the data,
- s.dataType,
- a function that permits to get/set the transportDataType (so that you can
make casts in your dataFilter).
- crossDomain: a boolean computed into the main $.ajax method to make life
of filters easier.
So far, I have:
- the logic in $.ajax (with xhr emulation callbacks system),
- the factory system,
- a helper function to help create transports (in the end only 3 functions +
the filter will have to be provided to create a new transport),
- the interface for a transport (which is much easier to deal with than an
xhr).
I have yet to implement actual transports and start testing.
Also, generalizing the implementaton, global events, timeout, ifModified,
etc, are handled for all transports (now, given lack of headers, ifModified
may not have an effect with most transports but still).
The code hasn't exploded in size but I cannot estimate yet how bigger it
will get.
Now onto stuff I'd like to see in jQuery and am very tempted to add in the
process is ful-fledged support for CORS with the definition of
jQuery.support.crossDomainRequest (values false, standard or
XDomainRequest -- detection code can be found here:
http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/ --).
Using filters and the new s.crossDomain computed option, it should be very
easy to handle all situations (by throwing an exception or whatnot so that
client
Re: [jquery-dev] Re: $.ajax feature matrix
All of this sounds pretty good - do you have a link to the code? (Preferably
in a fork up on Github - makes it easy to do a code review.)
--John
On Wed, Nov 18, 2009 at 10:10 PM, Julian Aubourg
aubourg.jul...@gmail.comwrote:
OK, just a post to keep you all updated since I didn't get as much time as
I expected though I have progress, mind you.
Also, I recommend a good understanding of the internals of $.ajax to follow
everything.
First, let me start with some design decisions I came up with:
1) the fake XHR returned by $.ajax only emulates header related methods
abort
The rational behind the decision is as follows:
- the onreadystatechange callback was already used by jQuery internally on
the old implementation, meaning that using it was pointless if not plain
wrong.
- same goes for open send, it doesn't make sense for external code to use
them
On a sidenote, readyState could be emulated but I fail to see the point. I
*could* emulate onreadystatechange but is there really a use case for this?
Of course, the complete(), success() error() methods are implemented. If
you do something like jQuery.ajax(options).complete(completeCallback); in
async=false mode, the completeCallback method WILL be called with correct
arguments even though the request already completed.
Each callback family handled return false; in callbacks, meaning no
further callbacks of that family will be called later on.
For backward compatibility, the complete, success error callbacks
provided in the options object are also called (they are actually added to
the list of callbacks before issuing the request).
2) I added the notion of transport which is the actual implementation
that will send the request
ajaxSettings has two new properties:
- transportSelector, a function that will take an options object and
determine what transport type is more suited for the request,
- transportDefinitions which is a hashmap of transport definitions
(obviously).
Transport definitions contains two functions:
- filter which takes the options object returns a new transport type if
it deems it more suited than itself
- factory which takes no argument returns a new transport of the desired
type
The idea in having the filter function is:
- to set s.global as false if the transport cannot ensure completion
(cross-domain script / jsonp),
- to keep differentiating code as close to the implementation as possible.
A good example are scripts which wont be handled the same if they are cross
domain or not (first will use xhr, second will use a script tag). If
s.transportDefinitions[transportType] is not an object but a function, it is
considered a filter. Following previous example, transportSelector would
just return script no matter what, and the script transport definition
would look like this:
s.transportDefinitions[script] = function (s) { return isCrossDomain(s) ?
script-tag : xhr }
Filters get called until a final transportType is found, then the
corresponding transport factory gets called.
By changing transportSelector transportDefinitions, a user can completely
I also added some options into the ajax options object beside
transportSelector transportDefinition:
- transport: which can be used to bypass transportSelector (filters called
until final type is found are not bypassed)
- transportDataType: it's the data type used to determine which transport
to use (in transportSelector), if not provided it's equivalent to dataType.
The idea came when I was refactoring and realized that it was no reason why
you couldn't ask for xml through jsonp. So you would have something like
$.ajax({ dataType: xml, transportDataType: jsonp, ...}) and the request
will be made through jsonp and the resulting json object will be parsed as
xml (I already implemented the logic). As a consequence dataFilter gets 3
arguments:
- the data,
- s.dataType,
- a function that permits to get/set the transportDataType (so that you can
make casts in your dataFilter).
- crossDomain: a boolean computed into the main $.ajax method to make life
of filters easier.
So far, I have:
- the logic in $.ajax (with xhr emulation callbacks system),
- the factory system,
- a helper function to help create transports (in the end only 3 functions
+ the filter will have to be provided to create a new transport),
- the interface for a transport (which is much easier to deal with than an
xhr).
I have yet to implement actual transports and start testing.
Also, generalizing the implementaton, global events, timeout, ifModified,
etc, are handled for all transports (now, given lack of headers, ifModified
may not have an effect with most transports but still).
The code hasn't exploded in size but I cannot estimate yet how bigger it
will get.
Now onto stuff I'd like to see in jQuery and am very tempted to add in the
process is ful-fledged support for CORS with the definition of
Re: [jquery-dev] Re: $.ajax feature matrix
Not yet, I'll wait to have at least one transport made (I'm working on the
xhr one atm) and all the layers tested... wouldn't like to put some code
with obvious mistakes that some rough testing will get rid of. I thought
about unit testing early, but truth is the amount of refactoring at each
iteration makes it impossible to cope with. Once I have something stable
codewise and roughly tested, I'll put it on github. OK with you?
btw, do you prefer I edit ajax.js or that I upload a plugin (which is the
format I'm using right now)?
2009/11/19 John Resig jere...@gmail.com
All of this sounds pretty good - do you have a link to the code?
(Preferably in a fork up on Github - makes it easy to do a code review.)
--John
On Wed, Nov 18, 2009 at 10:10 PM, Julian Aubourg aubourg.jul...@gmail.com
wrote:
OK, just a post to keep you all updated since I didn't get as much time as
I expected though I have progress, mind you.
Also, I recommend a good understanding of the internals of $.ajax to
follow everything.
First, let me start with some design decisions I came up with:
1) the fake XHR returned by $.ajax only emulates header related methods
abort
The rational behind the decision is as follows:
- the onreadystatechange callback was already used by jQuery internally on
the old implementation, meaning that using it was pointless if not plain
wrong.
- same goes for open send, it doesn't make sense for external code to
use them
On a sidenote, readyState could be emulated but I fail to see the point. I
*could* emulate onreadystatechange but is there really a use case for this?
Of course, the complete(), success() error() methods are implemented. If
you do something like jQuery.ajax(options).complete(completeCallback); in
async=false mode, the completeCallback method WILL be called with correct
arguments even though the request already completed.
Each callback family handled return false; in callbacks, meaning no
further callbacks of that family will be called later on.
For backward compatibility, the complete, success error callbacks
provided in the options object are also called (they are actually added to
the list of callbacks before issuing the request).
2) I added the notion of transport which is the actual implementation
that will send the request
ajaxSettings has two new properties:
- transportSelector, a function that will take an options object and
determine what transport type is more suited for the request,
- transportDefinitions which is a hashmap of transport definitions
(obviously).
Transport definitions contains two functions:
- filter which takes the options object returns a new transport type if
it deems it more suited than itself
- factory which takes no argument returns a new transport of the desired
type
The idea in having the filter function is:
- to set s.global as false if the transport cannot ensure completion
(cross-domain script / jsonp),
- to keep differentiating code as close to the implementation as possible.
A good example are scripts which wont be handled the same if they are cross
domain or not (first will use xhr, second will use a script tag). If
s.transportDefinitions[transportType] is not an object but a function, it is
considered a filter. Following previous example, transportSelector would
just return script no matter what, and the script transport definition
would look like this:
s.transportDefinitions[script] = function (s) { return isCrossDomain(s)
? script-tag : xhr }
Filters get called until a final transportType is found, then the
corresponding transport factory gets called.
By changing transportSelector transportDefinitions, a user can
completely
I also added some options into the ajax options object beside
transportSelector transportDefinition:
- transport: which can be used to bypass transportSelector (filters called
until final type is found are not bypassed)
- transportDataType: it's the data type used to determine which transport
to use (in transportSelector), if not provided it's equivalent to dataType.
The idea came when I was refactoring and realized that it was no reason why
you couldn't ask for xml through jsonp. So you would have something like
$.ajax({ dataType: xml, transportDataType: jsonp, ...}) and the request
will be made through jsonp and the resulting json object will be parsed as
xml (I already implemented the logic). As a consequence dataFilter gets 3
arguments:
- the data,
- s.dataType,
- a function that permits to get/set the transportDataType (so that you
can make casts in your dataFilter).
- crossDomain: a boolean computed into the main $.ajax method to make life
of filters easier.
So far, I have:
- the logic in $.ajax (with xhr emulation callbacks system),
- the factory system,
- a helper function to help create transports (in the end only 3 functions
+ the filter will have to be provided to create a new transport),
- the interface for a
Re: [jquery-dev] Re: $.ajax feature matrix
Github works for me - and editing ajax.js (and test/unit/ajax.js) would be
ideal - that way we could just merge it directly in.
If there's any way to make your changes piece-by-piece that'd be excellent
as it would make the full scope of the changes easier to understand.
Also, don't feel entirely bad if this gets bumped until after 1.4 - it
sounds like a lot of code might be changing and I'd rather do it right,
once, then badly twice.
--John
On Wed, Nov 18, 2009 at 10:52 PM, Julian Aubourg
aubourg.jul...@gmail.comwrote:
Not yet, I'll wait to have at least one transport made (I'm working on the
xhr one atm) and all the layers tested... wouldn't like to put some code
with obvious mistakes that some rough testing will get rid of. I thought
about unit testing early, but truth is the amount of refactoring at each
iteration makes it impossible to cope with. Once I have something stable
codewise and roughly tested, I'll put it on github. OK with you?
btw, do you prefer I edit ajax.js or that I upload a plugin (which is the
format I'm using right now)?
2009/11/19 John Resig jere...@gmail.com
All of this sounds pretty good - do you have a link to the code?
(Preferably in a fork up on Github - makes it easy to do a code review.)
--John
On Wed, Nov 18, 2009 at 10:10 PM, Julian Aubourg
aubourg.jul...@gmail.com wrote:
OK, just a post to keep you all updated since I didn't get as much time
as I expected though I have progress, mind you.
Also, I recommend a good understanding of the internals of $.ajax to
follow everything.
First, let me start with some design decisions I came up with:
1) the fake XHR returned by $.ajax only emulates header related methods
abort
The rational behind the decision is as follows:
- the onreadystatechange callback was already used by jQuery internally
on the old implementation, meaning that using it was pointless if not plain
wrong.
- same goes for open send, it doesn't make sense for external code to
use them
On a sidenote, readyState could be emulated but I fail to see the point.
I *could* emulate onreadystatechange but is there really a use case for
this?
Of course, the complete(), success() error() methods are implemented.
If you do something like jQuery.ajax(options).complete(completeCallback); in
async=false mode, the completeCallback method WILL be called with correct
arguments even though the request already completed.
Each callback family handled return false; in callbacks, meaning no
further callbacks of that family will be called later on.
For backward compatibility, the complete, success error callbacks
provided in the options object are also called (they are actually added to
the list of callbacks before issuing the request).
2) I added the notion of transport which is the actual implementation
that will send the request
ajaxSettings has two new properties:
- transportSelector, a function that will take an options object and
determine what transport type is more suited for the request,
- transportDefinitions which is a hashmap of transport definitions
(obviously).
Transport definitions contains two functions:
- filter which takes the options object returns a new transport type if
it deems it more suited than itself
- factory which takes no argument returns a new transport of the
desired type
The idea in having the filter function is:
- to set s.global as false if the transport cannot ensure completion
(cross-domain script / jsonp),
- to keep differentiating code as close to the implementation as
possible. A good example are scripts which wont be handled the same if they
are cross domain or not (first will use xhr, second will use a script tag).
If s.transportDefinitions[transportType] is not an object but a function, it
is considered a filter. Following previous example, transportSelector would
just return script no matter what, and the script transport definition
would look like this:
s.transportDefinitions[script] = function (s) { return isCrossDomain(s)
? script-tag : xhr }
Filters get called until a final transportType is found, then the
corresponding transport factory gets called.
By changing transportSelector transportDefinitions, a user can
completely
I also added some options into the ajax options object beside
transportSelector transportDefinition:
- transport: which can be used to bypass transportSelector (filters
called until final type is found are not bypassed)
- transportDataType: it's the data type used to determine which transport
to use (in transportSelector), if not provided it's equivalent to dataType.
The idea came when I was refactoring and realized that it was no reason why
you couldn't ask for xml through jsonp. So you would have something like
$.ajax({ dataType: xml, transportDataType: jsonp, ...}) and the request
will be made through jsonp and the resulting json object will be parsed as
xml (I already implemented the logic). As a
Re: [jquery-dev] Re: $.ajax feature matrix
Well, I was thinking about separating things into different files
(ajax-something.js -- main, transport, etc) but I haven't looked into
jQuery's building process and I'm *that* bad with anything that needs
configuration, I'll will definitely need a hand on this.
I'm all for post 1.4 actually. I think it would be wrong to push this change
too early especially given 1.4 release is getting damn close and the changes
we're talking about will require extensive regression testing. It can always
be introduced in a 1.4.x release as soon as backward compatibility is
ensured.
Also, I admit I don't have as much time as I'd like to work on it right now
and I'm pretty sure I'll also have to rework things before it's good for
production.
2009/11/19 John Resig jere...@gmail.com
Github works for me - and editing ajax.js (and test/unit/ajax.js) would be
ideal - that way we could just merge it directly in.
If there's any way to make your changes piece-by-piece that'd be excellent
as it would make the full scope of the changes easier to understand.
Also, don't feel entirely bad if this gets bumped until after 1.4 - it
sounds like a lot of code might be changing and I'd rather do it right,
once, then badly twice.
--John
On Wed, Nov 18, 2009 at 10:52 PM, Julian Aubourg aubourg.jul...@gmail.com
wrote:
Not yet, I'll wait to have at least one transport made (I'm working on the
xhr one atm) and all the layers tested... wouldn't like to put some code
with obvious mistakes that some rough testing will get rid of. I thought
about unit testing early, but truth is the amount of refactoring at each
iteration makes it impossible to cope with. Once I have something stable
codewise and roughly tested, I'll put it on github. OK with you?
btw, do you prefer I edit ajax.js or that I upload a plugin (which is the
format I'm using right now)?
2009/11/19 John Resig jere...@gmail.com
All of this sounds pretty good - do you have a link to the code?
(Preferably in a fork up on Github - makes it easy to do a code review.)
--John
On Wed, Nov 18, 2009 at 10:10 PM, Julian Aubourg
aubourg.jul...@gmail.com wrote:
OK, just a post to keep you all updated since I didn't get as much time
as I expected though I have progress, mind you.
Also, I recommend a good understanding of the internals of $.ajax to
follow everything.
First, let me start with some design decisions I came up with:
1) the fake XHR returned by $.ajax only emulates header related methods
abort
The rational behind the decision is as follows:
- the onreadystatechange callback was already used by jQuery internally
on the old implementation, meaning that using it was pointless if not plain
wrong.
- same goes for open send, it doesn't make sense for external code to
use them
On a sidenote, readyState could be emulated but I fail to see the point.
I *could* emulate onreadystatechange but is there really a use case for
this?
Of course, the complete(), success() error() methods are implemented.
If you do something like jQuery.ajax(options).complete(completeCallback);
in
async=false mode, the completeCallback method WILL be called with correct
arguments even though the request already completed.
Each callback family handled return false; in callbacks, meaning no
further callbacks of that family will be called later on.
For backward compatibility, the complete, success error callbacks
provided in the options object are also called (they are actually added to
the list of callbacks before issuing the request).
2) I added the notion of transport which is the actual implementation
that will send the request
ajaxSettings has two new properties:
- transportSelector, a function that will take an options object and
determine what transport type is more suited for the request,
- transportDefinitions which is a hashmap of transport definitions
(obviously).
Transport definitions contains two functions:
- filter which takes the options object returns a new transport type
if it deems it more suited than itself
- factory which takes no argument returns a new transport of the
desired type
The idea in having the filter function is:
- to set s.global as false if the transport cannot ensure completion
(cross-domain script / jsonp),
- to keep differentiating code as close to the implementation as
possible. A good example are scripts which wont be handled the same if they
are cross domain or not (first will use xhr, second will use a script tag).
If s.transportDefinitions[transportType] is not an object but a function,
it
is considered a filter. Following previous example, transportSelector would
just return script no matter what, and the script transport definition
would look like this:
s.transportDefinitions[script] = function (s) { return
isCrossDomain(s) ? script-tag : xhr }
Filters get called until a final transportType is found, then the
corresponding transport factory gets called.
By changing
Re: [jquery-dev] Re: $.ajax feature matrix
On Thu, Nov 12, 2009 at 1:15 PM, John Resig jere...@gmail.com wrote: I think the one area that would be troublesome is in the properties that xhr provides (like readyState, responseXML, etc.). I'm not sure how you'd build this mock XHR and keep those properties up to date. On Thu, Nov 12, 2009 at 10:14 PM, Julian Aubourg aubourg.jul...@gmail.com wrote: As an example of what I'm talking about with an real xhr as a base: - layer 0 is window.ActiveXObject ? new ActiveXObject(Microsoft.XMLHTTP) : new XMLHttpRequest() - layer 1 is a standard compliant xhr implementation that delegates to layer 0 while hiding browser incompatibilities. It listens to layer 0 through its onreadystatechange event handler and propagates the event by calling its own onreadystatechange if available I had briefly mentioned a similar idea in the other thread [1], but was rather scared of the actual implementation. I guess the question is whether there are possible state changes to the underlying XHR object that might affect the properties but that are not exposed through the onreadystatechange handler. I don't have nearly the knowledge of XHR to answer this. If there aren't any, I think this is quite a good idea. -- Scott [1] http://tinyurl.com/yl2lqjz#msg_1fa4cac00dbcedcf -- 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=.
Re: [jquery-dev] Re: $.ajax feature matrix
Well, the idea is to enable Jason Persampieri's idea of a chaining ajax system (ie $.ajax(options).success(...).error(...) ) while not having race conditions (so the bind method will be smarter than your usual one) and while maintaining compatibility with xhr. So basically, all ajax request systems hacks (real ajax, jsonp, script, etc) will be wrapped into an xhr-like object (that is an object you'll be able to use as an xhr) plus jQuery-only methods (allowing deferred callback binding and the use of several complete, error success callbacks for the same request). I've just began working on the pure xhr wrapper and I can already see how all the hacks to circumvent xhr incompatibilities between browsers have been scattered all around $.ajax and its submethods. Using a wrapper, I can already put them all in one place (ie: the xhr wrapper ensures a not modified response always has 304 as a status, onreadystatechange will always be called even in async mode on firefox 1.5, won't throw exceptions when headers are not available, etc, etc, there are too many little glitches to list here but you get the idea). I'm moving code around as we speak and I've set it all up as a plugin external to jQuery core for now to be safe. The idea is to keep the source as close to the current one as possible to avoid silly regressions (you know, when you see some code, tell yourself you can do better but fail to realize there are bug fixes in there). As far as I can tell, it's already quite promising from a maintenance point of view. I think I'm gonna built the wrapping system in three layers (bottom to top): - layer 0 is the implementation (xhr for ajax, script tag hack for script jsonp) - layer 1 is a standard-compliant xhr wrapper - layer 2 is an augmented xhr with callback handling The difference between layer 2 1 makes for a better and more readable separation of concern. So basically, you get the layer 1 wrapper from a factory given the dataType then wrap it into the callback aware one. Everything is classes (functions + prototype) and I'm making sure there are as few dynamically created methods/functions as possible. Anyway, in the end, you have *1* layer 2 class which can accept any of the layer 1 classes (one layer 1 class per remote request system -- ajax, jsonp, etc...). As an example of what I'm talking about with an real xhr as a base: - layer 0 is window.ActiveXObject ? new ActiveXObject(Microsoft.XMLHTTP) : new XMLHttpRequest() - layer 1 is a standard compliant xhr implementation that delegates to layer 0 while hiding browser incompatibilities. It listens to layer 0 through its onreadystatechange event handler and propagates the event by calling its own onreadystatechange if available - layer 2 is a standard compliant xhr that listens to layer 1, provides methods to bind notify events and actually does notify events, of course. Dunno if I make myself clear... but it's like 4 am passed in here ;) Anyway, I just moved from Paris to Brussels (I had intermitent internet the last few days) and I have guests this week-end (heh! social life!) so I'll try to have something concrete to show for the middle of next week. 2009/11/13 Dave Methvin dave.meth...@gmail.com Julian, could you show a few sample usages of the new design you had in 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.comjquery-dev%2bunsubscr...@googlegroups.com . For more options, visit this group at http://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=.
