Question: XMLHttpRequest

Q

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.
 
M

Martin Honnen

q-rious said:
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.
 
Q

q-rious

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...
 
M

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.
 
D

David Mark

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.
 
M

Matt

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


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

q-rious

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.
 
D

David Mark

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.
 
D

David Mark

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?
 
G

Gregor Kofler

q-rious meinte:
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
 
M

Matt

q-rious meinte:


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.)



What hints?


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.


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...
 
D

David Mark

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.
 
G

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
 
M

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?
 
T

Thomas 'PointedEars' Lahn

Matt said:
s/famous/in\0/


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.
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
 
M

Matt

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

Thomas 'PointedEars' Lahn

Thomas said:
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
 
G

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
 
D

David Mark

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,968
Messages
2,570,153
Members
46,699
Latest member
AnneRosen

Latest Threads

Top