jsplet:对Model 2模式的批判

注册类型而不是名字，则一个页面上就可以出现多个类型的对象。

对象生命周期管理可以控制运行时的规模，就如同桌面程序，打开一个菜单才能使用下面的对象。

对象事件路由使得jsp页面本身可以被进一步分解。比如
页面A: 需要objectMain和LayoutView
   子功能X : 需要objectX和viewX
   子功能Y : 需要objectY和viewY
最简单的页面上摆上两个列表一个角色列表，一个用户列表，要求能够独立翻页

总之，对比一下桌面应用程序中的对象控制和消息路由策略就很容易理解了。

我好晕,,,,,,,,,,,,,,,自己做框架很好,开发过server最好罗(简单的server谁都懂得开发吧...喔,如果是开发中间件并且现在项目中有采用的,我就不说了)

无论怎么分层,怎么样实现都好,都要合符单一职责原则.

你的MVC更注重的是V这层(不可否认,你应该是比较全面,对于开发web),只是传统的MVC2比较注重C.

唉....

你也许好久没有看过其它的框架了吧.其实我现在最喜欢的webwork2,他的MVC已经做得很好,并且它内部的实现也是MVC的(模块化,完全合符注入原则,思想是超不错的),具体情况可以看一下关于webwork2的资料.

不过我也讲一句,你的框架应该不错,嘻

但不要说MVC2了.

jsplet是我写的第一段java代码，也是我写的第一段web相关的框架代码，此前我一直是开发C++的。开发jsplet的时候，还没有webwork这个项目。不过，它的问题也是一样，都是基于action层面的，具有同样的局限性。在jsplet的实现中，一直是基于接口的，这方面和WebWork没什么区别。
   这里并无意比较各个框架的实际使用效果。我所指出的只是设计中的一个自然的扩展途径，一个随着复杂性的递增而逐渐展开的设计。如果你只是一个框架的使用者，我想这里的讨论对你无益。另外说一句，不要认为现有的就是最好的。你能预测webwork下一步会怎么发展吗。

呵...

说到框架倒是做过几个,现在也在用着几个.记得自己做的webMVC框架真是搞笑,幸好看到了一些开源的框架,才发觉自己目光短浅....

现在的不是最好的.....

究竟webwork和你的jsplet是不是一样,我就不好说了.因为你的源码与整个的开发过程我都不太了解...还有就是开发出来的action的可测试性,偶合性,数据绑定等.

不妨多说一点.

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整体的概念模型。数据绑定，参数和状态校验等与应用相关的功能在我们的框架中都是有着完整的解决方案的，目前不打算讨论这些。

我有几个问题想和楼主探讨一下。

1. Control Flow
楼主给出的例子，首先当前demo_view.jsp，产生了一个thisObj，同时还调用了对应的WebActionType 类DemoAction 来操作这个thisObj。
可以看出，JSPLet的入口点是view, 而不是Action。控制流程是Page Centric (以Page为中心)，而不是Action Centric (以Action为中心)。是View -> Action，而不是Action -> View。
所以楼主后面的这个比较是不公平的。

这里的a_view.jsp 和 b_view.jsp 同样是两个访问点。

如果在Action Centric的框架，要避免两个访问点，可以这么定义。
view.do?&templateName=a &objectName=/@Demo&objectEvent=test
view.do?&templateName=b &objectName=/@Demo&objectEvent=test

多一个参数templateName,  如果templateName = a, 那么导向a.jsp, 如果templateName = b, 那么导向b.jsp。

楼主给出的另一个例子。


如果是无状态（所有信息都通过页面参数来回，而不保存在Session中）的方式，
Action Centric 确实比较麻烦，必须同时传入角色列表 和 用户列表的 分页信息。
JSPLet对于这个问题是怎么处理的？

2．JSPLet Action 必须是 JSP ?
JSPLet的 Action部分用JSP实现，一个好处是可以即时修改编译。
这里我想问一下，Action部分几乎和页面输出无关，全属于业务逻辑部分，理论上可以是任何Java类，不用JSP实现也可以。

3. URL Parameters -> listener method

Tapestry, Wicket, JSF等 "C/S事件驱动机制 + Page Component Binding" 类型的框架，都实现了事件机制，根据URL参数映射到对应的Object的方法。它们的Link 是自己生成的，参数里包括了method name, parameter name value, 还包括了框架本身使用的一些状态控制信息，是一种有状态绑定。有可能在页面回退的时候，产生Stale Link的问题。
WebWork能够实现输入输出数据的无状态绑定。

楼主的URL Pattern定义的更完善一些。包括了类的层次、方法（事件）名、参数名值 等信息。似乎是无状态的绑定，不存在Stale Link问题。这是个相当优秀的特性。

4.  response输出结束之后的控制

MVC的步骤通常是这样，
Dispatch Servlet -> Action -> Dispatch Servlet -> View (jsp, freemarker, velocity)

这个过程的特点是 Action 和 View 分开，等于把 业务逻辑 和 显示逻辑分开。据说这样清晰。
但这个过程，同样也有缺陷。View是最后一步，控制转到View之后，就直接response输出，就完事了。用户没有机会 在view完成之后，统一做释放资源的扫尾工作（比如，一个著名的例子是OpenSessionInView问题）
可以用一些方法解决（还要考虑异常的try catch 流程）：
(1) 用ServletFilter, ActionInterceptor等截获。
(2) 在每个view script末端加入一段 清理代码。

我自己的做法是，把控制进一步转交给框架中的Action。Action的定义是这样。
interface Action{
  void service(request, response);
};

这个Action的责任重大，它没有返回值，它要自己负责把 html 输出到 response里面，自然可以在response之后，做最后的扫尾工作。

我想问一下楼主，JSPlet是如何处理类似问题的？在view.jsp中处理？

5. 关于WebWork Action


WebWork的Action本身就是模型对象。WebWork Action比一般的MVC框架中的Action的级别要低一些，相当于ActionBean。其属性同时也当作输入参数，和输出Model来使用。每次request – response cycle都生成一个instance，然后丢弃。并不保存状态。

        if (pushAction); {
            stack.push(action);;  // stack is the OGNL Stack
        }

当Action实现了ModelDriven接口的时候，表明使用 getModel() 的返回值作为bean。这个时候，getModel() 就代替了 Action本身，作为输入参数，和输出Model。

        if (action instanceof ModelDriven); {
            ModelDriven modelDriven = (ModelDriven); action;
            OgnlValueStack stack = invocation.getStack();;
            stack.push(modelDriven.getModel(););;
        }

同意楼主的观点.

我最早就是直接用jsp servlet javabean taglib做model 1 感觉很自由 往往能写出很小巧 快速的程序. 甚至可以在几个小时内做出一个网站框架
唯一的不足是要自己处理数据类型的验证和转换.

小应用采用model 1是最适合的 无论是开发速度还是性能都比struts之类的mvc强速倍. 单挑用这个很棒 ! 

对于中型的应用以页面为中心的开发思路会带来巨大的麻烦 而且很难协同多人共同完成任务.

这种做法就是程序自己处理而不是框架支持了。我说过，工作就是那么多，只是框架做什么和程序作什么的分工而已。说jsplet是page为中心也不太准确，jsplet是以对象为中心，只是指定了希望使用的视图页面而已。view.jsp放在前面只是jsp实现上的一个问题，


很简单包含两个子页面
list_both.jsp
<jsp:include page="role_list.jsp?objectName=/@RoleManager" />
  <jsp:include page="user_list.jsp?objectName=/@UserManager"/>
在访问的时候通过指定eventTarget参数即可将事件路由到合适的对象，没有响应事件的对象thisObj里的内容不变，因为前台view显示内容也不变。注意这里role_list.jsp和RoleManager, UserManager对象都是独立开发的。


当然可以是任何java类， JSP Action只是IEventListener接口的一个实现


在我们的前台模板机制中存在一个资源回收机制，不过基本没有用过。我们不使用hibernate，一般没有持续持有资源的情况，基本上所有的处理都在action中完成了。如果你说的是在action中处在transaction中的情况，那我们是通过IEventFilter实现的。


这是WebWork弱的地方，它因为是基于action的，没有对象化，所以只有以action作为模型对象的载体，无法捕获多个action之间的状态相关性。
完全无状态的设计正是因为没有合适载体造成的。而jsplet中thisObj可以看作是对session的局域化，是对session的分解。jsplet中的很多概念在webwork这种面向action的框架中都能找到对应，只是加上了很多限制并且变得模糊了。

我们用jsplet开发的是复杂的大型应用。jsplet的模式也不是model1。
不是说这个世界上除了model1和model2就什么都没有了。