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
> 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
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 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:
- 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
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
27 matches
Mail list logo
