Struts 2-Struts Ti,基于Java的RoR?

今天看了一下Struts2的release计划，有如下描述：

“Struts 2.0 的发布遵循  Struts Ti 计划书。包括两个阶段： Struts 2.0 是第一阶段，第二阶段是后续的 Struts发布系列 (Struts 2.1 或 Struts 3.0) 。

Struts Ti是一个简单化的Model 2（MVC）框架，面向不希望服务端组件有额外的复杂性和繁琐配置，但是具备最新web框架特性的的web应用。它定位于合并Ruby on Rails 和 NanoWeb的简单性、WebWork2的精巧性、Beehive的友好性。

Struts Ti的关键词是简单、完美。Struts Ti应该有Ruby on Rails级的易用性，并为大型应用提供向JSF的平滑过渡（如果需要）。”

Ruby on Rails级的易用性－－Struts Ti实现了基于java的RoR框架？其实也没关系，只要简单易用就行了。现在Struts文档还没有完成，2.0.0版8月份才能发布，到时候看看吧。

另：
“目前struts2正在开发中，如果现在就想升级到struts2，开发组推荐webwork2作为切入点。当然你也可以等一等，struts2预计今年3季度发布，不管是使用webwork2或struts1，都不用担心，struts2发布的时候，会包含webwork2、struts1的移植机制。”

评论

16 楼 zkj_beyond 2006-11-12  

buaawhl 写道

thanks robbin.
webwork的 package name 和 namespace config，这个功能，在我以前用webwork的时候，已经有了，我看到过这部分。
不过，和struts module config 差不多。属于一种简单的helper。
module (namespace) 之间不存在层次关系，是一个 flat 结构。
和简单的 url -> action 并没有本质不同。

我指的是，zope, RoR, webwork, struts等的简单url mapping convention无法达到类似 xlink + xpointer 那样的丰富的分层分级别的寻址和mapping。

/model1/submodule3/actionName/methodName/paramters..

这里其实是一个分级module 。上一层module包括下一层module。
每一层module有自己的 dispatcher，而不是都定义在一个或几个统一的 mapping config file中。
这样的好处是，几乎不需要config, 只需要很少的convention pattern config。增加一个或这个多个，一级或者多级module 的时候，也不需要重新刷新读取整个 config part。

springMVC可以达到效果

http://www.redsaga.com/spring_ref/2.0/html/mvc.html#mvc-handlermapping
http://www.redsaga.com/spring_ref/2.0/html/mvc.html#mvc-controller-multiaction
http://www.redsaga.com/spring_ref/2.0/html/mvc.html#mvc-coc
扩展处理器映射（handler mapping）+MultiActionController+正则表达式

15 楼 tianxinet 2006-11-11  

struts2已经发布，并开始走入实际应用，现在可能很多人有开始关注它，所以翻翻老贴，增添一些信息，看看大家的讨论，也会获取一些有益的信息。

14 楼 tianxinet 2006-07-31  

robbin 写道

Webwork的Lead老兄Pat Lightboy在n年前就在自己的blog上面宣称，webwork2.2和RoR没有啥区别，只不过一个是Java实现，一个是Ruby实现。

你相信他的话吗？

其实更重要的是：开发者看到了其他框架的优点，并试图采纳和改进自己的设计，这对用户是好事。毕竟“完美”的东西是不可想象的。
至于Pat Lightboy老兄的话嘛，他姑妄说之，咱姑妄听之，哈哈

13 楼 buaawhl 2006-07-31  

welllove53 写道

继续跑题
我觉得一个"每一级映射又自己的 dispatcher"这个做法不是太好.
大的项目这样的dispatcher太多了.

分dispatcher比较适合大项目。
比如，第1级有10个module, 其中的（第2级）每个module又有10个module，这些module下面每个又有 10个class。

那么共有 2 级module,  1000 个 class。
如果这 1000 个class，统一配置的话，或者统一定制映射规则的话，比较难以管理。里面需要考虑 100 个pacakge 分组。

如果分成dispatcher.
那么需要  1 + 10 + 100 = 111 个 dispatcher。
这 111 个 dispatcher 之间都没有关系，都是独立管理自己的 modules or classes。都可以分别进行部署。

一般的应用都用不到这个功能。
什么样的网站比较适合？
就是那种多了一套业务，就需要增加一套代码的那种业务。

12 楼 welllove53 2006-07-31  

继续跑题

我觉得一个"每一级映射又自己的 dispatcher"这个做法不是太好.
大的项目这样的dispatcher太多了.

如果composeClassFullName( ..package, action, method. )="一个字符串",这个字符串作为URL中的"一个字符串.action",这样,你的URL中其他的模块随意定义就可以了.
虽然这个时候URL的语义不清楚,但是我们可以给个工具,很容易的找到package, action, method.

11 楼 buaawhl 2006-07-31  

welllove53 写道

能不能写一种方法，把/package/actionName/methodName生成URL
如：
***/model1/*add*.action = org.javaeye.**.model1.**Action.add


可以直接在html上声明你调要的actionName.methodName

主要还是为了减少配置

这种一级的 url -> class full name mapping 做起来比较容易。
只需要定义一条映射规则就可以了。

// module, action, method is from url
composeClassFullName( ..module, action, method. ){
return org.javaeye.{module}.{action}Action.{method}
}

多级的module 映射比较难做。
我现在的做法是，每一级映射又自己的 dispatcher 和独立的 mapping rule。

比如，
/module1/submodule3/subsubmodule2/...

module1 就映射到一个 dispatcher。
这个dispatch继续处理 submodule3/subsubmodule2/...
发现 submodule3, 根据mapping rule，映射到下一个dispatcher。

下一个dispatcher继续处理subsubmodule2/...

就可以获得一个  full class name, 找到对应的 action，调用method。

总结来说，就是，前几个module都找到的是 dispatcher class，最后一个module找到的是 action class。

----

跑题了。:D

10 楼 welllove53 2006-07-31  

能不能写一种方法，把/package/actionName/methodName生成URL
如：
***/model1/*add*.action = org.javaeye.**.model1.**Action.add


可以直接在html上声明你调要的actionName.methodName

主要还是为了减少配置

9 楼 buaawhl 2006-07-30  

thanks robbin.
webwork的 package name 和 namespace config，这个功能，在我以前用webwork的时候，已经有了，我看到过这部分。
不过，和struts module config 差不多。属于一种简单的helper。
module (namespace) 之间不存在层次关系，是一个 flat 结构。
和简单的 url -> action 并没有本质不同。

我指的是，zope, RoR, webwork, struts等的简单url mapping convention无法达到类似 xlink + xpointer 那样的丰富的分层分级别的寻址和mapping。

/model1/submodule3/actionName/methodName/paramters..

这里其实是一个分级module 。上一层module包括下一层module。
每一层module有自己的 dispatcher，而不是都定义在一个或几个统一的 mapping config file中。
这样的好处是，几乎不需要config, 只需要很少的convention pattern config。增加一个或这个多个，一级或者多级module 的时候，也不需要重新刷新读取整个 config part。

8 楼 robbin 2006-07-30  

在webwork中，你所谓的module在webwork里面的术语叫做namespace,看一下webwork的文档，你想要的功能webwork都已经有了。

7 楼 buaawhl 2006-07-30  

tiyi 写道

引用

另外就是缺少了 url pattern -> action name, method name 的mapping convention。

public String doInput(){
        return INPUT ;
}


url  = testAction!input.action

这样不是吗？

thanks.

知识严重过时。
去年使用webwork的时候，还在网上讨论过如何实现这个convention。
现在已经有了。 convention over configuration。

这个url能够直接映射到 class name ? 不用config ?
待我查查，是如何处理class name 的 package name的。


-----------  题外话。

不过，这种url mapping convention（无论是RoR的，还是webwork的，还是 others）都是远远不够的。比如，对于多级module的支持。

/model1/submodule3/actionName/methodName/paramters...

6 楼 tiyi 2006-07-30  

引用

另外就是缺少了 url pattern -> action name, method name 的mapping convention。

public String doInput(){
        return INPUT ;
}


url  = testAction!input.action

这样不是吗？

5 楼 buaawhl 2006-07-29  

RoR是全套的，包括MVC, ORM。
WebWork是MVC。

如果只是从Controller来看，确实有些像。
WebWork也可以配制成不使用 action的 execute方法，而可以任意指定一个方法名。
另外就是缺少了 url pattern -> action name, method name 的mapping convention。
据说在 action interceptor里面做一个这样的 url pattern -> action method, 并不是很难。只是这么做和这么用的人不多。

如果 web work 的 view 只是采用 jsp ，那就更像了。:D
前后台的code都是同一种语言 java。正如 RoR的前后台语言都是ruby。
Just Kidding.

RoR的一些convention 可以学到，但里面更关键的特性是靠着语法能力支撑的，很难移植到java。
java 6 script,  java 7 dynamic, reflection enhancemeng之后，可能比较容易。

4 楼 robbin 2006-07-29  

Webwork的Lead老兄Pat Lightboy在n年前就在自己的blog上面宣称，webwork2.2和RoR没有啥区别，只不过一个是Java实现，一个是Ruby实现。

你相信他的话吗？

3 楼 bluemeteor 2006-07-29  

tianxinet 写道

bluemeteor 写道

从struts1移植？如果能实现ror的境界……我宁愿重写一次

建议老项目老办法，新项目新办法。移植是为了向下兼容，但很爽的移植不多见。既然宣称有Ruby on Rails 和 NanoWeb的简单性、WebWork2的精巧性、Beehive的友好性，新项目还是直接用Struts2比较爽。

为什么任何时候看到三个月以前写的代码....总觉得惨不忍睹

2 楼 tianxinet 2006-07-29  

bluemeteor 写道

从struts1移植？如果能实现ror的境界……我宁愿重写一次

建议老项目老办法，新项目新办法。移植是为了向下兼容，但很爽的移植不多见。既然宣称有Ruby on Rails 和 NanoWeb的简单性、WebWork2的精巧性、Beehive的友好性，新项目还是直接用Struts2比较爽。

1 楼 bluemeteor 2006-07-29  

从struts1移植？如果能实现ror的境界……我宁愿重写一次