> 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?"
Just happened to me last night. :-) I was wondering how it was able to
tell {} from new Object.
--
You received this messa
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
isObject
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/j
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 onreadystatechan
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
"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
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
> And here I ask the git newb question? How do I sync my branch with
And here I ask the git newb question? How do I sync my branch with your
latest changes?
2009/12/3 John Resig
> > 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
> > b
> 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
Great thread, well done guys. I've been following this with interest
and wondered...
As part of the re-write, please could we improve the continuity of the
callback arguments?
It can be hard to remember what each callback receives.
At the moment they are:
success : function (data, textStatus)
> 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 l
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 Adams
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
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.d
On Tue, Dec 1, 2009 at 8:21 PM, Julian Aubourg 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", {
> 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 y
Well, here is how this mini-project evolved so that you can get an idea how
it became what it is.
- At first I thought about a kinda enhanced $.ajaxSettings.xhr() with a
simple factory and that's it.
- Then I realized this would have meant a lot of code to provide by
"transport" developpers, mainl
I confirm that jQuery.isObjectLiteral(document.createElement("div")) returns
true under IE8.
2009/12/2 Julian Aubourg
> 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 & Fire
I'm still a little confused as to why the XHR (with "transport")
plugin doesn't give us what we need in terms of being able to provide
an alternate XHR-like transport that $.ajax will use?
I found it to be quite graceful and succinct for what I was doing with
flXHR and the jQuery.flXHR plugin.
Th
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
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
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
> > OK, so I have implemented my solution:
>
> > An
> 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
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(...).complet
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.
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
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
itera
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
wrote:
> OK, just a post to keep you all updated since I didn't get as much time as
> I expected thou
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
I looked into your code and we basically have the same approach. I'll try &
get the refactoring done by the middle of next week (like I said, I have
social life getting in the way right now ;) ).
2009/11/15 Shade
> I've built two different JavaScript projects which implement a nearly
> identical
I've built two different JavaScript projects which implement a nearly
identical interface to the native XHR object, including updating
properties, etc, while hiding under the covers how the actual XHR
happens. One is flXHR (http://flxhr.flensed.com) which actually has a
jQuery plugin that adapts fl
On Nov 13, 6:39 am, Scott Sauyet wrote:
> On Thu, Nov 12, 2009 at 1:15 PM, John Resig 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 prope
On Thu, Nov 12, 2009 at 1:15 PM, John Resig 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
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 system
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
I updated the spreadsheet to combine a few of the identical columns
and add ticket numbers for the items you created.
On #5501, processData=true by default to serialize a data object to a
string. Since the data has to be appended to the URL for a GET
request, it doesn't seem like processData=false
36 matches
Mail list logo
