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.XMLHttp Request) {
req = new XMLHttpRequest( );
req.onreadystat echange = processReqChang e;
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]

Re: Question: XMLHttpRequest

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]

Re: Question: XMLHttpRequest

On Aug 10, 10:06 am, Martin Honnen <mahotr...@yaho o.dewrote:

>
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]

Re: Question: XMLHttpRequest

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 <mit...@juno.co mwrote:

On Aug 10, 10:06 am, Martin Honnen <mahotr...@yaho o.dewrote:
>
>
>

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]

Re: Question: XMLHttpRequest

On Aug 10, 9:43 pm, Matt <mattj.morri... @gmail.comwrote :

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]

Re: Question: XMLHttpRequest

On Aug 10, 9:46 pm, David Mark <dmark.cins...@ gmail.comwrote:

On Aug 10, 9:43 pm, Matt <mattj.morri... @gmail.comwrote :
>

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]

Re: Question: XMLHttpRequest

On Aug 10, 6:43 pm, Matt <mattj.morri... @gmail.comwrote :

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]

Re: Question: XMLHttpRequest

On Aug 10, 11:15 pm, Matt <mattj.morri... @gmail.comwrote :

On Aug 10, 9:46 pm, David Mark <dmark.cins...@ gmail.comwrote:
>

On Aug 10, 9:43 pm, Matt <mattj.morri... @gmail.comwrote :

>

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]

Re: Question: XMLHttpRequest

On Aug 11, 1:42 am, q-rious <mit...@juno.co mwrote:

On Aug 10, 6:43 pm, Matt <mattj.morri... @gmail.comwrote :
>

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]

Re: Question: XMLHttpRequest

q-rious meinte:

On Aug 10, 6:43 pm, Matt <mattj.morri... @gmail.comwrote :

>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-"applicatio ns" 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]

Re: Question: XMLHttpRequest

On Aug 11, 2:36 am, Gregor Kofler <use...@gregork ofler.atwrote:

q-rious meinte:
>

On Aug 10, 6:43 pm, Matt <mattj.morri... @gmail.comwrote :

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-"applicatio ns" 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.gregorkof ler.at::: Landschafts- und Reisefotografie http://web.gregorkofle r.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"...y ou 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]

Re: Question: XMLHttpRequest

On Aug 11, 3:55 am, Matt <mattj.morri... @gmail.comwrote :

On Aug 11, 2:36 am, Gregor Kofler <use...@gregork ofler.atwrote:
>
>
>

q-rious meinte:

>

On Aug 10, 6:43 pm, Matt <mattj.morri... @gmail.comwrote :
>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-"applicatio ns" 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.gregorkof ler.at:::Landsc hafts- und Reisefotografie http://web.gregorkofle r.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"...y ou 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]

Re: Question: XMLHttpRequest

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(myPara meters);

- 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"...y ou 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]

Re: Question: XMLHttpRequest

(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(myPara meters);

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.Periodical Updater. 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....whi ch 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]

Re: Question: XMLHttpRequest

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(myPara meters);

>
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.Periodical Updater.

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....whi ch 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, <f806at$ail$1$8 300dec7@news.de mon.co.uk>