也说说Struts2的Convention和REST插件

首先个人觉得Struts2.1有很大的进步，不再单单是struts2.0.x刚刚出道时被人评做仅仅是webwork2换个包名而已；其中我觉得支持插件和模块化开发是一个很大的进步，这直接让struts2的生态圈得到了改善，目前有几十个插件了，而且很多第三方的插件也慢慢加入到了官方插件列表中。

使用过Rails like的框架之后，我们都会想如果可以在传统的Java Web应用中可以有Rails类似的友好的URL该多好啊，现在似乎convention plugin 和REST plugin可以做到这些，可是经过一些文档和源码的查阅之后，我觉得convention plugin还是不够方便，不知道是自己水平所限，无法充分利用上这个插件，所以有相关经验的大侠也可以指点一二。

个人感受最深的一点便是Multi Action的支持，convention插件中，默认是用Java包名作为namespace的层级关系，但是我觉得在MultiActiond的情形中，还需要可以以一个Action类的名字作为NameSpace才好；一个Action中编写多个方法供页面调用，虽然Struts2提供了Dynamic Method Invocation的方法，但是个人觉得这种通过后面加‘！’的调用方式最终形成的URL，并不符合我们的预期，虽然可以通过足够的@Action标记，实现友好的URL，可以那么多写到代码里面的“配置”，让我觉得这个convention不够力度，说说我理想中的convention的实现。

package com.xxx.actions;  // the root package

public class FoobarAction implements Action {
    public String index() throws Exception {
         ///do someting
         return SUCCESS;
    }
    public String save() throws Exception {
        // do something
        return SUCCESS;
    }
    @Jsonify(root="foobarList")  // custom annotation
    public String list() throws Exception {
        // do somethind
        return SUCCESS;
    }
}

对于上面的这个Action，我的原意是想实现对Foobar实体的CRUD操作，我希望我不要写一行的@Action配置最终达到这样效果:
/foobar/ -> mapping to method index() of FoobarAction
/foobar/save -> mapping to method save() of FoobarAction
/foobar/list -> return jsonify data of foobarList
上面的URL匹配，尽管不是RESTful的，但是可以简单化URL，并且需要配置的东西很少；这样的URL对Controller的映射关系，在很多语言框架中都是这样设计的，但是在Struts2不考虑这么设计我觉得有点out的嫌疑。现在Spring MVC在这方面就做得很好，为什么Struts2的convention插件不考虑如此呢？当然，对于只有唯一的execute方法的Action，使用java的包结构作为namespace是无可厚非的，而对于一个支持动态方法调用的框架，为其设计一个了一个CoC的插件，为什么不考虑上面说的URL组织方式呢？感觉现在convention的设计就感觉要一个Action只做一件事似的，压根就不要写MultiAction，但是这样明显会造成类急剧膨胀和相关逻辑代码的分散，以及set/get参数的代码增加。大家觉得呢？是否有没有必要扩展和改写convention插件，甚至开始一个新的插件？请大家讨论和指点！