JavaScript ajax library critique

[JR]

While it might be more efficient to use the new "native object" (it isn't
one) over the ActiveX object, it is less helpful, and not suited for a
general-purpose XHR library: by contrast, it does not support `file://' URIs
and it is not backwards-compatible.

`file://' URIs are blocked by default in FF 3 for instance
(about:config, security.fileuri.strict_origin_policy).

-- JR

 

[Thomas 'PointedEars' Lahn]

Yes. There are lots of examples (e.g. all ActiveX methods):-

No. From that i can see they have own implementation of internal
[[Get]] and [[Put]] methods.

var a = window.external.addFavorite;

No type conversion but error is still there. Interesting in that part
is typeof.

[...]

The error is unrelated to type conversion.

True. It is related to the implementation-dependent [[Get]] method of the
host object that `window.external' refers to, which is triggered by the
property accessor (ES3F/ES5, 11.2.1).

The typeof operator works on reference and so it seems that typeof can't
get a reference, then it returns "unknown".

"unknown" is one possible implementation-dependent value returned by the
algorithm for the `typeof' operator as triggered by its step 5 (ES3F,
11.4.3) or 3 (ES5, 11.4.3). It does not require the type of the operand to
be a non-Reference, and it is not likely for a property accessor to a
method to result in such a value.


PointedEars

 

[David Mark]

Asen Bozhilov wrote:
Garrett Smith wrote:
David Mark wrote:
No, you are just confusing the uninitiated with your confusion.
You wrote:
| Ajax is global.  It's not referenced by the local Activation
| Object.  If it were, virtually everything would leak (think about it).
The Ajax object is not a member of the containing scope, but it is a
member of an object in the containing scope's containing scope.
If you are correct:
window.onload = function(){};
That will be produce circular reference. If `window' host object is
property of Global Object diagram is:
Global Object -> window -> onload -> AF[[scope]] -> Global Object
Right.

Wrong, no leak.  Give it up.

It must be frustrating not being able to explain things.

Go back and read my posts to this thread. I explained your
misunderstanding at least twice. Baiting won't garner a third.

 

[Asen Bozhilov]

"unknown" is one possible implementation-dependent value returned by the
algorithm for the `typeof' operator as triggered by its step 5 (ES3F,
11.4.3) or 3 (ES5, 11.4.3).  It does not require the type of the operand to
be a non-Reference, and it is not likely for a property accessor to a
method to result in such a value.

All right but step 4 in 11.4.3 ECMA3 explicit say:

| 4. Call GetValue(Result(1)).

So again we have implicit invocation of [[Get]]. They have error
handling in typeof implementation or treat that for special case in
theirs [[Get]] method. Can you give a clear explanation or better
supposition?

Merry Christmas.

 

[Thomas 'PointedEars' Lahn]

According to Adam Wiener, Lead Program Manager for Data
Programmability/XML Technologies (Microsoft), the “Microsoftâ€
namespace is actually older and is only implemented in MSXML3 for
legacy support. So “msxml2†namespace should be used for
instantiating objects.

http://blogs.msdn.com/xmlteam/archive/2006/10/23/using-the-right-version-

of-msxml-in-internet-explorer.aspx

That does not answer my question, though.

And since "Microsoft.XMLHTTP" apparently means the same as
"MSXML2.XMLHTTP.2.0", what he suggested in 2006 did not make sense then and
is not making more sense now. Replacing the identifier with
"MSXML2.XMLHTTP.3.0" as he suggests would break compatibility. Adding the
identifier would decrease efficiency for older implementations at no
advantage. Surely you are not suggesting Microsoft would deliberately
break backwards-compatibility?


PointedEars

 

[JR]

of-msxml-in-internet-explorer.aspx

That does not answer my question, though.

And since "Microsoft.XMLHTTP" apparently means the same as    
"MSXML2.XMLHTTP.2.0", what he suggested in 2006 did not make sense then and
is not making more sense now.  Replacing the identifier with
"MSXML2.XMLHTTP.3.0" as he suggests would break compatibility.  Adding the
identifier would decrease efficiency for older implementations at no
advantage.  Surely you are not suggesting Microsoft would deliberately
break backwards-compatibility?

According to MSDN (http://msdn.microsoft.com/en-us/library/
cc507441%28VS.85%29.aspx)
- "MSXML 3.0 and prior versions of MSXML are version independent.
MSXML 3.0 was the last version of MSXML to support version-independent
CLSIDs and ProgIDs."
- "MSXML 3.0 is supported in Windows Vista; Windows Server 2003;
Windows XP; Windows 2000; Windows 98; Windows Millenium Edition (ME)."

You seem to be mistaking MSXML versions with IE versions. You may look
for msxml3.dll (v. 3.0) in your Windows\System32 folder to verify the
above information.

Since the OP's original code 'try-catch' only version 2.0
(Microsoft.XMLHTTP), I think his code needs to test for version 3.0 as
well (MSXML2.XMLHTTP).

 

[JR]

According to MSDN (http://msdn.microsoft.com/en-us/library/
cc507441%28VS.85%29.aspx)
- "MSXML 3.0 and prior versions of MSXML are version independent.
MSXML 3.0 was the last version of MSXML to support version-independent
CLSIDs and ProgIDs."
- "MSXML 3.0 is supported in Windows Vista; Windows Server 2003;
Windows XP; Windows 2000; Windows 98; Windows Millenium Edition (ME)."

You seem to be mistaking MSXML versions with IE versions. You may look
for msxml3.dll (v. 3.0) in your Windows\System32 folder to verify the
above information.

Since the OP's original code 'try-catch' only version 2.0
(Microsoft.XMLHTTP), I think his code needs to test for version 3.0 as
well (MSXML2.XMLHTTP).

Actually, you only need to use new ActiveXObject("Msxml2.XMLHTTP"). Do
not worry about the current MSXML version registered in the client's
computer.

 

[JR]

Actually, you only need to use new ActiveXObject("Msxml2.XMLHTTP"). Do
not worry about the current MSXML version registered in the client's
computer.

So, returning to the OP's original code, I'd suggest the following
snippet:

Ajax = {
transport : (function () {
var req = null;
if (typeof window.XMLHttpRequest != "undefined") {
// IE7+, FF, Opera 8.0+, Safari.
try { req = new XMLHttpRequest(); }
catch (e) { } // Ignores any exception.
} else if (typeof window.ActiveXObject != "undefined") {
//IE 5+, 6, or IE7/8 with native XMLHTTP support disabled.
try { req = new ActiveXObject("Msxml2.XMLHTTP"); }
catch (ex) {
try { req = new ActiveXObject("Microsoft.XMLHTTP"); }
catch (expt) { }
}
} else {
// alert("Your browser doesn't support AJAX. Sorry!");
}
return req;
})();

// other properties.
};

 

[Garrett Smith]

[...]

So, returning to the OP's original code, I'd suggest the following
snippet:

Ajax = {

Don't forget var.

 

[JR]

On Dec 27, 11:25 pm, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
JR wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
On Dec 23, 3:59 pm, Mychal Hackman <[email protected]> wrote:

[...]

So, returning to the OP's original code, I'd suggest the following
snippet:

Ajax = {

Don't forget var.

Oops! Thank you!

I'd also substitute:
- 'Ajax' for 'var ajax = {...}', because 'ajax' won't be used as a
constructor; and
- the semicolon ( after the 'transport' method for just a comma (,)
because there are other properties coming after it.

Cheers,
JR

 

[JR]

Had to look into this last night and will use something like
this, gleaned from Wikipedia:

if (typeof XMLHttpRequest == "undefined") {
  XMLHttpRequest = function() {
    try { return new ActiveXObject("Msxml2.XMLHTTP.6.0"); }
      catch (ignore) {}
    try { return new ActiveXObject("Msxml2.XMLHTTP.3.0"); }
      catch (ignore) {}
    throw new Error("This browser does not support
XMLHttpRequest.");
  };

}

Firstly, the code should try new XMLHttpRequest() before the
activeXObject, because it's supported in all of the new versions of
IE, FF, Safari, Opera, and Chrome, just to mention the 'majors'.

In addition, David Mark has made a negative comment on a similar code
that I've copied (and pasted here) from the MSDN site. I think he used
the term 'awful' to describe the attempt to override the
XMLHttpRequest object.

If you want to support browsers older than IE6, you may have to
add things like:

    try { return new ActiveXObject("Msxml2.XMLHTTP"); }
      catch (ignore) {}
    try { return new ActiveXObject("Microsoft.XMLHTTP"); }
      catch (ignore) {}

But are you sure your JavaScript will actually run perfectly in
Internet Explorer 5.x or other older browsers? Fortunately I
don't have to support those.

According to my readings on the Microsoft website (MSDN mainly), it is
not really necessary to specify the version of the Msxml2.XMLHTTP
ActiveX object. When you write 'new ActiveXObject("Msxml2.XMLHTTP");',
the browser (IE) tries to instantiate the active version registered in
the computer's OS (Windows).

Cheers,
JR

 

[Garrett Smith]

Had to look into this last night and will use something like
this, gleaned from Wikipedia:

if (typeof XMLHttpRequest == "undefined") {
XMLHttpRequest = function() {

Why is it that this thread keeps missing var?

The problem with adding a user-defiend global XMLHttpRequest is that it
will trip up other code that makes the same check:-

if(typeof XMLHttpRequest == "undefined") {

}

 

[Thomas 'PointedEars' Lahn]

Why is it that this thread keeps missing var?

The problem with adding a user-defiend global XMLHttpRequest is that it
will trip up other code that makes the same check:-

if(typeof XMLHttpRequest == "undefined") {

}

You are not making any sense.


PointedEars

 

[Garrett Smith]

It makes your user-defined function look like the real deal.

 

[Thomas 'PointedEars' Lahn]

It makes your user-defined function look like the real deal.

And that is bad[tm], because ...?


PointedEars

 

[David Mark]

It makes your user-defined function look like the real deal.

And that is bad[tm], because ...?

Because they are not exactly equivalent.

 

[Garrett Smith]

It makes your user-defined function look like the real deal.

And that is bad[tm], because ...?

Making the user-defined function look like the real deal is bad because
it isn't. If a script makes a check:-

var IS_NATIVE_XHR = typeof XMLHttpRequest !== "undefined";

- the script is misled. It might seem safe, but it isn't; the
user-defined new XMLHttpRequest() can throw:-

"This browser does not support XMLHttpRequest."

 

[JR]

Garrett Smith wrote:

And that is bad[tm], because ...?

Making the user-defined function look like the real deal is bad because
it isn't. If a script makes a check:-

var IS_NATIVE_XHR = typeof XMLHttpRequest !== "undefined";

- the script is misled.  It might seem safe, but it isn't; the
user-defined new XMLHttpRequest() can throw:-

"This browser does not support XMLHttpRequest."

Yeah, a bad example (Very bad indeed!!!) from Wikipedia:
http://en.wikipedia.org/wiki/XMLHttpRequest

It's not even necessary to check for "Msxml2.XMLHTTP.6.0",
"Msxml2.XMLHTTP.5.0", 4.0 or 3.0. Just try using "Msxml2.XMLHTTP", and
"Microsoft.XMLHTTP" as a last alternative. As I posted earlier, the
version of the MSXML Parser is dependent on the Windows version, not
on the IE version, according to the MSDN article that I cited (on that
post).

 

[JR]

Garrett Smith wrote:
Hans-Georg Michna wrote:
Had to look into this last night and will use something like
this, gleaned from Wikipedia:
if (typeof XMLHttpRequest == "undefined") {
  XMLHttpRequest = function() {
Why is it that this thread keeps missing var?
The problem with adding a user-defiend global XMLHttpRequest is that it
will trip up other code that makes the same check:-
if(typeof XMLHttpRequest == "undefined") {
}
It makes your user-defined function look like the real deal.
And that is bad[tm], because ...?

Making the user-defined function look like the real deal is bad because
it isn't. If a script makes a check:-

var IS_NATIVE_XHR = typeof XMLHttpRequest !== "undefined";

- the script is misled.  It might seem safe, but it isn't; the
user-defined new XMLHttpRequest() can throw:-

"This browser does not support XMLHttpRequest."

Yeah, a bad example (Very bad indeed!!!) from Wikipedia:http://en.wikipedia.org/wiki/XMLHttpRequest

It's not even necessary to check for "Msxml2.XMLHTTP.6.0",
"Msxml2.XMLHTTP.5.0", 4.0 or 3.0. Just try using "Msxml2.XMLHTTP", and
"Microsoft.XMLHTTP" as a last alternative. As I posted earlier, the
version of the MSXML Parser is dependent on the Windows version, not
on the IE version, according to the MSDN article that I cited (on that
post).

I wrote this example to let someone know which XLMHTTP versions are
available on his/her computer:

<script type="text/javascript">
(function () {
var xmlVersions = [
'Microsoft.XMLHTTP',
'Msxml2.XMLHTTP.3.0',
'Msxml2.XMLHTTP.4.0',
'Msxml2.XMLHTTP.5.0',
'Msxml2.XMLHTTP.6.0'
], i, len, xhr, ret = "<p>";
for (i = 0, len = xmlVersions.length; i < len; i++) {
try {
xhr = new ActiveXObject(xmlVersions);
if (xhr) { ret += xmlVersions +"<br>"; }
} catch(ex) { }
}
document.write('MSXML versions available on this computer:<br>' +
ret + '</p>');
})();
</script>

 

[David Mark]

Garrett Smith wrote:
Hans-Georg Michna wrote:
Had to look into this last night and will use something like
this, gleaned from Wikipedia:
if (typeof XMLHttpRequest == "undefined") {
  XMLHttpRequest = function() {
Why is it that this thread keeps missing var?
The problem with adding a user-defiend global XMLHttpRequest is that it
will trip up other code that makes the same check:-
if(typeof XMLHttpRequest == "undefined") {
}
It makes your user-defined function look like the real deal.
And that is bad[tm], because ...?

Making the user-defined function look like the real deal is bad because
it isn't. If a script makes a check:-

var IS_NATIVE_XHR = typeof XMLHttpRequest !== "undefined";

- the script is misled.  It might seem safe, but it isn't; the
user-defined new XMLHttpRequest() can throw:-

"This browser does not support XMLHttpRequest."

Yeah, a bad example (Very bad indeed!!!) from Wikipedia:http://en.wikipedia.org/wiki/XMLHttpRequest

It's not even necessary to check for "Msxml2.XMLHTTP.6.0",
"Msxml2.XMLHTTP.5.0", 4.0 or 3.0. Just try using "Msxml2.XMLHTTP", and
"Microsoft.XMLHTTP" as a last alternative. As I posted earlier, the
version of the MSXML Parser is dependent on the Windows version, not
on the IE version, according to the MSDN article that I cited (on that
post).

Yes, that seems reasonable. I don't recall ever having to deal with
the version numbers instantiating COM objects (for any component) in
desktop development (of course, it's been quite a long time). IIRC,
looking at how the entries are registered with the OS is
illuminating. So glad I never have to deal with such MS nonsense
again.

This is from the old CWR project (and ended up in My Library). It was
discussed (here) quite a bit back then. I don't remember the details,
but the rationale seemed reasonable to me at the time.

// for legacy eg. IE 5
function() {
return new global.ActiveXObject("Microsoft.XMLHTTP");
},
// for fully patched Win2k SP4 and up
function() {
return new global.ActiveXObject("Msxml2.XMLHTTP.3.0");
},
// IE 6 users that have updated their msxml dll files.
function() {
return new global.ActiveXObject("Msxml2.XMLHTTP.6.0");
},