コンバータはすべてプラグインとして用意するといいかも
SeasarConは見てないのでなんともいえないですが、T2Frameworkで気になったところが。
JSONにしろXMLにしろその他の独自形式にしろ要望はいくらでも出てくると思うので、思い切ってすべて入力、出力ともにプラグインにしてしまってはどうですかね?JSONとXMLの変換ライブラリは標準で用意するけど、これも実装はプラグイン。ですから、プラグインを作る人のサンプルソースとなっております、という感じの。パフォーマンスが悪ければ他のJSONライブラリに変更するとかできる余地は必要になるかも知れません。
ここから妄想はいります。閲覧注意!
例えばプラグインの登録にはGoogle Guiceのようなモジュールにしてそこで登録。設定はHogeModule.classだよ、というのをweb.xmlで定義。
public class HogeModule implements Module { public void config(Binder binder){ //引数1:キー //引数2:コンバート後のクラス //引数3:コンバータのクラス binder.getReader().bind("JSON" , JsonObject.class , JsonReader.class); binder.getReader().bind("XML" , Document.class , XMLReader.class); binder.getWriter().bind("JSON" , JsonObject.class , JsonWriter.class); } }
で、コンバータはまぁ、コンバータの元になるやつを適当にインプリメントする。
public class JsonReader implements RequestReader<JsonObject> { public JsonObject convert(HTTPServletRequest request){ .... } }
そんで、使用するときにはbindしたStringを引数にとるアノテーションを用意。
@Page("hello") public class HogePage { @GET @ActionPath public Navigation get(@Convert("JSON") JsonObject json){ .... } }
まぁ、例えばの話ですが、ここまでプラガブルにしてしまえば、ユーザーはいくらでも便利なプラグインを作るわけでして。susieプラグインとかみたいにいくらでも。PDFを出力したり逆に入力したり、ExcelやWORDの文章のやり取りとかも出てくるでしょう。また、zip圧縮とかのラッピングも容易になるかもしれません(zipの解凍圧縮をするPageクラスが実際にJSON等をやり取りするPageクラスにフォワードする)し、Velocityとか好きなテンプレートを挟む余地も生まれるでしょう。
すべては妄想なので見当違いならば無視してください。^^;