Ok, you were definitely right about the problem being cross-domain issues with AJAX. No solution found on this board, but I got it to work myself, using flXHR, rather seamlessly I must say. Of course, performance is not what we're used to, but it works.
If flXHR is properly deployed (not hard, see flXHR documentation), the following changes to the above code worked for me.
1. Include the flXHR library by adding another script tag to the head.
<script type="text/javascript" src="path/to/flXHR.js"></script>
2. Add the following lines at the beginning of the Init() function body. Obviously, all other QV urls should be changed to start with http://YourQVServer/ as well.
adaptNative(); // integration with flXHR
Qva.QvAjaxZfcPath = "http://YourQVServer/QvAJAXZfc/";
Qva.Remote = "http://YourQVServer/QvAJAXZfc/QvsViewClient.aspx";
3. The adaptNative() function could be defined as follows.
// this function replaces the native XMLHttpRequest by the cross-domain flXHR variant
// adapted from http://flxhr.flensed.com/code/tests/flxhr-7f.html
function adaptNative() {
var configurationObject = {
instancePooling:true,autoUpdatePlayer:false,xmlResponseText:true,noCacheHeader:false,
//onerror:handleError, // if you want to use some error handling function handleError
loadPolicyURL:"http://YourQVServer/QvAJAXZfc/your_specific_policy.xml" // only required if you use a QV specific policy, see flXHR documentation
}
XMLHttpRequest = function() { return new flensed.flXHR(configurationObject); }
// IE only, for the IE specific XHR code instantiation
try {
if (window.ActiveXObject) {
var old_ActiveXObject = window.ActiveXObject;
window.ActiveXObject = function(typeStr) {
if (typeStr === "Microsoft.XMLHTTP") {
return new flensed.flXHR(configurationObject);
} else {
return new old_ActiveXObject(typeStr);
}
}
}
} catch (err) {}
}
There may still be other/better solutions (please reply if you know any), but I hope this will help other people as well.
Roeland
(Rotterdam, the Netherlands)
