[导入]jsplet与webwork的概念对比

jsp本身提供的是一个有限状态机模型(FSM)，Web访问模型直接体现了这一点: action?XXXX。
action对应于方法名，XXX是方法的参数。在这个访问模型中没有指出状态存储在什么地方，因为它假设后台是一个整体，构成一个巨大的状态集。
但 这种模型注定是过分简化的，所以会有很多的发展。发展的方向就是逐渐精细化，识别出相关的部分，把它们组织到一起。其实可以从各个框架的开发过程来看出这 种演化的过程。 Struts最早只有一个全局配置文件，现在多了一个模块的概念。WebWork是在Struts之后设计的，提供了一个所谓的package的概念，将 一堆action和interceptor组织到一起，其设计中package的extends属性看上去是不是有点眼熟。概念多了就要分模块，这一点在 面向对象之前就存在了，也符合Struts的发展历程，只是WebWork的这个extends不再是简单的模块概念了，而是一种面向对象的设计，只是 WebWork中没有实现型与名的分离，每个action名对应唯一的一个action，所以package也可以看作是一种完全静态的对象,只有一个实 例，不是吗? 我们可以做一个对应，包的namespace大概可以对应于Jsplet中的objectScope, 包名大概可以对应于Jsplet中的objectType, action对应于objectEvent, 差别在于objectScope是完全动态的，并参与Web对象管理，而package的namespace被创造出来之后只起了一个名字区别作用， Webwork的后续发展会不会在这一点上再做些文章?
再看另外一个地方。前台页面显示需要从模型中拿到数据，那模型对象是怎么管理的， Jsp本身提供了几个管理策略application, session, request, page, 几个action需要共享状态信息怎么办？状态与行为的相关就是对象化了。Webwork2没有提供对象化的手段，不知道一般人是怎么做的，将所有相关操 作都塞在一个Action里，然后通过一个扩展参数映射? 还是都从session中存取模型对象? session中的对象是不是越来越多，有没有人来管一管?

jsplet的核心是objectManager, 它利用objectFactory来创建对象，利用objectName来管理WebObject，这是与网络无关的, 这里管理的对象也不一定需要响应Web事件。
对 象如果需要响应事件, 实现IEventListener接口，在缺省实现中, Jsplet用了EventManager来管理objectEvent的响应，大致相当于xwork的工作，只是EventManager是个帮助对 象，由WebObject自己决定是否使用，而且它是每个WebObject自己使用自己的EventManager, 而不是系统全局只有唯一的一个EventManager。

整个objectManager层面都是网络无关的，当然可以单元测试。 WebEngine最终实现objectManager与web环境的关联，只是它使用了拉模式。特别是在视图jsp中调用WebEngine, 其最重要的作用是将thisObj这个变量注入到jsp模型中。this指针其实体现了对象化的很重要的特点:使用局部名而不是全局名称。
其实XWork本身也是可以脱离Web环境应用的，特别是它可以脱离View来使用，这是它的扩展性的一个来源。

在Webwork 中有一种叫做Model Driven的概念，使用Model Driven之后在OGNL表达中就可以直接使用model的属性和方法。在jsplet使用我们自己的tpl模板引擎, 其中token解析策略是thisObj的属性和方法可以直接使用，也可以通过thisObj.xx来访问，这就如同this指针的用法。


再次声明，我无意将jsplet与其它框架在实际使用效果上作对比，所分析的只是Framework整体的概念模型。数据绑定，参数和状态校验等与应用相关的功能在我们的框架中都是有着完整的解决方案的，目前不打算讨论这些。