This is a very smart strategy, never aware of that. I think I can
benefit a lot from it. Thanks for mentioning!
On Oct 24, 2:23 am, Andrea Giammarchi
wrote:
> Hi Scott, almost everything fine ...
>
> On Fri, Oct 23, 2009 at 6:39 PM, Scott Sauyet wrote:
>
>
>
> > So the only thing left is the act
This is very thorough! Now I understand the code, Thanks a lot!
But doe it mean I have to write code like this to make an ajax:
// Set defaults
$.ajaxSetup({
data:{
defaultKey:"defaultValue"
}
});
// Make an ajax call
$.ajax({
url: './index.html',
data: $.ajaxSetup.ext({
Thank you! This really does the trick, but now the real problem is to
using a setInterval to check location.hash to implement an
"onhashchange" event. These events are all asynchronous, and I can't
get my tests passed, here is the test case:
http://dl.getdropbox.com/u/1402827/hashchange/index.htm
On Sat, Oct 24, 2009 at 12:22 AM, DBJDBJ wrote:
>
> Well for the FF team this was not meaningless, since it is possible to
> set/get css value on the non-attached newly created dom element in FF
> and then get to it through getComputedStyle()
> You just have to follow in the Firebug and Chrome co
What a waste of time ...I have posted the code which neither of you
have checked in her browsers ...
@Scot : where is the definition/explantaion of the CSS2 computed
values about the created but un-attached dom element ?
If this would be defined, FF and Chrome would most likely do it in the
same
On Fri, Oct 23, 2009 at 8:44 PM, Steven Parkes wrote:
>
> Not an example of how XHR is defined, but how XHR implemented as a
> thread could communicate back to the main thread. It can't call the
> onreadystate callback on its own thread, but it could use setTimeout
> to get it queued to be run on
Just use sync: true in all tests and put an end to this discussion :)
On Oct 22, 9:26 pm, gMinuses wrote:
> I'd like to test the following code to make sure:
>
> 1. setTimeout calls the function
> 2. ajax success callback is called
>
> setTimeout(function() {
>
> $.ajax({
>
On Oct 23, 2009, at Oct 23,12:30 PM , Andrea Giammarchi wrote:
> It's quite pretentious to define an XHR call as setTimeout(fn, 0)
Not an example of how XHR is defined, but how XHR implemented as a
thread could communicate back to the main thread. It can't call the
onreadystate callback on
On Fri, Oct 23, 2009 at 7:40 PM, Steven Parkes wrote:
>
> Certainly possible.
>
> And I know nothing about Flash. Only pure JS, which is not Flash, by
> any means.
>
ActionScript 1.0 the one I am certified (2.0 as well) is 99.9% JavaScript,
except arguments are arrays, and setInterval/setTimeout
Oh, I certainly caught the sarcasm. DBJDBJ's question piqued my
curiosity. I wanted to see if the spec had something to say about how
getComputedStyle worked with elements not in the DOM.
It did.
I couldn't tell if DBJDBJ was intending some sarcasm as well or simply
was too lazy to Google it b
> I think now you are the one confusing timers with the fact
> JavaScript is single threading for each tab ...
>
> I wrote a complete Ajax Guide in 2004 and used LoadVars via Flash
> before so hopefully I know these things ...
Certainly possible.
And I know nothing about Flash. Only pure JS,
Hi Scott, almost everything fine ...
On Fri, Oct 23, 2009 at 6:39 PM, Scott Sauyet wrote:
>
> So the only thing left is the actual definition of "ext". Nothing to
> it, right? :-)
>
extend
Note that the re-use of the name ext in this declaration is not
> necessary.
named functions are good
Thanks Scott, my reply was quite sarcastic ... if a node is removed or is
not in the document nothing changes, "Computed" words speaks itself ... I
mean, if not rendered or present, there's nothing computed for sure.
Regards
On Fri, Oct 23, 2009 at 5:25 PM, Scott Sauyet wrote:
>
> On Fri, Oct 23
I think now you are the one confusing timers with the fact JavaScript is
single threading for each tab ...
I wrote a complete Ajax Guide in 2004 and used LoadVars via Flash before so
hopefully I know these things ... in any case for this ML purpose it's
always good to remind people how are things
However, I'm not sure I understand the advantage of the above over the
arguably simpler:
jQuery.ajaxSettings.ext = function(o) {
var k, result = {};
if(this.data) {
for(k in this.data)
result[k] = this.data[k]
;
On Thu, Oct 22, 2009 at 9:57 PM, gMinuses wrote:
> I'm sorry, but I don't quite understand your code.
It took me a while to get it, too. Obviously Andrea can tell you
better, but perhaps a mere mortal can explain it better to other
mortals. :-)
First of all, you need to know that jQuery.ajaxS
On Fri, Oct 23, 2009 at 11:11 AM, DBJDBJ wrote:
> What does W3C DOM spec says?
"Since a computed style is related to an Element node, if this element
is removed from the document, the associated CSSStyleDeclaration and
CSSValue related to this declaration are no longer valid." --
http://www.w3.
> I was talking about Ajax calls, no timeouts, but maybe you are not
> replying to my post :-)
Sorry. This stuff does all mix together. XHR can execute async to the
Javascript thread, but all callbacks are executed on the Javascript
thread. so any onreadystatechange callbacks won't get exec
On Fri, Oct 23, 2009 at 4:30 PM, Steven Parkes wrote:
>
> There's a lot of misinformation in here about timers. I'd recommend
> people read John's discussion of timers:
>
I was talking about Ajax calls, no timeouts, but maybe you are not replying
to my post :-)
Regards
--~--~-~--~~-
This should probably be moved off the dev list to the general jquery
list.
There's a lot of misinformation in here about timers. I'd recommend
people read John's discussion of timers:
http://ejohn.org/blog/how-javascript-timers-work/.
> I am not sure what you are asking for but from logical
What does W3C DOM spec says?
--DBJ
On Oct 23, 12:05 pm, Andrea Giammarchi
wrote:
> I wonder how meaningless would be a get*Computed*Style for a node not in DOM
> neither rendered yet ... it's not clear in any case which browser does what.
>
> On Fri, Oct 23, 2009 at 11:58 AM, DBJDBJ wrote:
>
I still think the testing order should be determined. It's not the
test cases themselves are asynchronous, it's the functions they are
going to test are asynchronous, and that's why we use a "stop()" to
stop a test case, and use a "start()" in the asynchronous function to
restart the test case, by
If we need asynchronous calls for a synchronous management, we should use
success as "next call if any" event.
var queue = [function(){/*1*/}, function(){function(){/*2*/}},
function(){/*3*/}, function(){/*4*/}], ajax;
$.ajax(ajax = {
url: './index.html',
success: fun
I wonder how meaningless would be a get*Computed*Style for a node not in DOM
neither rendered yet ... it's not clear in any case which browser does what.
On Fri, Oct 23, 2009 at 11:58 AM, DBJDBJ wrote:
>
>
> CHROME 4.0.223.9
>
> If one does this :
>var dumsy = $("").css
> ("color", "re
Uhm, uhm ... AG is right ... Logically asynchronous events start
immediately upon firing, but they *finish* at an future undetermined
point on the time vector. (or "never")
This is why this paradigm is also called "fire and forget" ... vs
"wait for return" Synchronous paradigm.
Therefore: ordered
CHROME 4.0.223.9
If one does this :
var dumsy = $("").css
("color", "red");
C = window.getComputedStyle(dumsy[0], null).getPropertyValue
("color");
C will be empty string , aka "". Also observing
window.getComputedStyle(dumsy[0], null).cssText will reveal that
"color:" has no
clearTimeout() as soon as you can
clearInterval() same as above or in window unload event
On Oct 23, 5:49 am, gMinuses wrote:
> You mean those timers should be reset in the "unload" event? I thought
> the browser was gonna do the job. Anyway, thanks for mentioning!
>
> On Oct 23, 4:40 pm, DBJDB
You mean those timers should be reset in the "unload" event? I thought
the browser was gonna do the job. Anyway, thanks for mentioning!
On Oct 23, 4:40 pm, DBJDBJ wrote:
> Agreed: QUNIT could be documented better.
>
> BTW: Just to be sure "we are by the book" ;o)
> I would be so bold to recomme
On Oct 23, 4:11 pm, Andrea Giammarchi
wrote:
> generally speaking asynchronous calls do not guarantee order by default
I think asynchronous tests themselves should guarantee the order. You
fire up two asynchronous calls and their executing order really
doesn't matter. But for asynchronous test
Agreead.
Also: Not having QUnit introduce global functions would be *very*
usefull, too.
I dare to think we all understand how much more advisable is to have :
qunit.test()// or Q.test() or whatever else ...
instead of :
test()
--DBJ
--~--~-~--~~~---~--~~
Y
Agreed: QUNIT could be documented better.
BTW: Just to be sure "we are by the book" ;o)
I would be so bold to recommend ,instead of this :
setTimeout(function() {
$(window).unbind('hashchange');
start();
},
On Fri, Oct 23, 2009 at 1:26 AM, gMinuses wrote:
>
> If you open firebug, you can see the order is "1,3,2,4", which can
> cause disasters.
I am not sure what you are asking for but from logical point of view and
generally speaking asynchronous calls do not guarantee order by default so
your beh
32 matches
Mail list logo
