关于jsplet的一些问答

引用:

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

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

引用:

Action Centric 确实比较麻烦，必须同时传入角色列表 和 用户列表的 分页信息。 JSPLet对于这个问题是怎么处理的？

很简单包含两个子页面
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对象都是独立开发的。

引用:

这个时候，role_list.jsp 和 user_list.jsp里面都有一个 thisObj。而且这两个thisObj的scope都是 sesession ?

注意所有的对象模型都需要状态保持机制，所以thisObj确实被保持在session中。在webwork2中如果希望在多个action之间协调，则必须将某个对象保留在session中，否则就是采用无状态模型，所有的状态数据都持久化在数据库中，每次输出的页面都和某个action产生绑定（一种行为相关），则根本无法实现上述例子中的分解过程，因为在action模型中状态与行为无法抽象到一起并重用！ 当页面显示逻辑比较复杂的情况下，页面本身也有一些临时状态需要保持，MVC并不是意味着所有的状态都是需要持久化到数据库中的关键业务数据。在每个层次上都可能需要保持状态，MVC只是说某些状态变量更加重要，可以驱动其它层次而已。
另外说thisObj的scope是session也是不准确的。首先注意到jsplet通过对象化实现了将状态和行为抽象到一起，此后程序就拥有了对这个整体的控制权，在jsplet中存在着对象的生命周期控制，对象的scope是自定义的，对象的生命周期是session的子部分，而不是整个session生命周期范围内都存在。请注意一下这种控制策略带来的可扩展性。我们拥有了对象生命周期的控制权，依然可以采用无状态设计，但在需要保持状态的时候，可以做到。而在webwork这样的action模型中是没有这种选择权的。

引用:

session过度使用是不好的

thisObj只是允许使用session,是否使用session可以自行决定，这是一种使能技术，而没有object支持，结果是无法有效的使用。另外，请仔细看清楚，objectScope是一种非常精细的资源使用控制手段。

另外不要把设计理念和性能混为一谈。设计体现的是对概念的把握，能够达到合适的抽象，而性能是实际实现过程中的限制。在概念能够支持的情况下，可以采用技术手段解决性能问题，或者退化到较低的层次，这是一种选择权。而概念无法支持的情况下，就需要各种穿墙打洞的方法来实现。

thisObj重要的是概念，如果需要，它可以把状态序列化到cookie或者dotNet那种参数中，这只是个实现问题。

引用:

JSPLet Action 必须是 JSP ?

当然可以是任何java类， JSP Action只是IEventListener接口的一个实现 。在jsplet最初的版本中，action只能写在java文件中。稍后改为可以写在jsp中也可以写在java中

引用:

WebWork的Action本身就是模型对象

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

引用:

没有model1简易(jstl+javabean) 没有struts的"优雅" 定位模糊.

jsplet是以非常精炼的方式实现对象化。再说一次，不要把jsplet的定位向那些开源框架上靠。jsplet的开发时间大概与那些开源框架同时进行的。仔细看看设计中的可扩展性。xwork的所有特性jsplet都可以实现，而且jsplet多提供的部分就是对象化。

可以使用 并不意味着必须使用，所有无状态设计都可以一样应用。jsplet是一种事件驱动设计，在这一点上，更像是Tapestry或者JSF。基于actioin的设计是真正的无能使用session，它不敢应用session的原因是它对session没有控制力。而在jsplet中对session的使用控制是很自然的：当你需要对象的时候，当你需要这个状态的时候，它才存在。它出现是因为需要它存在。在面向action的框架中，你仍然需要解决状态问题。只是框架无法提供支撑，自己解决而已。
我想，大概大多数人开发的程序都是CURD的堆砌，所以很难理解一个复杂的应用中的状态管理的必要性。有了对象支持之后，才构成整个框架的概念上的完备性。

很简单包含两个子页面
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对象都是独立开发的。

引用:

这个时候，role_list.jsp 和 user_list.jsp里面都有一个 thisObj。而且这两个thisObj的scope都是 sesession ?

注意所有的对象模型都需要状态保持机制，所以thisObj确实被保持在session中。在webwork2中如果希望在多个action之间协调，则必须将某个对象保留在session中，否则就是采用无状态模型，所有的状态数据都持久化在数据库中，每次输出的页面都和某个action产生绑定（一种行为相关），则根本无法实现上述例子中的分解过程，因为在action模型中状态与行为无法抽象到一起并重用！ 当页面显示逻辑比较复杂的情况下，页面本身也有一些临时状态需要保持，MVC并不是意味着所有的状态都是需要持久化到数据库中的关键业务数据。在每个层次上都可能需要保持状态，MVC只是说某些状态变量更加重要，可以驱动其它层次而已。
另外说thisObj的scope是session也是不准确的。首先注意到jsplet通过对象化实现了将状态和行为抽象到一起，此后程序就拥有了对这个整体的控制权，在jsplet中存在着对象的生命周期控制，对象的scope是自定义的，对象的生命周期是session的子部分，而不是整个session生命周期范围内都存在。请注意一下这种控制策略带来的可扩展性。我们拥有了对象生命周期的控制权，依然可以采用无状态设计，但在需要保持状态的时候，可以做到。而在webwork这样的action模型中是没有这种选择权的。

引用:

session过度使用是不好的

thisObj只是允许使用session,是否使用session可以自行决定，这是一种使能技术，而没有object支持，结果是无法有效的使用。另外，请仔细看清楚，objectScope是一种非常精细的资源使用控制手段。

另外不要把设计理念和性能混为一谈。设计体现的是对概念的把握，能够达到合适的抽象，而性能是实际实现过程中的限制。在概念能够支持的情况下，可以采用技术手段解决性能问题，或者退化到较低的层次，这是一种选择权。而概念无法支持的情况下，就需要各种穿墙打洞的方法来实现。

thisObj重要的是概念，如果需要，它可以把状态序列化到cookie或者dotNet那种参数中，这只是个实现问题。

引用:

JSPLet Action 必须是 JSP ?

当然可以是任何java类， JSP Action只是IEventListener接口的一个实现 。在jsplet最初的版本中，action只能写在java文件中。稍后改为可以写在jsp中也可以写在java中

引用:

WebWork的Action本身就是模型对象

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

引用:

没有model1简易(jstl+javabean) 没有struts的"优雅" 定位模糊.

jsplet是以非常精炼的方式实现对象化。再说一次，不要把jsplet的定位向那些开源框架上靠。jsplet的开发时间大概与那些开源框架同时进行的。仔细看看设计中的可扩展性。xwork的所有特性jsplet都可以实现，而且jsplet多提供的部分就是对象化。

可以使用 并不意味着必须使用，所有无状态设计都可以一样应用。jsplet是一种事件驱动设计，在这一点上，更像是Tapestry或者JSF。基于actioin的设计是真正的无能使用session，它不敢应用session的原因是它对session没有控制力。而在jsplet中对session的使用控制是很自然的：当你需要对象的时候，当你需要这个状态的时候，它才存在。它出现是因为需要它存在。在面向action的框架中，你仍然需要解决状态问题。只是框架无法提供支撑，自己解决而已。
我想，大概大多数人开发的程序都是CURD的堆砌，所以很难理解一个复杂的应用中的状态管理的必要性。有了对象支持之后，才构成整个框架的概念上的完备性。