Question: XMLHttpRequest

[q-rious]

Hello All,

I have a question regarding XMLHttpRequest. I have the following code
(as part of a much larger file):

function loadXMLDoc(url)
{
// branch for native XMLHttpRequest object
if (window.XMLHttpRequest) {
req = new XMLHttpRequest();
req.onreadystatechange = processReqChange;
alert("Inside loadXML.3. URL: "+url);
req.open("GET", url, true);
alert("Inside loadXML.4");
req.send(null);
alert("Inside loadXML.5");
}
}

When I use this javascript file locally and load the HTML page as a
file that calls the above function, everything works fine. However,
when I put the same HTML file in a web server (along with the
javascript file), the alert on "Inside loadXML.4" never happens. Or in
other words, nothing happens after req.open call.

Few observations:
(a) This is not a synchronous/asynchronous call problem (the last
argument to req.open being true or false). I have tried both.
(b) This is not a caching problem when the HTML file is used as a
local file.

Any help will be much appreciated.

Thanks.

[Martin Honnen]

q-rious wrote:

req.open("GET", url, true);
alert("Inside loadXML.4");
req.send(null);
alert("Inside loadXML.5");
}
}

When I use this javascript file locally and load the HTML page as a
file that calls the above function, everything works fine. However,
when I put the same HTML file in a web server (along with the
javascript file), the alert on "Inside loadXML.4" never happens. Or in
other words, nothing happens after req.open call.

Check the error console, probably you are using a URL from a different
origin than your document with the script and that way the browser (e.g.
Firefox) gives an error on the open call.

--

Martin Honnen
http://JavaScript.FAQTs.com/

[q-rious]

On Aug 10, 10:06*am, Martin Honnen <[e-mail]:

>
Check the error console, probably you are using a URL from a different
origin than your document with the script and that way the browser (e.g.
Firefox) gives an error on the open call.

Martin,

Thanks for your reply. I already had checked the error console. It did
show an error but on a comment. I know that is probably the best clue
I have in this case, but I was hoping for some more debugging tips if
anyone has some. Just so that you know the variable 'url' is actually
a constant string that did not change between my local and remote
testing. So, the only change I can think of has to come from the web
server side.

Looking for more tips...

[Matt]

Personally, I would avoid using XMLHttpRequest directly...if you use
the Prototype library you can eliminate any browser issues that could
be the culprit. Also, like Martin said, I think the problem is the
URL. What is the URL that you're call is requests and what is the URL
of your javascript file? If those two URLs don't originate from the
same domain, it will not work due to security reasons.

On Aug 10, 5:34*pm, q-rious <[e-mail]:

On Aug 10, 10:06*am, Martin Honnen <[e-mail]:

Check the error console, probably you are using a URL from a different
origin than your document with the script and that way the browser (e.g..
Firefox) gives an error on the open call.

Martin,

Thanks for your reply. I already had checked the error console. It did
show an error but on a comment. I know that is probably the best clue
I have in this case, but I was hoping for some more debugging tips if
anyone has some. Just so that you know the variable 'url' is actually
a constant string that did not change between my local and remote
testing. So, the only change I can think of has to come from the web
server side.

Looking for more tips...

[David Mark]

On Aug 10, 9:43*pm, Matt <[e-mail]:

Personally, I would avoid using XMLHttpRequest directly...if you use

You should avoid top-posting too. At least in this group.

the Prototype library you can eliminate any browser issues that could

Translation: I don't know what I am talking about.

[Matt]

On Aug 10, 9:46*pm, David Mark <[e-mail]:

On Aug 10, 9:43*pm, Matt <[e-mail]:

Personally, I would avoid using XMLHttpRequest directly...if you use

You should avoid top-posting too. *At least in this group.

the Prototype library you can eliminate any browser issues that could

Translation: I don't know what I am talking about.

Are you saying that the Prototype library doesn't make Ajax easier,
and that it doesn't fix cross browser compatibility issues? Have you
ever written an Ajax application?

[q-rious]

On Aug 10, 6:43*pm, Matt <[e-mail]:

Personally, I would avoid using XMLHttpRequest directly...if you use
the Prototype library you can eliminate any browser issues that could
be the culprit. *Also, like Martin said, I think the problem is the
URL. *What is the URL that you're call is requests and what is the URL
of your javascript file? *If those two URLs don't originate from the
same domain, it will not work due to security reasons.

Hi Matt,

Thanks for the hints.

(a) Please point me to the 'Prototype library'. Sorry, I am new to
this.
(b) The HTTP call is to a domain named google.com and the javascript
runs on myowndomain.com. I am not sure why this is a security problem
since the called website makes these data available publicly as well
documented APIs. Also as I said, it works as my local file.

Thanks again.

[David Mark]

On Aug 10, 11:15*pm, Matt <[e-mail]:

On Aug 10, 9:46*pm, David Mark <[e-mail]:

On Aug 10, 9:43*pm, Matt <[e-mail]:

Personally, I would avoid using XMLHttpRequest directly...if you use

You should avoid top-posting too. *At least in this group.

the Prototype library you can eliminate any browser issues that could

Translation: I don't know what I am talking about.

Are you saying that the Prototype library doesn't make Ajax easier,

Yes.

and that it doesn't fix cross browser compatibility issues?

It doesn't and that is the least of its problems.

*Have you

ever written an Ajax application?

Yes.

[David Mark]

On Aug 11, 1:42*am, q-rious <[e-mail]:

On Aug 10, 6:43*pm, Matt <[e-mail]:

Personally, I would avoid using XMLHttpRequest directly...if you use
the Prototype library you can eliminate any browser issues that could
be the culprit. *Also, like Martin said, I think the problem is the
URL. *What is the URL that you're call is requests and what is the URL
of your javascript file? *If those two URLs don't originate from the
same domain, it will not work due to security reasons.

Hi Matt,

Thanks for the hints.

Hints from Prototype proponents are always the same: use Prototype.

>
(a) Please point me to the 'Prototype library'. Sorry, I am new to
this.

That would be pointless in this case. In fact, I can't think of any
case where that would help.

(b) The HTTP call is to a domain named google.com and the javascript
runs on myowndomain.com. I am not sure why this is a security problem

You don't need to worry about why it is a security problem, but you do
need to be conscious of this issue.

since the called website makes these data available publicly as well
documented APIs. Also as I said, it works as my local file.

It will work from a local file in some browsers' default
configurations. So what?

[Gregor Kofler]

q-rious meinte:

On Aug 10, 6:43 pm, Matt <[e-mail]:

>Personally, I would avoid using XMLHttpRequest directly...if you use
the Prototype library you can eliminate any browser issues that could
be the culprit.

What "browser issues"? XHR is relatively easy dealt with. A
cross-browser solution is easily realized within 50 lines of code. And
you are suggesting a buggy library, that weighs in with - how much? -
100kiB? (And whichs "API" has to be understood, too.)

Hi Matt,

Thanks for the hints.

What hints?

(a) Please point me to the 'Prototype library'. Sorry, I am new to
this.

Google "prototype.js". However, this won't help you to understand
JavaScript or DOM models or why things work or don't work. And don't ask
for "problems" with your prototype.js reinforced JS-"applications" in
this NG.

(b) The HTTP call is to a domain named google.com and the javascript
runs on myowndomain.com. I am not sure why this is a security problem
since the called website makes these data available publicly as well
documented APIs. Also as I said, it works as my local file.

Google "Same-origin policy".

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[Matt]

On Aug 11, 2:36*am, Gregor Kofler <[e-mail]:

q-rious meinte:

On Aug 10, 6:43 pm, Matt <[e-mail]:

Personally, I would avoid using XMLHttpRequest directly...if you use
the Prototype library you can eliminate any browser issues that could
be the culprit.

What "browser issues"? XHR is relatively easy dealt with. A
cross-browser solution is easily realized within 50 lines of code. And
you are suggesting a buggy library, that weighs in with - how much? -
100kiB? (And whichs "API" has to be understood, too.)

Hi Matt,

Thanks for the hints.

What hints?

(a) Please point me to the 'Prototype library'. Sorry, I am new to
this.

Google "prototype.js". However, this won't help you to understand
JavaScript or DOM models or why things work or don't work. And don't ask
for "problems" with your prototype.js reinforced JS-"applications" in
this NG.

(b) The HTTP call is to a domain named google.com and the javascript
runs on myowndomain.com. I am not sure why this is a security problem
since the called website makes these data available publicly as well
documented APIs. Also as I said, it works as my local file.

Google "Same-origin policy".

Gregor

--http://photo.gregorkofler.at::: Landschafts- und Reisefotografiehttp://web.gregorkofler.com*::: meine JS-Spielwiesehttp://www.image2d.com* ** ::: Bildagentur für den alpinen Raum

Wow, so apparently there are some Prototype haters. Prototype's Ajax
object is great. You don't have to create an ActiveX object for IE
and a new XHR object for everything else for starters. Have any of
you ever heard of DRY? Why would you re-write the same JavaScript to
1. Create the XHR object, 2. check the response status, and 3 handle
the response? You can do all of those things in the constructor of
the Ajax.Request object. I've never heard Prototype referred to as
"Buggy"...you wouldn't think that things like Scriptaculous (to name
one of many popular frameworks that build ontop of Prototype) would
choose a "Buggy" library to build from...

[David Mark]

On Aug 11, 3:55*am, Matt <[e-mail]:

On Aug 11, 2:36*am, Gregor Kofler <[e-mail]:

q-rious meinte:

On Aug 10, 6:43 pm, Matt <[e-mail]:
>Personally, I would avoid using XMLHttpRequest directly...if you use
>the Prototype library you can eliminate any browser issues that could
>be the culprit.

What "browser issues"? XHR is relatively easy dealt with. A
cross-browser solution is easily realized within 50 lines of code. And
you are suggesting a buggy library, that weighs in with - how much? -
100kiB? (And whichs "API" has to be understood, too.)

Hi Matt,

Thanks for the hints.

What hints?

(a) Please point me to the 'Prototype library'. Sorry, I am new to
this.

Google "prototype.js". However, this won't help you to understand
JavaScript or DOM models or why things work or don't work. And don't ask
for "problems" with your prototype.js reinforced JS-"applications" in
this NG.

(b) The HTTP call is to a domain named google.com and the javascript
runs on myowndomain.com. I am not sure why this is a security problem
since the called website makes these data available publicly as well
documented APIs. Also as I said, it works as my local file.

Google "Same-origin policy".

Gregor

--http://photo.gregorkofler.at:::Landschafts- und Reisefotografiehttp://web.gregorkofler.com*::: meine JS-Spielwiesehttp://www.image2d.com*** ::: Bildagentur für den alpinen Raum

Wow, so apparently there are some Prototype haters. *Prototype's Ajax
object is great. *You don't have to create an ActiveX object for IE

There is absolutely nothing great about it.

and a new XHR object for everything else for starters. *Have any of
you ever heard of DRY? *Why would you re-write the same JavaScript to
1. Create the XHR object, 2. check the response status, and 3 handle

1. LOL.
2. LOL.
3. LOL.

the response? *You can do all of those things in the constructor of
the Ajax.Request object. *I've never heard Prototype referred to as

Or in hundreds of other ways.

"Buggy"...you wouldn't think that things like Scriptaculous (to name

Buggy. Inefficient. Stupidly designed. Prototype is more or less a
cult for JavaScript programmers who refuse to learn JavaScript. This
is hardly news.

one of many popular frameworks that build ontop of Prototype) would
choose a "Buggy" library to build from...

The fact that somebody somewhere wrote an extension to Prototype does
not imply that Prototype is bug-free. Regardless, bugs are the least
of its problems. The whole rotten structure needs to be torn down.

[Gregor Kofler]

Matt meinte:

(a) Trim your quotes.
(b) Stop quoting signatures.

Wow, so apparently there are some Prototype haters.

No need for that.

Prototype's Ajax
object is great. You don't have to create an ActiveX object for IE
and a new XHR object for everything else for starters. Have any of
you ever heard of DRY? Why would you re-write the same JavaScript to
1. Create the XHR object, 2. check the response status, and 3 handle
the response? You can do all of those things in the constructor of
the Ajax.Request object.

Impressive.

(c) Even the world-famous prototype.js has to create an ActiveX object
to access IE's XHR functionality.
(d) My very own library also wraps those browser peculiarites. All I do
is something like

var myXhr = vxJS.xhr(myParameters);

- and voila: No need to worry bout timeouts, response handling, request
encoding, aborting. It's magic. And it's less than 100 lines of code.
Including gimmicks. And it works in IE6+ (naturally), FF/Gecko, Safari,
Opera, Konqueror, etc. Er... what was that DRY term standing for?

I've never heard Prototype referred to as
"Buggy"...you wouldn't think that things like Scriptaculous (to name
one of many popular frameworks that build ontop of Prototype) would
choose a "Buggy" library to build from...

(e) I'd suggest to add jQuery for good measure.

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[Matt]

(c) Even the world-famous prototype.js has to create an ActiveX object
to access IE's XHR functionality.
(d) My very own library also wraps those browser peculiarites. All I do
is something like

var myXhr = vxJS.xhr(myParameters);

I have no problem with people not using Prototype...but why write your
own XHR wrapper if you don't have to. I'm not a member of a Prototype
"cult" to my knowledge...I only use the $ function and the Ajax
wrappers....no need for me to write and re-write my own version of
Ajax.Request and Ajax.PeriodicalUpdater. These have all been
thoroughly tested across browsers and platforms...why should I risk
writing my own code that could have a hole when running in IE for Mac
when I know that Prototype will already work?

- and voila: No need to worry bout timeouts, response handling, request
encoding, aborting. It's magic. And it's less than 100 lines of code.
Including gimmicks. And it works in IE6+ (naturally), FF/Gecko, Safari,
Opera, Konqueror, etc. Er... what was that DRY term standing for?

Dry stands for Don't Repeat Yourself....which is sounds like you're
not doing since you wrote your own XHR wrapper.

Alright...I've had enough back and fourth about Prototype vs. home
grown. I completely understand people's fear and/or distrust of open
source libraries. If you write everything from the ground up you'll
have a better understanding of how Ajax and the XHR object works....if
you choose to "re-invent the wheel" that's fine as long as you've got
enough hours in your project to work out the bugs.

David - since you seem to be VERY against Prototype is there a
different open source library that YOU opt to use, or do you just
"repeat yourself" every time you write a new Ajax app? Maybe you
should develop a better prototype if you've got so many problems with
the existing one. If you did that, I'd love to check it out and see
what improvements could be made.

q-rious - Did you get what you needed, or did we get off on a tangent
and forget about you?

[Thomas 'PointedEars' Lahn]

Matt wrote:

>(c) Even the world-famous prototype.js has to create an ActiveX object

s/famous/in\0/

>to access IE's XHR functionality. (d) My very own library also wraps
those browser peculiarites. All I do is something like

var myXhr = vxJS.xhr(myParameters);

I have no problem with people not using Prototype...but why write your
own XHR wrapper if you don't have to.

Because you have to. Prototype.js is junk, and I have yet to see another
heavily advertised library that is not.

I'm not a member of a Prototype "cult" to my knowledge...I only use the $
function and the Ajax wrappers...

That's bad enough, as discussions here show.

no need for me to write and re-write my own version of Ajax.Request and
Ajax.PeriodicalUpdater.

As someone relying on copy and pray, you are not exactly in a position to
make a correct assessment of your situation.

These have all been thoroughly tested across browsers and platforms...

Hardly. And even if that were true, them being marked working in an
environment by their testers would be rather a matter of coincidence.

why should I risk
writing my own code that could have a hole when running in IE for Mac
when I know that Prototype will already work?

Because you do not know that, and more knowledgeable people explained that
and why it breaks.

>- and voila: No need to worry bout timeouts, response handling, request
encoding, aborting. It's magic. And it's less than 100 lines of code.
Including gimmicks. And it works in IE6+ (naturally), FF/Gecko, Safari,
Opera, Konqueror, etc. Er... what was that DRY term standing for?

Dry stands for Don't Repeat Yourself....which is sounds like you're not
doing since you wrote your own XHR wrapper.

Georg is not repeating himself, and since there is no equivalent to his code
in Prototype.js, he is also not repeating that.

Alright...I've had enough back and fourth about Prototype vs. home grown.
I completely understand people's fear and/or distrust of open source
libraries.

You do not understand anything. This is not about fear or open source,
it is about being able to recognize code quality or, in the case of
Prototype.js & Co., the lack thereof.

If you write everything from the ground up you'll have a
better understanding of how Ajax and the XHR object works....

If only the authors of Prototype.js and Co. would have done that, there
might be the possibility that they could actually be recommended.

if you choose to "re-invent the wheel" that's fine as long as you've got enough
hours in your project to work out the bugs.

Working out the bugs of the heavily advertised libraries would already be a
lifetime commitment. It is only that because their users are incompetent
enough to fall for them, they will seldom, if ever, encounter the bugs. But
their visitors will.

[...]
q-rious - Did you get what you needed, or did we get off on a tangent and
forget about you?

Even if that, this is not a support forum. You get what you paid for.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>

[Matt]

Can someone give some specific examples of these alleged "bugs" in
Prototype? I'm hearing a LOT of conjecture about Prototype being crap.

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

Matt wrote:

>>- and voila: No need to worry bout timeouts, response handling, request
encoding, aborting. It's magic. And it's less than 100 lines of code.
Including gimmicks. And it works in IE6+ (naturally), FF/Gecko, Safari,
Opera, Konqueror, etc. Er... what was that DRY term standing for?

Dry stands for Don't Repeat Yourself....which is sounds like you're not
doing since you wrote your own XHR wrapper.

Georg is not repeating himself, and since there is no equivalent to his code
in Prototype.js, he is also not repeating that.

Sorry, *Gregor* :)
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Thomas 'PointedEars' Lahn]

Matt wrote:

Can someone give some specific examples of these alleged "bugs" in
Prototype? [...]

The thought had crossed my mind.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[Gregor Kofler]

Matt meinte:

Dry stands for Don't Repeat Yourself....which is sounds like you're
not doing since you wrote your own XHR wrapper.

I don't repeat *my*self. I use my own library on which I build my
widgets and applications. I wrote my first XHR wrapper about 2 1/2 years
ago. I don't know whether prototype already existed then. Even if: There
was no documentation available then.

you choose to "re-invent the wheel" that's fine as long as you've got
enough hours in your project to work out the bugs.

Debugging my own JS applications is actually way less frustrating than
somebody elses. And since I've improved on JS over the last couple of
months, time for debugging is falling considerably.

David - since you seem to be VERY against Prototype is there a
different open source library that YOU opt to use, or do you just
"repeat yourself" every time you write a new Ajax app?

Why should he? I suppose he reuses his own library.

Maybe you
should develop a better prototype if you've got so many problems with
the existing one. If you did that, I'd love to check it out and see
what improvements could be made.

Well, you could have a look at prototype.js and see what improvements
could be made there. If you think prototype is perfect (or at least
nearly perfect), then I doubt you can judge code quality.

Anyway, David has his library on the web. [1]

Gregor

[1] http://www.cinsoft.net/mylib.html
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[David Mark]

On Aug 11, 3:32*pm, Gregor Kofler <[e-mail]:

Matt meinte:

Dry stands for Don't Repeat Yourself....which is sounds like you're
not doing since you wrote your own XHR wrapper.

I don't repeat *my*self. I use my own library on which I build my
widgets and applications. I wrote my first XHR wrapper about 2 1/2 years
ago. I don't know whether prototype already existed then. Even if: There
was no documentation available then.

you choose to "re-invent the wheel" that's fine as long as you've got
enough hours in your project to work out the bugs.

Debugging my own JS applications is actually way less frustrating than
somebody elses. And since I've improved on JS over the last couple of
months, time for debugging is falling considerably.

David - since you seem to be VERY against Prototype is there a
different open source library that YOU opt to use, or do you just
"repeat yourself" every time you write a new Ajax app?

Why should he? I suppose he reuses his own library.

Maybe you
should develop a better prototype if you've got so many problems with
the existing one. *If you did that, I'd love to check it out and see
what improvements could be made.

Well, you could have a look at prototype.js and see what improvements
could be made there. If you think prototype is perfect (or at least
nearly perfect), then I doubt you can judge code quality.

Anyway, David has his library on the web. [1]

Gregor

[1]http://www.cinsoft.net/mylib.html

Yes, it has been there since last March. It is partially a result of
the "Code Worth Recommending" project. I think the XHR instantiation
is Peter's.

I haven't really touched the public site since then and I know there
are a few bugs (see posts the discussion group.) I plan to take some
time this fall to finish the documentation and test the latest
agents. Until then, it is not recommended for public use.

[Gregor Kofler]

David Mark meinte:

>[1]http://www.cinsoft.net/mylib.html

I haven't really touched the public site since then and I know there
are a few bugs (see posts the discussion group.) I plan to take some
time this fall to finish the documentation and test the latest
agents. Until then, it is not recommended for public use.

It's relatively hard to find (compared to jQuery and its comrades). But
since Matt asked so fervoursly for alternatives... (He also promised to
look into the code.)

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

[Matt]

Anyway, David has his library on the web. [1]

>
[1]http://www.cinsoft.net/mylib.html

I like a lot of the concepts mentioned...like the "Builder" for 1, so
you only get what you need. Very nice, like MooTools. Also, the
feature detection sounds good. What's the status of that project?
There a lot of broken links. If this project is something that is
being actively developed, I might have to abandon Prototype.

[David Mark]

On Aug 11, 4:43*pm, Matt <[e-mail]:

Anyway, David has his library on the web. [1]

[1]http://www.cinsoft.net/mylib.html

I like a lot of the concepts mentioned...like the "Builder" for 1, so
you only get what you need. *Very nice, like MooTools. *Also, the

Thanks. Modularity was one of the projects' aims.

feature detection sounds good. *What's the status of that project?

See my reply to Gregor.

There a lot of broken links. *If this project is something that is
being actively developed, I might have to abandon Prototype.

You should abandon Prototype anyway.

Also, Peter's "Fork JavaScript" is very good and AFAIK ready for
production use.

[David Mark]

On Aug 11, 4:43*pm, Matt <[e-mail]:
[snip]

There a lot of broken links. *If this project is something that is
being actively developed, I might have to abandon Prototype.

Those links were to the now defunct CWR project. I need to remove
them (among other things.)

[q-rious]

On Aug 11, 1:56*pm, David Mark <[e-mail]:

On Aug 11, 4:43*pm, Matt <[e-mail]:
[lots of discussion]

Okay folks, I am new to this and I did not understand all the things
that you guys discussed. I went back and read the 'same origin
policy'. If my understanding is correct, no one can ever fetch an XML
file from some other site and parse it using javascript (and
XMLHttpRequest). The only exceptions would be like 'signed scripts'
and activeX controls (both of which are beyond me at this point). I am
a bit surprised by the 'same origin policy' since I am sure someone
must have parsed some RSS feed from another site using Javascript
before me.

Looking for more help. Thanks.

[John G Harris]

On Mon, 11 Aug 2008 at 12:22:57, in comp.lang.javascript, Matt wrote:

>Can someone give some specific examples of these alleged "bugs" in
Prototype? I'm hearing a LOT of conjecture about Prototype being crap.

It takes half a minute for the js file to crawl down the wire before you
see anything useful in the web page. That's a bug.

John
--
John Harris