《案例精解企业级网络构建》赠书活动开始啦！　最新活动：“Web安全大家谈”有奖征文

深入Atlas系列：客户端网络访问基础结构示例（1） - 编写并使用自定义的WebRequestExecutor

2006-10-30 03:05:20

　标签：客户端 Atlas WebRequestExecutor　　　[推送到技术圈]

　　 WebRequestExecutor是ASP.NET AJAX网络访问基础结构的唯一修改点。理论上，我们可以使用自定义的WebRequestExecutor来取代默认的 XMLHttpExecutor。我们要做的，其实只是开发一个继承于Sys.Net.WebRequestExecutor类。不过事实上，在实际使用中，Sys.Net.XMLHttpExecutor已经足够用了，真的要自定义，也只需继承这个类即可。就像接下去的例子一样。

　　可是，Sys.Net.XMLHttpExecutor作为一个父类来说，可以说相当的不友好。先不多说，我们开始吧。在这个例子中，我们将开发一个 TraceExecutor，如果使用了这个Executor，Request和Response的信息都会被打印在页面上，开发人员可以把这些内容作为一个参考。TraceExecutor非常简单，代码也很短。

　　首先，是构造函数代码。如下：

Jeffz.Net.TraceExecutor = function Jeffz$Net$TraceExecutor()
{
    Jeffz.Net.TraceExecutor.initializeBase(this);
}

　　一般情况下，在这个方法中，会初始化所有的“私有”变量。不过在这里，我们不需要。

　　然后，我们将覆盖XMLHttpExecutor的executeRequest方法，我们需要作的，就是将WebRequest对象打印在页面上。代码如下：

function Jeffz$Net$TraceExecutor$executeRequest()
{
    debug.trace("<b>Request sent at " + new Date() + ":</b>");
    debug.dump(this.get_webRequest(), "Request");
    
    Jeffz.Net.TraceExecutor.callBaseMethod(this, "executeRequest");
}

　　我在这里使用Debug模式下，为方法起了一个“别名”，在prototype中需要使用一下。自然，我们也需要调用registerClass，表示类的继承关系。代码如下：

Jeffz.Net.TraceExecutor.prototype = 
{
    executeRequest : Jeffz$Net$TraceExecutor$executeRequest
}
Jeffz.Net.TraceExecutor.registerClass('Jeffz.Net.TraceExecutor', Sys.Net.XMLHttpExecutor);

　　等一下，为什么我们就覆盖executeRequest这一个方法呢？很显然，我们只是打印出了Request的信息，那么Response呢？我们是不是还需要再覆盖另一个方法呢？

　　我们的确应该再写一些代码，用来将Response信息打印出来，但是我们的做法不是覆盖XMLHttpExecutor的另一个方法，原因有两点：

XMLHttpExecute作为一个父类，相当地不友好。可以从代码里看到，它用来相应XMLHttpRequest对象 onreadystatechanged的回调函数“_onReadyStateChanged”是定义在其构造函数内。也就是说，它又使用了 Closure，而不是prototype。这样我们事实上就无法覆盖那些方法了，如果要继续在TraceExecutor上面做文章的话，我们必须写大量的代码，这几乎就相当于重新写了一个WebRequestExecutor。为什么会出现这种情况？是XMLHttpExecutor故意写成这个样的吗？我们来看一下：在XMLHttpRequest代码的executeRequest方法中，设置XMLHttpRequest对象 onreadystatechanged的代码是：“this._xmlHttpRequest.onreadystatechanged = this._onReadyStateChanged”，然后在_onReayStateChanged方法中使用了保留在Closure之中的 “_this”变量。这个是没有“Function.createDelegate”时，或者在使用Closure时的写法，编写过Windows Live Gadget的朋友们可以回忆一下，在使用官方提供的模版时，是不是在一开始也保留了一个“m_this”变量？这是相似的原因。那么在 XMLHttpExecutor里，为什么不使用“Function.createDelegate”方法？估计只有负责这部分代码的开发人员才知道了。因此，我认为这里部分使用了Closure不是故意所为，这更像是负责这段代码的开发人员一时“神志错乱”。
即使我们覆盖了“_onReadyStateChanged”方法，我们还漏了一些别的。如果这个Request超时了呢？如果这个Request被abort了呢？如果我们一一覆盖这些方法的话，似乎也有些太麻烦了。

　　因为上面两个原因（主要是第一个），我们将响应Sys.Net.WebRequestManager.completeRequest事件，在这个事件被触发时打印Response的信息。代码如下：

Jeffz.Net.TraceExecutor.traceResponse = function Jeffz$Net$TraceExecutor$traceResponse(response)
{
    debug.trace("<b>Response received at " + new Date() + ":</b>");
    debug.dump(response, "Response");
}
Sys.Net.WebRequestManager.add_completedRequest(Jeffz.Net.TraceExecutor.traceResponse);

　　我们可以尝试着使用一下，代码很简单，将HTML和Javascript一并贴出了。代码如下：

<asp:ScriptManager runat="server" ID="ScriptManager1">
    <Scripts>
        <asp:ScriptReference Path="Debug.js" />
        <asp:ScriptReference Path="TraceExecutor.js" />
    </Scripts>
</asp:ScriptManager>

<asp:UpdatePanel runat="server" ID="UpdatePanel1">
    <Triggers>
        <asp:AsyncPostBackTrigger ControlID="btnRefresh" />
    </Triggers>
    <ContentTemplate>
        <%= DateTime.Now.ToString("r") %>
    </ContentTemplate>
</asp:UpdatePanel>

<asp:Button runat="server" ID="btnRefresh" Text="Refresh"/>

<script language="javascript">
    Sys.Net.WebRequestManager.set_defaultExecutorType("Jeffz.Net.TraceExecutor");
</script>

　　在这里，需要使用我在《为ASP.NET AJAX 1.0 Beta补充trace和dump功能》里提到的Debug.js来补充ASP.NET AJAX中缺少的trace和dump功能。在代码的最后会使用Javascript将默认的WebRequestExecutor设为Jeffz.Net.TraceExecutor。

　　打开页面，点击Refresh按钮，嗯？Request信息不错，不过Response信息为什么只是这些？

Response {Jeffz.Net.TraceExecutor}
+_webRequest {Sys.Net.WebRequest}
+_resultObject: null
+_xmlHttpRequest {Object}
+_responseAvailable: true
+_timedOut: false
+_timer: null
+_aborted: false
+_started: true

　　原因在于，由于缺少了了Type Descriptor，debug.dump方法只会将该对象上附属的“值”（例如：this._started）打印出来，而不会调用任何方法。而在 XMLHttpExecutor中，许许多多方法（各种属性的get方法）是直接将消息委托给XMLHttpRequest对象，而不是将信息保留在 XMLHttpExecutor附属“值”上，因此，我们得到的只能是这些无用的信息了。

　　那么我们该怎么做？那么就为Response对象补充一个Type Descriptor。这里的Response对象其实就是Jeffz.Net.TraceExecutor类的实例，因此我们需要为该类添加一个Type Descriptor。代码如下：

Jeffz.Net.TraceExecutor.descriptor =
{
    properties:
    [
        {name: 'started', type: Boolean },
        {name: 'timedOut', type: Boolean },
        {name: 'aborted', type: Boolean },
        {name: 'responseAvailable', type: Boolean },
        {name: 'responseData', type: String },
        {name: 'statusCode', type: Number },
        {name: 'statusText', type: String }
    ]
}

　　这是RTM中Type Descriptor的表示方式。可以发现我在这里只添加了部分，而不是全部的属性。例如缺少了object属性，为什么呢？在XMLHttpExecutor中get_object方法是这样定义的：

function Sys$Net$WebRequestExecutor$get_object() {
    /// <value></value>
    if (arguments.length !== 0) throw Error.parameterCount();

    if (!this._resultObject) {
        this._resultObject = Sys.Serialization.JavaScriptSerializer.deserialize(this.get_responseData());
    }

    return this._resultObject;
}

　　我们可以发现，这段逻辑并没有判断responseData的合法性，如果它不是一个正确的JSON字符串，就会抛出异常。如果一定要在 Type Descriptor中定义object属性的话，那么我们还必须在TraceExecutor中覆盖XMLHttpRequest的object属性。作为一个没有多少使用价值的演示，我们就不作得如此“仁至义尽”了。:)

　　现在我们再来看一下打印出来的内容：

　　点击这里下载示例代码。

本文出自 “赵劼” 博客，转载请与作者联系！

上一篇深入Atlas系列：Web Sevices Access in Atlas..　　下一篇 ASP.NET AJAX - Q & A专用文章

类别：深入Atlas系列 ┆ 技术圈() ┆ 阅读() ┆ 评论() ┆推送到技术圈 ┆返回首页

相关文章

文章评论

昵称：
验证码：		点击图片可刷新验证码　　博客过2级，无需填写验证码
内容：