まさたか日記

■[other]-失敗とは

SeasarとKijimunaは失敗です。が、失敗ではない。まだ手仕舞いしてないから。ただ、うまくないことも多いので少なくとも次世代のSeasar3＆Kijimuna3ではすべての成功と失敗を踏まえたうえで、イメージングの限りを尽くした上で作りたいなと。すくなくともEJB3の仕様がでる4月以降ですから、おそらく半年近く後のことです。Seasar3＆Kijimuna3がどんな機能で、利用するとどんなことができるか想像できますか？まだ作ってないから、それらは最強です。想像しうる限りの最上のソフトウェアなのです。それも、一人が想像するのではなく、たくさんの人でイメージを共有しながら計画をすればいいものできると思います。実装力はあるからね〜。リアルに細部まで考えられたら、あとは作るだけ。アジャイルとかウォーターフォールとかって、その後のHowtoの話ですよ。まず自分が何をやりたいのかもわかってなきゃしょうがないと思います。

なんか宗教がかってきましたが。徹底的にリアルにイメージすると、自然にできちゃうのです。ソフトウェアって。それが言いたかった。ということで、みなさんも今日から考えてみてください、半年間。毎日、毎日、Seasar3とKijimuna3のことを。私は今、毎日MayaとNPOのことを考えています。

実はこの考え方もどうなのか、ディスカッションすべき話題なんですけどね。私の前提ではあっても、みなさんの前提とか限らないですから。

■[maya]-S2JSF組み込み版Maya(2)

みました。SourceForgeにはまだあがってないのかな？メールで送ってもらったものみたのですが、サンプル実行してみたところ、やはりAタグが追い越されてうまく動作してないので、サンプルとして意図された動作をおえてないです。しかし、実装については、TLDのロードやテンプレのパースなど、計画している動きが結構の割合で実装されています。きちんと動くものができるものも近いでしょう。

でもね、申し訳ないけどこれはMayaじゃないです。表面の仕様は追ってるけど、つくりの根幹のところで私の持ってた問題意識はとらえていないし、わざわざ時間かけて実装を先延ばしにしても仕様をオープンにして練ってきた意味を反映したものではないです。困ったなぁ、実装量が圧倒的なのともうちょいで動くところまで来ているんで惜しいのですが。理由を以下に述べます。

• Mayaはとにかく守備範囲を狭く考えています。また他の既存技術とはできるかぎり依存せず、依存するものについては差し替え可能なつくりに考えています。JSPカスタムタグの仕様は取替えようがないですが、たとえば式言語エンジンしかり。しかしこの版ではSeasar2のライブラリが多く使われています。それらはSeasar2と一緒に同梱されてますので、配布にはSeasar2といっしょになっちゃう。この問題は、Seasar2からライブラリ群を別にメンテナンスしていくプロダクトに出せば（StrutsからJakarta Commonsが出たみたいに）解決するかな。でもいまのままだと、Springと組み合わせても、Seasar2が動いちゃってるわけです。中核のエンジンを構築するのに、Seasar2を使ってますので。そうなると、将来バージョン管理リスクも、たいしたことではないかもしれませんが、発生します。
• さらにはプラグインサポートが考慮されていない作りになってることです。Seasar2がそうなんですが、プラグインのサポートしやすい・しにくい作りというのがあって、それは特にモデルを構築するところとその持ち方にあります。エラーを含む書類をパースしてなぜエラーなのかを表示していく仕組みは、ランタイムの一点でも瑕疵があったら例外で終わらせてよいというものよりヘビーな実装が要求されます。仕様および実装が固まったあとからプラグイン作るのは難しく、先にプラグイン作るぐらいでやればちょうど良いと思ってました。が、実装が一番はじめにできちゃいました。
• さらには、コードジェネレーションしないつくりに引っかかってます。コードジェネレーションはMayaの本質なんですよ。異論はひがさんだけでなく、みなさんいろいろあると思いますけど。テンプレートカスタムタグの考えを示しましたが、あれはたしかにTapestryのパクリなんです。ただ、Tapestryはテンプレートを実行時にパースした結果をメモリ上でもち、Tapestryのフルサイズのエンジンの上で動作します。そうなるとTapestryのJWCが独自という以上に、コンポーネントが他に持ち運ぶモノでは無いのですね。そこをMayaはページがそれ自体テンプレートカスタムタグというような考えの下、コンポーネントモデルを構築したうえ、コンパイル済みのテンプレートカスタムタグはJSPページの上で使えるという仕組みにしようとしてます。これは、私の過去の案件および開発資産のポートフォリオを再構築・再生する手段なんですよ。ここ3年ぐらい、StrutsとTapestryでかなりの数の案件をこなし、StrutsやTapestryベースの製品を世に出しています。HTMLテンプレートの仕様をTapestryに近づけ、またJSP上でコンポーネントとして使えるようにするのはそこに動機があります。JWCでできたGISのコンポーネントライブラリも社内にありますし、JSPタグのライブラリでグループウェアのパーツもあります。それらをMayaで再構成しようとしているのです。

とりあえず、ひがさんのこの実装系、Mayaの名前をはずしてもらえませんか？ちょっとコードネームとしては私には思いいれがある名前なのです（だって娘の名前だもの、きっかけは偶然でしたが）。進め方としては、元の名前のS2Pagesとして実装すすめてもらって、きちんとリリースしてください。後に、ひがさんも本を書いたり、S3をつくったりしないといけないですからS2PagesおよびS2JSFから手が離れるでしょう？ぼちぼちに平行で、手をあげてくれているまるおさんとすがさんと私のほか、意欲ある方をつのったうえ、S2Pagesの成果をしっかり再利用して根幹からMayaとして再構築していくというのではいかがでしょうか？

あとは、SeasarもKijimunaも失敗プロジェクトなんだってこと、指摘させてください。実装に突っ走ったために誰も他の人がメンテナンスできない・やりたいとおもわない。Mayaはそうしたくないのが、迂遠ながら一番初めにドキュメントを書いているということです。試行錯誤ですから、手段が正しいかはわかりませんけど。

最後に、それなら何時になるかわからない、と思われる方が多くいらっしゃるかもしれません。けど、ひがさん一人で2週間ぐらい？でそれっぽいものできちゃうわけですよ。実装は特別時間がかかることではないです。ソフトウェアを作るうえで一番時間がかかるのはイメージングだと私は思います。何をどう作るか、ネクストステップでどう発展させるか、誰にやらせるか、どう見せるか。予算はどうするか。すべてにおいてイメージングできるまで頭をつかいます。手はあと。営業も会社経営も全部いっしょ。イメージングを練る時間と手間を惜しむと、かえって時間はかかる、金はかかる、質は落ちる。NPO組織もそうだし、子供だってそうでしょう。どう育ってほしいかを夢にみるぐらい念じるわけです。

■[maya]-式言語まとめ

とにかく時間かかったのは、JSPやJSFのELのインターフェイスがよく理解できなかったためです。いろいろ考察してやっとわかった（と思う）。

• JSPおよびJSFのVariableResolverは、OGNLで言うところのルートオブジェクト。これを式言語の基点とします。TapestryではOGNLの基点をPageオブジェクトとしています。Mayaはページオブジェクトが無いですが、「式言語的」にはVariableResolverが（Tapestryの）Pageと同等の役割をすると思われます（ここ、ひがさんの意見聞きたい。ひがさんのコメントの雰囲気では私と違う捉え方をしている気がするのです。よって自信ちょっと無し）。
• JSFのPropertyResolverは、その名前が私に誤解させていて、VariableResolverとグループになるものだと思ってました。が、そうではなく、OGNLではPropertyAccessor。今のJSPやJSFではアプリケーション毎にひとつだけPropertyResolverが登録されるのですが、Classをキーに複数登録できるとOGNLのPropertyAccessorのように「.」オペレータのオーバーローディングなるカスタマイズされた動きが実現できるのです。これを、JSR245では言ってるのだと思います。公開したサンプル実装ではオフサイド（？）ですがやっときました。このオペレータオーバーローディングはとてもわれわれには重要な機能で、S2Containerとのつなぎなどを後から追加的に実装するための仕組みを支えます。サンプル実装中のS2ContainerPropertyResolverのようなものを、SpringFrameworkPropertyResolverとか、JMXPropertyResolverとかいろいろ作っていけばOKというのがゴール。
• JSPのExpressionEvaluatorもしくはJSFのValueBindingおよびMethodBindingが式言語エンジンのホストです。JSPはメソッドの手当てがEL中に無いので、MethodBindingに相当する機能がありません。OGNLでは式言語エンジンの中でメソッド対応してしまうので、MethodBindingの機能は式言語「文法」のほうに溶け込んでます。

Sunの実装より、OGNL3は相当先の実装だと思います。ELの仕組みだとKijimunaでのRTTIサポートでやったような作りは難しいんじゃないかなと思います。JSP2.1でやっと追いつくんじゃないかな。ただ、バックワードコンパチに囚われるのと、JSP＆JSFの2系列の式言語の統合は結構ヘビーでしょう。

■[maya]-S2JSF組み込み版Maya(1)

ひがさんのほうでS2JSF組み込みでMayaServletを開発中とのことです。コメントの雰囲気から何かやってるなとは思いましたが、実装はいってましたか。仕様を煮詰めつつ、ひがさんの実装を取り込んでいきましょう。ひがさんにはくーす本かいてもらわないといけないしね。私のほうはカスタムタグインジェクション機構でコードジェネレーションハンドラ（仮称）でアダプタブルにカスタマイズできるようにする仕組みを、式言語ホストの仕様を考えたみたいに考えます。

禁をみずからやぶってしまいましたが、インターフェイスを軽く組むだけでも実装すると細かな点がぼろぼろでてくるんですよね。コード実装＆メンテを属人にしないために戒めていたのですが。。。私のほうは本格実装参加は後々です。仕様案つくったら次はNPOやらないといけないし。

■[maya]-式言語ホスト周辺の実装

ドキュメントを書いていて、説明が難しいので、サンプル実装を作りました。先の考察を踏まえているものです。

http://package.gluegent.com/~kurihara/maya/MayaELImplSample20041201.zip

軽く組んでありますのでコンパイルは一応通してありますが、当然動きません。パッケージなども特にこだわってつけてるものではなく、直感的につくってます。

• 式言語エンジンの差し替え
• Seasarなどとのカスタマイズされたつなぎ
• 組み込みオブジェクトの追加

これらを柔軟にやるためのアイディアを出しました。この方向でよければ、あとはハードコーディングしているカスタマイズポイントを設定に適宜出したりするなどして煮詰めていくつもりです。いきなり「ソース読め」で申し訳ないですが、ご意見いただけましたら幸いです。

■[maya]-式言語のカスタマイズ仕様の考察

JSFのValueBinding、MethodBinding、VariableResolver、PropertyResolverは登場人物としてJSR245にも出てくるという前提のもと、それらがどうなるかを考察します。

• ability to redefine the behavior of the "." operator through a Property Resolver API
• ability to plug in Variable Resolvers on a per-application and per-page basis
• ability to plug in Property Resolvers on a per-application and per-page basis
• ability to express references to bean methods using the expression language and invoking those methods via a Method Binding API
• ability to express references to bean properties using the expression language and getting/setting those attributes via a Property Binding API
• ability to defer expression evaluation until a time of a tag handler's choosing

一番はじめの、「Property Resolver API」はおそらくOGNLのPropertyAccessorの機能だと思います。今でもPropertyResolverのメソッドは、getValue(Object, Object)で、一番目の引数がベースのBean、二番目の引数がプロパティ名です。型はObjectですが、内部でtoString()して名前に変換しているので、事実上Stringです。これをValueBinding（バックワードコンパチを考えて、JSPのExpressionEvaluator）に、addPropertyResolver(Class, PropertyResolver)とするのでしょう。デフォルトでObject.classに汎用のまともにプロパティを見に行くPropertyResolverをセットしておけば、バックワードコンパチもOKです。そうであれば、Mayaの対応ではJSP2.1のスペックがでるまで独自に軽量にやっておいてもよい機能です。ここはSeasarとの連携とかで必要になる機能なので、何らかの機能がいることはいります。

二番目および三番目のVariable ResolverとProperty Resolverのアプリケーションおよびページごとにプラグインできる機能ですが、おそらくweb.xmlでアプリケーション全体の設定、JSPファイルには@ディレクティブを用いてプラグインするのだと思います。Mayaではその機能の有用性が見えてきたらでよいかと思います。エンジンいじる機能なので、簡便にやれるようにしなくてよいと思います。ただ、VariableResolverのカスタマイズによって組み込みオブジェクトのカスタマイズができます。このへんはファクトリーで対応したいと思います。

四番目の「Method Binding API」はJSFのMethodBindingを指して言ってるのだと思いますが、この機能もExpressionEvaluatorに盛り込んでしまっていいのではないかと思います。バックワードコンパチと新実装の効率を両立すると、ExpressionEvaluator#invoke(String, Class, Object[])かなと。Maya的にはOGNLでまずやるのでこのMethodBindingについては保留できます。

五番目の「Property Binding API」は値の参照のみならず設定ができるようにあらかじめ式言語エンジンを作りこんでおくということだと思いますが、Mayaの初期実装では不必要です。JSF1.2対応で必要になってくるものでしょう。JSF1.1ではスルーで式言語をJSFに行って、JSFでハンドルするのでMayaの中でやらず、S2JSFの中でやる内容と見ています。

最後がどう見せるのかよくわからないけど、バックワードコンパチ的には、デフォルトでエンジン評価なのでしょう。初期Mayaでは${}と#{}の式言語の囲いの違いで結果的にスイッチングできます。

■[maya]-JSP2.1とJSF1.2

JSR245およびJSR252での議論はMayaへの影響がいくらかあるものです。とりわけJSR245は式言語を名指しで変更すると予告しているものですから、吟味しました。昨日の移動中に整理したのは以下のとおりです。

• JSR245とJSR252の趣旨は、JSPとJSFの親和性を高めるためのもの
• JSR245は式言語のインターフェイス変更
• JSR252はJSF側のカスタムタグやツリーの構築関連のバグっぽい動きの修正で式言語関連については特に言及していない
• JSR245のVoteにおいて、オラクルの投票者が式言語だけ新しいJSRを立てるべきという意見があったのにそういう風にはなってませんが、テーブルでそういう風な捉え方が暗黙にされていると状況より想像する。

これらから、

• JSR245の内容は現在のJSFの式言語のインターフェイスに近いものになると思います
• JSR245の変更はJSP2.0とバックワードコンパチなはず。なぜなら既存JSPカスタムタグが動かなくなってしまうと困るから
• JSR245の変更と同時に、JSFのリファレンス実装等の対応もあると思います（もちろんJSR252も、ですが）。

あくまで予想ですけど。