flXHR is a graceful solution on cross-domain comm. I've integrated it into dojo.js using the adaptDojo() method on demo #7.
I use an html file located in the same domain to test dojo.xhrGet() method. It works wonderfully.
By removing the adaptDojo() part from body onload, I can compare the response speed between original dojo.js and flXHR. I find the original dojo.js quite responsive. But after utilizing flXHR, there's some seconds delay.
I tried to set xmlResponseText to false, but the same delay.

The code is quite simple:

function doit() {
dojo.xhrGet({ url: "service.htm", load: handleLoading, error: handleError });
}
function handleLoading(responseObj, dojoObj) {
dojo.byId("content").innerHTML = responseObj;
}

Could somebody test this? I hope flXHR can be responsive too.
Thanks!

Baoshan Sheng

This same question was posted to the discussion group, and I responded there to the question being asked, which is why flXHR takes several more seconds to make a request/response cycle than native XHR.

The answer is in this thread: http://groups.google.com/group/flensed/ ... d6f51645b#

Next, I'm going to post here a suggested coding solution workaround which should help alleviate the initial instantiation delay that you are seeing. I'll post that here as soon as I get the code ready to go.

OK, so let me explain the code strategy I have to suggest for alleviating some of the pain (time delay) caused by the first flXHR instance instantiation.

Basically this idea is very similar in concept to image pre-loading from the old days of javascript. Instead of trying to pre-load a bunch of images and have them in the browser cache ready to get quickly when needed, what we'll do is have one or more flXHR instances sitting around (in memory, not in cache) ready for Dojo to call up and use immediately whenever it wants.

Taking advantage of the fact that flXHR will remember and keep on hand instances that have been previously used and are now idle, and were marked originally as "instancePooling:true", you can instantiate one (or more, if you need to make simultaneous/concurrent requests) flXHR instance(s) at the beginning of the page, and fire off basically a waste-away request (like an empty GET request, even one that may fail, like to a non-existent URL). Then, later in the page's lifetime, when you call a dojo xhr call, it will try to instantiate a new flXHR, but because a previous one is already created and sitting idle, the delay will be gone because it can just return that existing instance right away and move right to making the request!

If you only ever need to do one request at a time on your page, this is very simple. However, if the most simultaneous requests you ever need to make is 4, for instance, then it's a simple thing to extend this example to do the pre-instantiation 4 times (hint: for loop), and have 4 idle instances sitting around waiting to be used later by dojo.

Simple Example:


"throwaway" is just a temp variable to create a dummy flXHR request just to get it instantiated and ready to go. Then, later, when you call dojo.XhrGet(), it'll try to instantiate a new one, but flXHR will have an internal reference to this idle object and will just return a reference to it immediately, saving a lot of processing time by preventing unnecessary instantiation. The best part about the "instancePooling" feature is that it'll just keep recycling the same single instance over and over again, as more and more dojo Xhr calls are made. As long as each request fully completes, and makes the instance used but idle, the instancePooling will just pick up the same instance over and over again, so you'll not see the instantiation delays again.

Again, if you know you will need several objects sitting around ready to be used simultaneously (like if you will fire off requests to two different sources at the same time), then you just need to extend that example to pre-instantiate several flXHR instances and have them sitting around ready to use.

Simple Example (extended):


Hope this strategy and code samples help you get on a track to where you can alleviate your instantiation woes.


Note: Obviously, this pre-instantiation strategy stuff has to happen at some point (no way to completely avoid it), so if you are trying to use flXHR during the initial building of your page (during page load), then you'll still have the painful initial delay the first time, but subsequent requests should be much quicker.