Struts 2のConventionとRESTプラグインについても

まず個人的にはStruts 2.1大きな進歩があり、strutsだけではありません.0.xデビューしたばかりの頃、webwork 2のパッケージ名を変えただけだと評価された.その中でプラグインのサポートとモジュール化の開発は大きな進歩だと思います.これはstruts 2の生態圏を直接改善し、現在数十のプラグインがあり、多くの第三者のプラグインも徐々に公式プラグインのリストに追加されています.
Rails likeのフレームワークを使った後、伝統的なJava WebアプリケーションでRailsのような友好的なURLがあればどんなにいいのか、今はconvention pluginやREST pluginでできるようになったようですが、いくつかのドキュメントやソースコードを調べた後、convention pluginはまだ不便で、自分のレベルが限られているとは思いません.このプラグインを十分に利用できないので、経験のある大侠も一二を指摘することができます.
個人的に一番感じたのはMulti Actionのサポートで、conventionプラグインではデフォルトでJavaパッケージ名をnamespaceの階層関係としていますが、MultiActiondの場合、Actionクラスの名前をNameSpaceとして使う必要があると思います.1つのアクションではページ呼び出し用に複数のメソッドが記述されていますが、Struts 2では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;
    }
}

上記のアクションについては、Foobarエンティティに対するCRUD操作を実現したいと思っています.私は1行の@アクション構成を書かないで最終的にこのような効果を達成することを望んでいます.
/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へのマッピング関係は、多くの言語フレームワークでこのように設計されていますが、Struts 2ではこのような設計を考えないのは少しoutの疑いがあると思います.今Spring MVCはこの方面でよくやっていますが、なぜStruts 2のconventionプラグインはそう考えないのですか?もちろん、唯一のexecuteメソッドのみのActionに対してjavaのパッケージ構造をnamespaceとして使用するのは間違いありませんが、動的メソッド呼び出しをサポートするフレームワークに対して、CoCを1つ設計したプラグインに対して、上記のURL組織方式を考慮しないのはなぜですか?今のconventionのデザインは1つのActionが1つのことしかしないような気がして、MultiActionを書かないでください.しかし、これは明らかにクラスの急激な膨張と関連する論理コードの分散、set/getパラメータのコードの増加をもたらします.皆さんはどう思いますか?conventionプラグインを拡張して書き換え、新しいプラグインを開始する必要はありますか?皆さん、討論と指摘をお願いします.