友好的开发框架-Asta4D（8）：Content Provider与Request Handler Chain

（本来觉得到上一节，作为User Guide的内容应该就是足够了，不过后来觉得这部分内容也补充进来更完整一些。。。）

 

前面曾经提到，在一个URL映射规则中，可以配置多个request handler，这些handler就构成了一个request handler chain，在解释chain的流动规则之前，我们需要先说明另外一个概念： Content Proiver。

 

1. Content Provider

 

Content Provider是框架用来描述一个负责写入Response的角色的接口。所有请求在经过处理后最终都必须映射到一个Content Provider上，而该Content Provider负责将应答结果写入HttpResponse接口返回给远程客户端。

 

Asta4D中有以下几种Content Provider：

• Asta4DPageProvider：将模板文件的渲染结果写入response的OutputStream
• BinaryDataProvider：将二进制流写入response的OutputStream
• HeaderInfoProvider： 将header信息写入response的header部分
• JsonDataProvider： 将数据以json的格式写入response的OutputStream
• RedirectTargetProvider：产生一个301或者302重定向
• SerialProvider：主要是框架内部使用，将多个Content Provider合并成一个

更进一步的，Content Provider分为可继续的与不可继续两类，除了HeaderInfoProiver以外，都是不可继续的Provider。可继续的意思是该Provider完成自己的写入动作后，response不会关闭，其他Provider仍然可以后继写入自己的内容，而不可继续的Provider意味着，它的写入动作完成后，response已经处于不可再写入状态，必须立即关闭。

 

2. Request Handler Chain

如果一个request handler的handle方法直接返回一个Content Provider，框架会立即调用Content Provider的produce方法完成写入，同时，框架会判断该Content Provider是否可继续，如果不可继续，则后续的request handler不会被调用，当前请求被视为已经响应完毕，框架会立即返回。如果得到的content provider是可继续的，那么在produce方法完成后，框架会继续调用后续的request handler，并重复同样的过程。

 

以前的示例代码中我们可以看到，request handler通常并不会直接返回一个content provider，这个时候，框架会将request handler的结果按照顺序调用预设的result transformer将结果变换成特定的content provider。变换过程是反复迭代的，框架会将变换的结果一遍又一遍的通过result transformer进行变换，直到得到一个可用的content provider实例为止。

 

这里的result transformer是框架内建的一组变换规则，严格的讲，并不支持客户定制。但事实上，forward和redirect的结果匹配，就是利用result transformer的反复迭代来实现的，所以，forward和redirect的声明可以看作是对result transformer的有限度的定制化。

下面来看一个反复迭代的例子：

        

       rules.addGlobalForward(TemplateNotFoundException.class, "/pagenotfound.html", 404);
        
        rules.add("/app/handler").attribute("authcheck")
             .handler(LoginHandler.class)
             .forward(LoginFailure.class, "/templates/error.html")
             .forward("/templates/success.html");

 

 

首先，我们假设LoginHandler返回了一个LoginFailure的结果，根据forward的声明，LoginFailure结果会被变换成新的结果：字符串"/templates/error.html"。然后，对这个值，框架会再次调用变换规则，根据内置的规则，一个字符串值会被变换成一个Asta4DPageProvider，至此，完成了从request handler result到template文件的变换过程。

 

接下来，看一个更有趣的例子，假如"/templates/error.html"文件不存在会怎么样？如果该文件不存在，则在上述的第二次变换时，即将"/templates/error.html"变换成Asta4DPageProvider时，会抛出TemplateNotFoundException，而这个异常，同样被视作"/templates/error.html"的变换结果，从而导致变换规则被再次迭代，这一次，我们发现了一个全局的forward声明，于是，根据这个声明，TemplateNotFoundException被变换成"/pagenotfound.html"，对于字符串值，再一次迭代，"/pagenotfound.html"最终被变换成一个Asta4DPageProvider，然后produce方法被调用，应答页面写入客户端。

 

 

 

最后，至本节止，对Asta4D框架的整体说明就全部结束了，接下来的内容，将会补充前面遗漏的一些细节并对某些内容做更深入的说明。