在上次的文章中,我们已经提到了一种能够跨子域名进行AJAX请求的方法。我们现在就来实现一个对开发人员透明的实现,它会自动判断这个请求是否是跨子域名,如果不是,则使用传统的方法发出AJAX请求,反之则使用我们的方式。
我在如何实现这个Executor的问题上,我想了很久。按照ASP.NET AJAX的“标准”来说,应该开发一个WebRequestExecutor的子类,然后将其设为默认的Executor或者某个特定WebRequest的Executor。但是最终我使用了直接修改XMLHttpExecutor的做法,因为考虑到以下原因:
-
完整实现一个WebRequestExecutor需要实现太多接口,而CrossSubDomainExecutor和XMLHttpExecutor有太多相同的地方。
-
如果继承WebRequestExecutor的话,还是需要了解XMLHttpExecutor的太多细节,JavaScript做不到太好的封装,无法实现真正的面向对象。
-
CrossSubDomainExecutor在普通情况下和XMLHttpExecutor的行为一模一样。
直接修改XMLHttpExecutor的做法其实就是在XMLHttpExecutor的prototype上做文章,这也就是JavaScript扩展对象的一贯做法。
首先,我们定义一个Sys.Net.WebRequest类的静态方法,用来从一个URL中获得域名。例如输入http://www.sample.com/Default.aspx这个URL,返回http://www.sample.com,这个静态函数对于判断是否Cross Domain非常重要,如下:
其次,我们为Sys.Net.WebRequest类扩展一个,用于检测请求能否直接发出,而不需要使用我们的方法。在这里我们直接使用了一个XMLHttpRequest对象作为尝试:
我们还需要得到WebRequest的两个特性:它的Document Domain(设为document.domain的值),以及它本身的域名(Raw Domain),我们依旧为Sys.Net.Request扩展方法:
我们要修改XMLHttpExecutor,最关键的一步就是要重新实现executeRequest方法。很显然,再这之前,我们需要保留原来的实现:
接下来,就需要实现一个跨子域名发出AJAX请求方法了。再这之前,需要对于XMLHttpExecute本身的实现有所了解。我们现在就对添加的方法进行简单的分析。
首先,自然是_crossDomainExecuteRequest方法。我们准备了两个字典:_iframeCache和_iframeLoaded,分别用于保存作为Proxy的iframe对象,以及表明iframe对象是否已经加载成功了(iframe加载也是异步的,也需要一定时间)。我们先模仿XMLHttpExecutor的实现,建立一个侦测是否超时的监听器;再使用该请求的Raw Domain作为key,经过下面判断的三个分支做出不同逻辑。它们是:
-
如果iframeCache中没有相应的iframe对象,则调用_createIFrame方法创建一个作为Proxy的iframe。
-
如果已经存在iframe对象,但是Proxy页面还没有加载完毕,则等待500毫秒后重新尝试着调用_crossDomainExecuteRequest方法。
-
如果Proxy已经加载成功了,并且用户没有调用abort方法,请求也没有过超时时间,则将document.domain设为正确值,并且调用Proxy页面里的方法发出AJAX请求。
createIFrame方法的作用就是创建一个新的作为Proxy的iframe对象,加载的内容即为我们准备的Proxy页面,请注意Proxy页面还带有QueryString,用于指定Proxy页面的document.domain。我们也会响应iframe对象的onload事件。很幸运,这个事件被IE和FireFox浏览器都实现了——毕竟FireFox原本就是向IE拿来的iframe,有何道理实现的不同呢?
在iframe加载成功时,onIFrameLoadHandler方法会被调用。在这个方法里,我们将会通过查看Proxy方法有没有被正确加载来判断iframe里的Proxy有没有被加载成功。如果没有加载成功,则清除iframeCache字典中相应的iframe对象,并直接结束WebRequest请求:清除检测超时的Timer,调用WebRequest对象的completed方法等等。如果加载成功了,则在iframeLoaded字典中标记这个iframe已经加载成功了,并且在该方法之后重新调用_crossDomainExecuteRequest方法——只要使用setTimeout再将时间设为0即可:
最后我们只要再提供一个作为Proxy的页面即可,我们必须把它放在每个子域名的根目录下——当然您也可以改进之前_createIFrame的代码,加载其他位置上的Proxy页面。Proxy页面的实现非常简单,只要模仿XMLHttpExecutor原有的executeRequest方法实现即可:
到目前为止,这个CrossDomainExecutor就实现好了,我们现在使用WebRequst时就可以把它的URL设为不同子域名下的资源。例如,我们在http://www.test.com里可以请求http://sub.test.com或http://sub0.sub1.test.com里的资源。而且,如果不做跨子域名的请求,XMLHttpExecutor的行为和之前不会有任何不同。
点击这里下载源码。