Using Ajax.Request...

1 view
Skip to first unread message

darrin

unread,
Apr 25, 2008, 11:06:21 AM4/25/08
to crosscheck
Hello all -

I'm like crosscheck - but I have to say it's left me a bit wanting for
robustness in how it handles network simulation, Ajax.Requests and
xml. Ajax.Request is of course from prototype.js - so I figured it
would work like a charm... well almost...

Specifically I had some problems that I thought I'd share with
Ajax.Request. I was having problems in 3 areas and here's what I've
found on each:

1) Crosscheck wasn't parsing my response as XML - though the response
did in fact have an xml root node - ala "<xml version='1.0'
encoding='utf-8'>"...

Turns out that crosscheck uses the filename - expects that your url
need to end in ".xml" for it to properly populate responseXML. This
means that if you have any parameters your response will never be
interpreted as xml. There's no workaround other than to change the
url and the crosscheck.response to match and end in .xml.

In the long term I think this should be changed.. to look for "<xml "
in the response and maybe to see if the url _contains_ .xml or
something similar. I have downloaded the source and patched it to do
these two things... in ActiveXObject and Moz17XMLHttpRequest.

So if you want to do this in ActiveXObject search for ".xml" and
replace the if clause with this:

if ((url.contains(".xml")
|| response.getResponseText().contains("<xml "))
&& !(response instanceof FileSystemResponse)) {


2) Under InternetExplorer6 - I wasn't getting any response from
crosscheck at all...

Turns out that I was calling Ajax.Request synchronously... as soon as
I changed it to async it worked... I have no other fix for this and
don't really know what is going on here...


3) Handling malformed xml.

It turns out that in one case I had malformed xml. I actually didn't
realize this until I was running crosscheck in debug mode on the test
case in question. Crosscheck actually gets some good information
internally but doesn't share it with the user - even a stack trace
would be nice - something rather than failing silently on the
response. I've added a patch for this locally... but it's a bit
involved for me to share here.

If things are failing (you're not getting your xml response) its
probably a good idea to run your response through an online xml
validator to be sure your xml is well formed.

----------


Note that in the cases above - my code seems to work just fine when I
run it in the browser - so I'm guessing these are just nuances of how
crosshcheck is handling things... Just for reference... here's my
code:

new Ajax.Request(url, {
method: 'get',
asynchronous : async,
onComplete : function (transport) {
Qr.dbgDS.info("in onComplete");
},
onSuccess: function(transport) {
Qr.dbgDS.info("in onSuccess");
var xmlResponse = transport.responseXML ||
transport.responseText;
Qr.dbgDS.info("Received successful response for: '" +
this.lastURL + "' XML response was:\n" +
xmlResponse);
if (this.validResponse(xmlResponse)) {
Qr.dbgDS.info("Response validated for: " +
this.lastURL);
this.receiveXMLData(xmlResponse, onLoadComplete,
onNoDataMsg);
}

}.bind(this),
onFailure: function(t) {
Qr.dbgDS.info("Received failed response. " +
this.lastURL);
var msg = 'Error ' + t.status + ' -- ' + t.statusText;
this.error = {userMsg: msg, techMsg: msg, stacktrace:
"None available."};
this.onError(this, this.error);
}.bind(this)
});


A couple notes about the code:
1) Qr.dbgDS.info ends up getting mapped to crosscheck.print - so we
can see what is going on during my test run.
2) I'm obviously running this within an object... hence the bind to
this.
3) Using prototype version 1.5.1.1 - same as in the repo for
crosscheck just to be safe.

Best of luck,
-Darrin
Reply all
Reply to author
Forward
0 new messages