-本

mayaa

なかなか文章を書くのはつらい。コードのほうが多くを語れると思うところで、川を渡ってしまったかともおもふ。今、とにかくこれは書かねばと思ってるのが、InjectionResolverメカニズムのところ。これを明らかにしておくと、各方面幸せになるらしい様子を聞いてます。
HTMLテンプレート中のタグを見て、なにもしなくてもStrutsアプリケーションに仕立てたりする、「formをみたらhtml:formと思え」という機能をつくるとしたら、たぶんInjectionResolverです。作ってファクトリ設定にクラス名を１行書いてあげればいい。ほか、すでにサンプルでは作ってもらってますが、Seasar等のドメインモデルを握ってるところのネゴはAttributeScopeというのをちょっと作って、やはりファクトリ設定にクラス名を１行書きます。そのほかはTemplateProcessorを別にすると、スクリプトエンジンとか、テンプレートパーサとかの大物になりますが、これらも差しかえることは可能で、たとえばRhinoをOGNLやBeanUtilsなどに代えたり、.mayaaファイルをJavaソースにしてXMLを無くすことも理論的には可能です。ただ、いろいろ可能性を考えても、どうもダサいアイディアしか思いつかないので、今の形がひとつの完成形にちかいんじゃないかなと思います。ま、そんなこんなで本を書く、と。

-アノテーションの限界

java

直感的には、Javaアノテーションによるソリューションの限界も近いように思います。用途によってはXMLのほうがとても「優しい」可能性もある。それもこれも、先日のエントリにきしださんがコメントくださったように、Javaアノテーションは継承できないところにあるように思います。

 - 現行仕様枠内 -
public @interface Validation {
  Class< ? extends Validator > validator();
}

こんなのがあったとして、

 - 現行仕様枠外 -
public @interface LengthValidation extends Validation {
  Class< ? extends Validator > validator() default LengthValidator.class;
  int max() default 16;
  int min() default 1;
}

とできて、代入互換性の確保と型の判断ができればOKなんですが。。。いっそのことアノテーションにこそ総称型が入ればいいのにな。どうも現行仕様では柔軟性にもう一息欠けてますね。いままで出来なかった地平を開く技術だけに、期待もデカかった。

 - 現行仕様枠外 -
public @interface Validation< T extends Validator > {
  Class validator();
}

アノテーションについては、このへんの使わせ方のイディオムがまだ積みあがってないのでまだまだ余地がありますね。