妄想だけで終わらせるのはもったいない

妄想2のつ・づ・き♪
http://d.hatena.ne.jp/shot6/20080529#1212046240

JSFのようなイベントモデルをとらないで、こういうActionベースでの考え方の場合、あまり機能を増やさないほうが

結果的に融通が利いてやりやすい。必要ならばその上にかぶせればいいだけだし。

最近だとオレもそんな感じです。
かつActionベースでリクエストの何らかのインスタンスが引数でわたってくるモデルがお気に入りですね。

この考え方であればそれでいいですね。インターフェースはラップした側でいれてしまえば、必須として縛ることが十分可能です。ですが、ベースとして最初からインターフェースを入れてしまうと必須をはずすことができないわけですし。

リクエストスコープに入れてしまえば、というのはいろいろと試行錯誤しての結果でした。たしかに便利にはなっていません。不便にもなっていませんけど。メソッドだけを見ればわかるというほうが便利でしょうね。ただし、DWRのscriptスコープのような場合はこういうタイプがいいのでしょうけど、これもまたラップすればすむ話。

イベントの振り分けもnameとvalueは必須ではない属性にしてしまえばいいだけですから、これもこのままでいいとおもいます。デフォルトはメソッド名で。


面白いのでSpringMVCのパラメータやモデルの渡し方もここにのせてみたいと思います。SpringMVCの基本はシングルトンですからすべてメソッドで完結しています。

たとえば古の時代からあるSpringMVCの戻り値だとこんな感じです。

	@RequestMapping(method = RequestMethod.POST)
	public ModelAndView add(
			@RequestParam(value="arg1") String arg1String , 
			@RequestParam(value="arg2") String arg2String ) {
			
		//Validationはここらでお好きにどうぞ。
		Integer arg1 = Integer.valueOf(arg1String );
		Integer arg2 = Integer.valueOf(arg2String );

		
		Map<String,Object> requestMap = new HashMap<String,Object>();
		requestMap.setAttribute("arg1", arg1);
		requestMap.setAttribute("arg2", arg2);		
		requestMap.setAttribute("result", arg1 + arg2);//オートボクシングでよい
		
		return new ModelAndView("jsp/add.jsp",requestMap);
	}

フォワードやリダイレクト先とrequestへのパラメータの指定ができます。

で、最近だと引数にもかけます。

	@RequestMapping(method = RequestMethod.POST)
	public String add(
			@RequestParam(value="arg1") String arg1String , 
			@RequestParam(value="arg2") String arg2String ,ModelMap requestMap) {
			
		//Validationはここらでお好きにどうぞ。
		Integer arg1 = Integer.valueOf(arg1String );
		Integer arg2 = Integer.valueOf(arg2String );

		
		requestMap.setAttribute("arg1", arg1);
		requestMap.setAttribute("arg2", arg2);		
		requestMap.setAttribute("result", arg1 + arg2);//オートボクシングでよい
		
		return "jsp/add.jsp";
	}

戻り値は何もしないとフォワードで、「redirect:」をつけるとリダイレクト指定になります。


妄想だけで、オレオレフレームワークだけで終わらせるのはもったいないですね。シンプルな各自カスタマイズを前提としたベースとなるべき薄いフレームワークは絶対に公開すべきですよ。


フレームワークとしてとしてjarファイルをクラスパスに登録して終わりということではなく、その上に便利になりそうなプラグインとしてどんどん乗せていく、もしくは自前でコードを書いていくというアーキでいいと思います。

シンプルですからバグは少ないでしょうし、パフォーマンスも問題にはなりにくいでしょうし。


このフレームワークが近日中に公開されるのでしたら、お手伝いしましょう。ドキュメントとサンプルコードはインストール直後のNetBeansからさくっと使えるように用意したりするだけではなく、次の開発案件で(ベータや非公開のアルファバージョンであっても)すぐに実装してバグあらいだしますよ。納品日はまー先になりますし、シンプルだからこそ自前でいくらでも調整はできるでしょうし気にしていません。

前提としてコンテナ非依存がありますけど。つまり、Seasar2でもGuiceでもSpringでもEJB3でもDIコンテナなしでも動かせる物がいい。


と、発破をかけてみる。^^;