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
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
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
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
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?:
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
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
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
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
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.
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
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)
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
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
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:
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
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
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
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
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
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
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
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
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
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
25 matches
Mail list logo
