挣脱浏览器的束缚(7)

在上次的文章中,我们已经提到了一种能够跨子域名进行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._getRawDomain静态方法

Sys.Net.WebRequest._getRawDomain = function(url)
{
  url = Sys.Net.WebRequest._resolveUrl(url);

  var index = url.indexOf('://');
  var prefix = url.substring(0, index + 3);

  var url = url.substring(index + 3);
  index = url.indexOf('/');
  if (index < 0)
  {
    index = url.indexOf('?');
  }

  if (index >= 0)
  {
    url = url.substring(0, index);
  }

  return prefix + url;
}

其次,我们为Sys.Net.WebRequest类扩展一个,用于检测请求能否直接发出,而不需要使用我们的方法。在这里我们直接使用了一个XMLHttpRequest对象作为尝试:

Sys.Net.WebRequest._checkIfIsCrossDomainRequest方法

Sys.Net.WebRequest.prototype._checkIfIsCrossDomainRequest = function()
{
  var request = new XMLHttpRequest();
  try
  {
    request.open('get', this.get_url());
    return false;
  }
  catch(e)
  {
    return true;
  }
}

时间: 2024-08-02 09:31:00

挣脱浏览器的束缚(7)的相关文章

挣脱浏览器的束缚(6)

标题有些唬人的成分,因为这里跨的只是子域名. 事情的经过是这样的,还是那个个人门户网站.其中有个功能就是RSS订阅,每个订阅作为一个模块出现在页面上.如果一个用户订阅了比较多的RSS,则在打开页面时所有的RSS模块就会开始加载,这时候可能就会需要十几秒甚至更长的时间才能加载完毕.这时,如果用户需要作别的AJAX操作--比如保存页面设置--那么长时间的等待就不可避免了,谁让浏览器对于相同域名只能同时存在两个连接呢?不过这可不是一个好的用户体验,那么我们需要怎么做呢? 第一种做法可能比较容易想到,我

挣脱浏览器的束缚(5)

还记得<ASP.NET AJAX Under the Hood Secrets>吗?这是我在自己的Blog上推荐过的唯一一篇文章(不过更可能是一时兴起).在这片文章里,Omar Al Zabir提出了他在使用ASP.NET AJAX中的一些经验.其中提到的一点就是:Browsers do not respond when more than two calls are in queue.简单的说,就是在IE中,如果同时建立了超过2两个连接在"连接状态"中,但是没有连接成功(

挣脱浏览器的束缚(4)

我们已经知道,脚本文件的并行下载能够提高页面的加载速度.但是目前还有一个急需解决的问题,那就是对于FireFox浏览器的优化.在我们之前使用的优化方法,无论是简单实用的document.write还是食之无味的defer属性,FireFox浏览器都对此置若罔闻.不过FireFox也不是绝对地"冥顽不灵",开发人员还是有方法对它进行优化的. 这个方法就是动态添加script元素. 动态添加script元素 不知道"动态添加script元素"这个说法是否正确,我在这里的

挣脱浏览器的束缚(3)

在讨论这次的主题之前,我们现在看一下脚本优化的另一个问题,就是"优化难度".在这里我所说的"优化难度"是指优化一张页面时的修改难度.例如在前一片文章中,使用document.write来引入脚本的话,其"优化难度"会非常的低--没有任何副作用,不用修改其它任何代码.不过它的效果似乎还不太理想,因为仅仅优化了IE下的体验,在FireFox里却没有任何作用. 很可惜,我回想了几乎所有的优化方式,再也没有找到优化难度如此低的做法了.对于其它的方式,我们

挣脱浏览器的束缚(1)

最近在为某个人门户站点作优化. 从传统意义上来说,这个站点的各方面都属中规中矩.不过作为一个以客户端为中心的Web应用,其性能,尤其是它的感知性能(Perceived Performance),经常会严重受制于浏览器本身.一个没有对客户端数据访问模型经过精心设计和优化的应用,其导致的结果往往就是无法充分利用带宽,让用户等待的时间变长.换句话说,其Perceived Performance需要进一步的提高. 突破浏览器限制,充分利用带宽,提高性能,尤其是Perceived Performance等

挣脱浏览器的束缚(2)

现在哪里还找得到不引入JavaScript脚本文件的Web应用?使用脚本文件的好处多多,其中最重要的可能就是提供缓存能力了.使用脚本文件之后再加上缓存,可以大大降低数据传输量,提高页面打开的速度.不过脚本文件的引入也不是简单得不值一提,我们完全有能力来优化它. 小心传统的脚本引入方式带来的性能问题 现在的Web应用所需的脚本越来越多,一张页面下载几百K的脚本也不再是难以想象的事情了,这就直接导致页面需要更长的时间来加载脚本.不过传统的脚本引入方式(使用<script />)会造成什么问题?再查

挣脱创新的束缚&amp;#8211;由TRIZ理论,解析创新的来源和方法

在生活和工作中,我们经常会锁定一个焦点词汇"创新" 时常听到大家议论创新的重要性,要如何去创新.为了创新我们在设计过程中同样挖空心思的去头脑风暴,思考着如何得到更炫.更酷更意想不到的设计方案,从而达到创新的目的.与此同时我们也感觉到这样的创新更多的依赖于个人的灵感,灵感闪现则点子排山倒海,一发不可收拾,灵感消失则黯然失色,苦思不得其解. 于是我们发掘创新无迹可寻-于是我们被反复的催眠,觉得创新只需要灵感,我们在焦灼中期待灵感的闪现-- 当我数到3,请大家随着我,一起醒过来. 1.2.3

挣脱创新的束缚–由TRIZ理论,解析创新的来源和方法

在生活和工作中,我们经常会锁定一个焦点词汇"创新" 时常听到大家议论创新的重要性,要如何去创新.为了创新我们在设计过程中同样挖空心思的去头脑风暴,思考着如何得到更炫.更酷更意想不到的设计方案,从而达到创新的目的.与此同时我们也感觉到这样的创新更多的依赖于个人的灵感,灵感闪现则点子排山倒海,一发不可收拾,灵感消失则黯然失色,苦思不得其解. 于是我们发掘创新无迹可寻-于是我们被反复的催眠,觉得创新只需要灵感,我们在焦灼中期待灵感的闪现-- 当我数到3,请大家随着我,一起醒过来. 1.2.3

Andorid-15k+的面试题。

andorid开发也做了3年有余了,也面试很多加企业,借此机会分享一下,我们中遇到过的问题以及解决方案吧,希望能够对正在找工作的andoird程序员有一定的帮助. 特别献上整理过的50道面试题目 1.listView的优化方式 重用convertView viewHolder static class viewHolder 在列表里面有图片的情况下,监听滑动不加载图片 多个不同布局,可以创建不同的viewHolder和convertView进行重用 2.listView展示数据几种形式 从sql