[spring对象名.方法名]这种映射方法比基于正则字符串匹配的方式要简单明确的多。spring容器本身已经实现了对象的全局管理功能，spring对象名称必然是唯一的，公开发布的，相互之间不冲突的，没有必要再通过匹配运算重新发现出它的唯一性。
   对于一些确实存在的横切需求，我们可以通过Annotation机制来实现切点坐标标定，将复杂的切点匹配问题重新划归为[对象名.方法名]。

针对以上对象，在app.aop.xml文件中可以定义

<I-myObject.I-myFunc>
   .
</I-myObject.I-myFunc>

以上这些需求往往是系统中最易变的部分, 而它们在概念上恰恰表现为对CRUD的一种限制性描述. 因此通过如下扩展我们可以定义BizFlow的概念: BizFlow = CRUD + Filter. 根据这种观念, witrix平台中BizFlow被实现为DaoWebAction的一种无缝扩展.
   在jsplet框架中我们通过如下url模式来访问后台的CRUD操作:
   /list.jsp?objectName=MyObj&objectEvent=Query
为了实现BizFlow只需通过spring为DaoWebAction配置一个xml配置文件, 此后仍然可以通过
    /list.jsp?objectName=MyObj&objectEvent=Query
来访问后台的CRUD操作,只是后台会自动应用配置文件中的 bizId="default", bizActionId="Query-default"等配置项.
如果我们采用如下url来访问
    /list.jsp?objectName=MyObj&objectEvent=Query&$bizId=test&$bizActionId=test   
则后台将应用配置项 bizId=manage, bizActionId=Query-test, 而
    /list.jsp?objectName=MyObj&objectEvent=BizAction&$bizId=test&$bizActionId=test   
则对应于配置项 bizId=manage, bizActionId=BizAction-test.
   应用BizFlow配置项之后,所有前台代码都可以不做出任何改变, 因为它们只是对于给定数据的展现.
  
   BizFlow可以看作是CRUD加上简单的流程控制和权限控制所构成, 但是它与完整的工作流模型还是有着显著区别的. 工作流中所关注的重点首先是流程实例而不是业务对象实例, 在一个流程中是否存在唯一的业务对象,以及业务对象的状态是否随着流程流转发生变化完全是一件独立的事情,它们并不属于抽象的工作流模型本身. 理论上说,一个业务对象可以同时参与多个流程. 在工作流建模中主要通过流程步骤的先后顺序的约束来描述业务进程, 处于同一状态的业务对象可能处在不同的流程步骤中. 而BizFlow可以看作是状态驱动的, 当前业务步骤直接由业务对象的状态决定. 在BizFlow中因为视角是业务对象的状态,因此我们直接面对的是大量处于同一状态的不同的业务处理过程, 而workflow中往往建模的时候强调单流程实例视角,而一般缺乏对于流程实例相关性的描述. 现在国内很多人认为工作流就是状态机其实是对workflow概念的一种误读.
 

html <--> tpl <--> java

注 意到这里html与tpl之间，以及tpl与java之间的映射都不是trivial的同构关系，而是都可能存在着复杂的运算过程，从而实现了html与 java映射过程中复杂性的分解与均摊。tpl与java之间的关联主要通过EL(expression language)表达式来完成，而html与tpl的映射则主要通过自定义标签(tag)机制。
注意到tpl所提供的中间层具有独立的重大意 义，它并不是臆造的或者是简单的技术驱动的结果。实际上，在web开发中除了java结构与html结构之外还存在着第三种结构，即用户眼中的界面结构， 本来它与html所描述的结构是简单的一一对应的，但是随着界面技术的发展，html的描述能力逐渐被耗尽，成为了internet时代的"汇编语言"。 现在一个简单的页面片断就可能对应着大量html代码，因而丧失了"所写即所见"的简单性。tpl通过强大的抽象能力在某种程度上恢复了程序员对于界面表 现结构的直观控制能力，并在一定程度上保留了html所见即所得的特性。

在witrix平台中因为存在着tpl这一强大的抽象层，使得我们对于ajax的支持可以采取更加灵活的方式。
ajax(Asynchronous JavaScript + XML)的标准结构是
html <--> js <==> xml <==> java

在 这种结构中通过xml信道的只是数据，而界面的表达逻辑与展现逻辑完全由js来控制。这种结构发展的一个极端是所有的界面展现结构都由 javascript动态构造出来，而完全丧失了html静态描述的特点,丧失了所见即所得的设计。与直接实现html<-->java之间 的映射情况类似，直接实现 html <--> js之间的映射也是困难的，尽管dom模型的支持可能使得js映射的难度要低于java映射。

在witrix平台中ajax的方案为
html <--> js <==> tpl <--> java

即tpl取代了ajax标准方案中xml的位置，使得映射过程的复杂性得以分散化。

结合jsplet框架的拉模式（pull mode)，我们定义了如下ajax访问接口
js.ajax.load({request='objectName=/@Test&objectEvent=query',tpl:'/test.tpl:partA',targetId:'testDiv'});

1。 远程服务请求就是一段普通的http post request， 避免了额外的xml编码解码需求。
2。请求到的数据先由tpl文件来进行处理。注意到这里tpl文件的url分成两部分，前一部分是tpl文件的虚拟路径，而 ：后面的部分，即partA指出请求的是该tpl文件内的partA部分，而不是整个tpl文件。
3。返回的html结果被填充到targetId所指定的html元素中。

test.tpl文件的内容
＜html＞
＜body＞

＜tpl:define id="partA"＞
＜img tpl:tag="ui:EditTable" /＞
＜/tpl:define＞

＜div id="testDiv"＞
＜img tpl:tag="ui:ViewTable" /＞
＜/div＞

＜/body＞
＜/html＞

FreeMarker是一种流 行的文本模板语言，其语法类似于xml tag，但是命名规则不同。这实在是一种令人费解的设计。有意思的是，我们发现tpl的功能集也包含了FreeMarker的功能集。这实际上表明了一件 事情，xml动态标签存在一些必然的功能需求，无论是jsp tag, FreeMarker还是tpl, 所不同的只是表现形式而已。但这种表现形式的差异却又造成了实际功能上的巨大差异。

tpl与FreeMarker具体对比如下。

宏定义
＜#macro greet person＞
＜font size="+2"＞Hello ${person}＜/font＞
＜/#macro＞]]＞

＜c:lib namespace="test"＞
＜greet demandArgs="person"＞
＜font size="+2"＞Hello ${person}＜/font＞
＜/greet＞
＜/c:lib＞

tpl具有更加强大的变量域控制手段，可以通过importVars参数来指定是否使用调用环境中的变量作为缺省参数。另一方面，tpl具有更加灵活的参数校验规则，可以通过demandArgs, otherArgs等参数来指定对自定义标签参数的校验规则。
调用宏
＜@greet person="Fred" /＞
＜test:greet person="Fred" /＞

嵌套内容
＜#macro border＞
＜table border="4" cellspacing="0" cellpadding="4"＞＜tr＞＜td＞
＜#nested＞
＜#nested＞
＜/tr＞＜/td＞＜/table＞
＜/#macro＞
＜c:lib namespace="test"＞
＜border type="bodyTag"＞
＜table border="4" cellspacing="0" cellpadding="4"＞＜tr＞＜td＞
＜cp:compile src="${tagBody}" /＞
＜/tr＞＜/td＞＜/table＞
＜/border＞
＜/c:lib＞

tpl的＜cp:compile＞指令在执行时可以指定xslt参数，从而在编译tagBody之前应用xslt变换。
复杂嵌套
与FreeMark一样,嵌套内容可以是复杂内容

＜@border＞
＜ul＞
＜@do_thrice＞
＜li＞＜@greet person="Joe"/＞
＜/@do_thrice＞
＜/ul＞
＜/@border＞
＜test:border＞
＜ul＞
＜test:do_thrice＞
＜li＞＜test:greet person="Joe" /＞＜/li＞
＜/test:do_thrice＞
＜/ul＞
＜/test:border＞

导入库
＜#import "/lib/my_test.ftl" as my＞
＜c:lib src="/lib/my_test.ftl" namespace="my" /＞

创建或替代变量
＜#assign mail="jsmith@other.com" /＞
＜c:set var="mail" value="jsmith@other.com" default="xx"/＞

判断
＜#if animals.python.price ＜ animals.elephant.price＞
Pythons are cheaper than elephants today.
＜/#if＞
＜c:if test="${lt(animals.python.price,animals.elephant.price)}"＞
Pythons are cheaper than elephants today.
＜/c:if＞

tpl因为是xml语法，算术操作符＜和＞必须转义后才能使用，使用起来很不方便，因而最终决定tpl不支持操作符，通过lt(), gt()等函数来实现功能。
循环
＜#list animals as being＞
＜tr＞＜td＞${being.name}＜td＞${being.price} Euros
＜/#list＞
＜c:forEach var="being" items="${animals}" ＞
＜tr＞＜td＞${being.name}＜td＞${being.price} Euros
＜/c:forEach＞

tpl提供＜c:tile＞等多种循环方式
include指令
＜#include "/copyright_footer.html"＞
＜c:include src="/copyright_footer.html" /＞

tpl强大的模板功能加上jsplet框架面向对象的能力，使得我们可以轻易的封装复杂的界面组件。而且这种封装能力还不需要Tapestry那种复杂的配置文件。tpl对portal应用的支持也是一个自然的发展过程。

（后来看到Bruce Eckel的文章Does Java need Checked Exception，发现大家在对待checked exception的态度上倒是心有戚戚焉。）

     一般使用自定义的异常类似乎是要将类名作为错误返回码使用，利用java编译器可以做所谓的强类型检查，这实在是一种概念上的浪费。毕竟创建并维护一个 java类还是有一定的代价的，特别是错误码经常变动而且数量不菲。实际上，java类库的设计中也是尽量重用已有的异常类，例如整个jdbc包只抛出 SQLException异常，xml包只抛出SAXException异常。

     使用异常，常见的方法是抛出一个字符串消息，例如 throw new MyException("the object manager does not contains the object :" + objectName);
这种做法的主要问题是，字符串异常消息无法进行进一步的处理，因而只能直接显示给最终用户，这一方面限制了错误显示的格式和方式，另一方面也不利于程序的多语言支持。
     witrix平台中抛出异常的标准方法为
 throw Exceptions.code(errorCode).param(paramValue).param(paramName,paramValue);
例如
    throw Exceptions.code("web.CAN_err_missing_object_in_manager").param(objectName).param(objectManager);

class Exceptions{
    public static CommonException code(String errorCode){
  return new CommonException(code);
 }
}

class CommonException extends RuntimeException{
 public CommonException param(Object paramValue){
  ...
  return this;
 }
}
      Exceptions规定只使用规范格式的错误码而不是任意格式的异常消息。这样在捕获异常之后，就可以根据错误码和当时的语言Locale设置来决定最终显示的消息格式。
      同时CommonException采用流式设计来支持任意数量的自定义参数。这一方面减少了自定义异常类的需求，另一方面也避免了将参数与错误码混合的倾向，即我们就不会倾向于
使用 throw Exceptions.code("the object manager does not contains the object :" + objectName);

注意到平面表结构只具有一个可延展的维度，而join可以看作是该维度上的连接操作。因此我们可以将交叉表看作是多个简单平面表结构并置的结果。即分解为
A:        
           productA
districtA   sellNum
districtB   sellNum

B:
           productB
districtA   sellNum
districtB   sellNum

横向维度的扩展在程序中表达。

SqlInfo结构封装了这种简单平面表的分解片断。
class SqlInfo{
    List fieldNames;
    SQL sql;
    String keyField;
}

我们在程序中通过JoinBuilder来实现横向维度的构造
JoinBuilder.begin(sqlInfoA)
           .join(sqlInfB)
           .leftJoin(sqlInfoC)
           .end();
生成的sql语句示例如下
select sqlInfoA.fieldNames, sqlInfoB.fieldNames
from sqlInfoA.sql join sqlInfoB.sql
on sqlInfoA.keyField = sqlInfoB.keyField

 public Object process(ITableVisitor visitor){
  Pager pager = new Pager(viewer, pageSize);
  Iterator it = pager.itemIterator();
  visitor.visitBegin(headers);
  while(it.hasNext()){
   Object row = it.next();
   if(!visitor.visitRow(row))
    break;
  }
  return visitor.visitEnd();
 }
}

interface ITableVisitor{
 void visitBegin(List headers);
 boolean visitRow(Object row);
 Object visitEnd();
}

Tree由三部分组成: 属性，值， 子节点

class TreeNode implements IVariant{
 List getChildren();

 int getChildCount();
 TreeNode child(int index);

 /** 当name对应的节点不存在时将会自动创建该节点 */
 TreeNode child(String name);

    /** 当name对应的节点不存在时返回null */
 TreeNode existingChild(String name);

 Map getAttributes();
 IVariant attribute(String name);
 void setAttribute(String name, Object attrValue);
}

TreeNode.attribute(name)返回的是IVariant接口，例如
boolean defaultValue = true;
boolean b = node.child("subA").attribute("attrB").booleanValue(defaultValue);

TreeNode本身也是IVariant接口的一个实现,例如
int i = ode.intValue();

2. 抽象能力
   获得抽象能力，首要的一点是使得创建新概念的成本极低。很少有人大量开发jsp tag，原因就是开发tag过于麻烦，而且调整不方便。另外开发出的tag如果粒度太小，大量使用的时候是对性能的致命伤害。
   tpl首先需要经过编译，而不是象jsp tag那样完全动态运行，而且tpl编译出的结果是无状态的，因此解决了性能上的问题。
   在tpl中导入外部模板的语法非常简单，可以实现基本的分解
    <c:include src="xxx.tpl" />
   更重要的是，tpl中定义了完善的库机制。
使用库
    <!-- 导入外部包, 导入时指定名字空间为demo。
         注意tpl中并没有完整的名字空间支持，只能作为qName使用
    -->
    <c:lib src="demo_lib.xml" namespace="demo" />

 <!-- 对具有cache:timeout属性的节点应用cache修饰，即该节点的运行内容被缓存 -->
 <c:decorator type="cache" match="//@[cache:timeout]" />

    <div id="blockA">
        <p>通过tpl:tag属性可以设定宿主标签的真实标签名。这种做法可以方便可视化设计：</p>
        <input tpl:tag="demo:文本框" value="in block A" otherValue="${varInJsp}" onclick="clickOnBtn()"/>
    </div>

    <div id="blockB">       
       <p>分页表格:</p>
        <img tpl:tag="demo:分页表格" headers="fieldA,fieldB" pager="${pager}" />
    </div>

    <div id="blockC">
      <p>bodyTag标签的调用:</p>
        <demo:循环data>
            <input type="text" value="${row}" /> <br/>
        </demo:循环data>
    </div>

    <div id="blockD" cache:timeout="1000s" >
        <p>条件标签的调用:</p>
        <demo:当Num足够大>
            <p>当 thisObj中的变量 'num' 的值大于3的时候显示这句话 </p>
        </demo:当Num足够大>
    </div>

定义库文件demo_lib.xml
<!--
     自定义标签的属性：
  type: simpleTag, bodyTag 或者 conditionTag, 缺省为simpleTag
  importVars : 每个自定义标签具有自己的变量空间，需要通过importVars来明确指定从外部变量空间中导入的变量。
  demandArgs: 调用时必须明确给出这些参数的值
  otherArgs: 如果指定了该参数，则调用自定义标签时能够使用的参数就必须在demandArgs和otherArgs指定的范围之内。
-->
<demo>
    <!-- 一个简单的tag示例， 直接输出变量。这里demandArgs指定调用时必须提供的变量。 -->
 <文本框 demandArgs="value" otherArgs="otherValue,onclick" type="simpleTag" >
  <p> -----------------------------------  </p>
     <!-- 可以使用调用时提供的其他变量，如otherValue-->
  <input size="40" type="text" value="${value} * ${otherValue}" onclick="${onclick}"/>
  <p> -----------------------------------</p>
 </文本框>

    <!-- 一个自动分页表格，要求传入headers(List类型)指定表头，pager(Pager类型)提供数据 -->
 <分页表格 demandArgs="headers,pager">
     <!-- 从外部导入tpl文件 -->
  <c:include src="flex_table.tpl" />
 </分页表格>

 <!-- 一个bodyTag示例: 循环处理thisObj中的变量data中的每一行。
      importVars从调用环境中自动导入变量而不需要通过调用参数直接指定。
      当然如果调用参数中指定的变量与importVars中指定的变量重复，则调用参数会覆盖importVars.
    -->
 <循环data importVars="thisObj" type="bodyTag">
  <c:forEach var="row" items="${data}">
   <!-- tagBody为调用时标签的内容 -->
   <cp:compile src="${tagBody}" />
  </c:forEach>
 </循环data>

 <!-- 一个条件标签的示例.
      条件标签一般不应该输出文本，而是返回一个bool值。仅当返回true的时候，调用时标签的内容才会被运行。
 -->
 <当Num足够大 importVars="thisObj" type="conditionTag">
  <l:gt name="num" value="3" />
 </当Num足够大>
</demo>

注 意到bodyTag和conditionTag使得我们可以将循环（容器）逻辑和判断逻辑抽象成有意义的概念，而不再是一些执行的指令。这种抽象能力的应 用非常依赖于xml的自描述特性，我们不需要付出太大的努力，就可以在lib中封装出一个有意义的概念来! 而且tag的参数可以指定，可以缺省，存在多种选择，也对应着多种逻辑模型。
通过<c:decorator>的用法可以看到，因为xml明确定义了结构，使得我们可以轻易的实施类似AOP的功能。

3. 集成能力
   首先，tpl完全符合xml规范，与xml世界接轨，可以自由的使用xslt。例如，在
   任何标签中都可以指定tpl:xdecorator属性, tpl在编译之前首先会应用指定的xslt文件进行变换，对变换后的结果再进行编译。
   <anyTagName tpl:xdecorator="some_xslt.xslt">
  ...
   </anyTagName>
   其次，tpl可以使用属性标记，即tpl标签不仅仅可以通过标签名来标识，而且可以通过tpl:tag属性来标识。例如:
   <input tpl:decorator="demo:文本框" />
   与 <demo:文本框 />等效。
   这种做法避免了tpl侵入html模型，使得我们可以利用现有工具对tpl进行所见即所得(WISIWIG)的设计。

   再次, 在tpl中使用EL(Expression Language)语言，集成java数据模型。

   第四, 在tpl中可以采用如下方式实现强类型化，完成与java的接口。
   interface ITest{
     void test(String name, int value);
   }

   <o:class name="MyClass" implements="ITest">
    <test args="name,value" >
   ...
    </test>
   </o:class>
   这种能力可以在数据源的filter中使用。

我 本人从未应用过Model2模式，但与我们的jsplet框架对比，我认为这种推送方式在大多数情况下并不是什么优点。如果将一次web访问看作是一次函 数调用，则按照Model2模式，这个函数的返回情况是不确定的，需要由一个额外的配置文件来确定。而我们知道，一个返回情况不确定的函数一般不是什么良 好的设计。在我们的框架设计中，一个基本的观点是尽量将自由度暴露给实际控制它的人。实际上，在大多数情况下，页面编制人员知道应该使用哪个页面来显示数 据，他们并不需要一个额外的配置文件。Jsplet使用如下的url格式:
       视图jsp?objectName=模型对象名&objectEvent=响应事件名&其他参数
举一个具体的例子:
   http://my.com/demo_view.jsp?objectName=/@Demo&objectEvent=test

demo_view.jsp是指定的显示页面, 其代码如下:
[code]
<%@ include file = "/engine.jsp" %>
<!-- 相当于在jsp模型中增加了一个新的变量thisObj，从而实现jsp页面的对象化 -->
<c:out>${thisObj.testVar}</c:out>
[/code]
objectName被WebEngine映射到session中的一个对象，在demo_view.jsp中成为thisObj这个变量，这就相当于java语言中的this指针，从而实现了jsp页面的对象化。

WebEngine还将objectEvent映射到一个Action响应函数并自动调用它，具体的Action代码写在一个独立的java文件或者jsp文件中。
DemoAction.jsp
[code]
<%@ include file = "/jsp_action_begin.jsp" %>
<%!
    //
 // objectName映射为thisObj, objectEvent=test映射对actTest的调用
 // 在这里增加一个actXXX函数之后，即可通过objectEvent=XXX来访问，不需要任何配置
    public Object actTest(){
  // thisObj中的变量可以在视图中使用
  thisObj.set("testVar","hello");
  return success();
 }

 // 如果存在actBeforeAction函数，则该函数在所有action函数之前调用
 public Object actBeforeAction(){
  return success();
 }

 // 如果存在actAfterAction函数，则该函数在所有action函数之后调用
 public Object actAfterAction(){
  return success();
 }
%>
<%@ include file="/jsp_action_end.jsp" %>
[/code]

在Jsplet框架中只需要注册对象，而不需要单独注册每个action。
register.jsp
[code]
<%
    WebEngine.registerType("Demo", new WebActionType("/demo/action/DemoAction.jsp"),pageContext);
%>
[/code]

与Jsplet 框架对比，Model2是对action的建模而不是对object的建模，即它相当于将objectName,objectEvent和 view.jsp绑定在一起定义为一个访问点action.do,绑定过程中需要一个配置文件来固化view.jsp和action之间的联系。因此, Model2并没有完全分离view和model，它隐含假定着objectName只具有一个objectEvent, 并且绑定了一个具体的view(出错页面除外)。
例如, 我们需要两个不同的view来显示同一个数据，则在Model2程序中可能需要配置两个独立的访问点，而在我们的框架中只需要使用两个不同的url:
a_view.jsp?objectName=/@Demo&objectEvent=test
b_view.jsp?objectName=/@Demo&objectEvent=test
同样的web程序甚至可以在前台通过XMLHTTP方式来调用而不需要额外配置!

在Jsplet框架中采用的是对象化的方式而不是Action化的方式，因此存在着多种面向对象的扩展,而所有的扩展都直接体现在url格式的细化上，一切都在阳光下。
  在Jsplet中objectName是WebObject的名称，在全系统内唯一，其格式定义为: objectScope@objectType$objectInstanceId
1. 对象类型objectType
  我们需要注册的是对象类型而不是完整的对象名，一个对象类型可以对应于无数个完整的对象名，例如我们注册了Demo类型的WebObject, 则objectName=/@Demo和objectName=/left/@Demo对应的处理文件都是DemoAction.jsp。
2. 对象生命周期控制objectScope
  objectScope为WebObject所在的域，其格式符合Unix路径命名规范。JSP模型本身支持一些预定义的对象域，包括page, request, session, application等。但为了能够反映现实世界中的对象组织结构，对象域必须是允许自定义的。objectScope被组织成一个树形结构，这是一个 基本的控制结构，其控制策略为
     同时存在的对象域之间必须存在线性序关系(order)
  当系统访问某一对象时，如果该对象所在的对象域不能和现有对象的域处在同一"路径"下(即当对象域之间不能建立父子关系时)，系统就会自动销毁不兼容路径 分支下的所有对象。 这种精细的控制策略保证了系统的可扩展性，因为模型上可以保证始终只有一部分对象被创建。
对象转移                                                           系统动作 
/main/@MyObject ==> /main/left/@OtherObject                       无
/main/left/@OtherObject ==> /main/@MyObject                       无
/main/left/@OtherObject ==> /main/left/@MyObject                  无
/main/left/@OtherObject ==> /main/right/@MyObject                自动销毁/main/left子域下的对象，如/main/left/@OtherObject
 
3. 对象实例标识 objectInstanceId
 如果在某一对象域中需要包含多个同一类型的对象，可以通过objectInstanceId来加以区分，这样在同一个页面上我们可以使用多个同样类型的对象。

Jsplet中另外一个扩展是通过事件路由来支持jsp子页面的对象化。例如
http://my.com/demo_main.jsp?objectName=/@Main&eventTarget=/@Sub&objectEvent=test
如果指定了eventTarget参数，则objectEvent由eventTarget对应的对象来响应。
在jsp文件内部我们可以通过include语法来引入子对象，例如
   <jsp:include page="sub_view.jsp?objectName=/@Sub" />
（注：我不是非常清楚Tapestry具体是如何实现对象化的，熟悉Tapestry的朋友可以介绍一下）

在Jsplet中可以通过配置文件来支持对Action的interception, 例如
[code]
<factory>
<listener-filter  class="global.LogFilter" />
<post-listener class="global.CommonActions"/>

<type name="Demo">
 <!-- 如果未指定object, 则缺省为WebObject类型 -->
 <object class="demo.MyWebObject" />
 <listener>
  <filter event="query*|select*" class="demo.LogFilter" />
  <url-listener url="/demo/DemoAction.jsp" />
  <url-listener url="/demo/DemoAction2.jsp" />
 </listener>
</type>

</factory>
[/code]
在上面这个配置文件中，DemoAction.jsp和DemoAction2.jsp是chain关系，即事件响应的传播模型中，如果event没有被标记为stopPropagation,就会传递到下一个listener。

综上所述，可以看到在目前多变的需求环境下，Model 2已不是一种非常完善的Web程序模式，一些重要的设计需求在Model 2模式的推方式中很难得到合适的表达。