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的移植机制。”
知识严重过时。
去年使用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... 8 楼 robbin 2006-07-30 在webwork中，你所谓的module在webwork里面的术语叫做namespace,看一下webwork的文档，你想要的功能webwork都已经有了。 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。 10 楼 welllove53 2006-07-31 能不能写一种方法，把/package/actionName/methodName生成URL
如：
***/model1/*add*.action = org.javaeye.**.model1.**Action.add
可以直接在html上声明你调要的actionName.methodName
主要还是为了减少配置 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 12 楼 welllove53 2006-07-31 继续跑题
我觉得一个"每一级映射又自己的 dispatcher"这个做法不是太好.
大的项目这样的dispatcher太多了.
如果composeClassFullName( ..package, action, method. )="一个字符串",这个字符串作为URL中的"一个字符串.action",这样,你的URL中其他的模块随意定义就可以了.
虽然这个时候URL的语义不清楚,但是我们可以给个工具,很容易的找到package, action, method. 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。都可以分别进行部署。
一般的应用都用不到这个功能。
什么样的网站比较适合？
就是那种多了一套业务，就需要增加一套代码的那种业务。 14 楼 tianxinet 2006-07-31 robbin 写道Webwork的Lead老兄Pat Lightboy在n年前就在自己的blog上面宣称，webwork2.2和RoR没有啥区别，只不过一个是Java实现，一个是Ruby实现。
你相信他的话吗？
其实更重要的是：开发者看到了其他框架的优点，并试图采纳和改进自己的设计，这对用户是好事。毕竟“完美”的东西是不可想象的。
至于Pat Lightboy老兄的话嘛，他姑妄说之，咱姑妄听之，哈哈 15 楼 tianxinet 2006-11-11 struts2已经发布，并开始走入实际应用，现在可能很多人有开始关注它，所以翻翻老贴，增添一些信息，看看大家的讨论，也会获取一些有益的信息。 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+正则表达式
