Teedaのメリット・デメリット

Teedaのメリット・デメリット

大体同意見ですが、私にとって最大の誤算は、開発者のJSFアレルギーですね。JSFアレルギーというより、新しい技術に対するアレルギーといったほうが正しいかもしれません。
それも間違ってるかな。DIみたいな小難しい技術もそれなりに受け入れられているから。
あえていうなら、ブラックボックス感のある技術に対するアレルギーでしょうか。ブラックボックス感があるというのは、実際の動きが予想しづらい、分厚い仕様であるということです。
大谷さんが書いているように、フレームワークは薄くして、開発者側のほうで、好きにいじれるようにするほうが、いいのかなぁと最近は思っています。
とはいえ、Teedaスタイルのリッチな機能の提供もやれるところまでやってみてもいいのかなという気持ちもあります。
リッチというよりは、痒いところに手が届く感をより増やすということかな。
金曜日に、小林さんから、Teedaの拡張案を聞いたんですけど、結構すごい。Entityと直接バインディングできるようになるので、永続化されないプロパティ以外は、プロパティを宣言する必要がなくなります。S2Dxoも使う必要がなくなるということです。詳しくは、小林さんが語ってくれるでしょう。

SAStrutsのファンクションの改良

1.0.1でSAStrutsのファンクションに改良を入れます。
最初は、f:date()。日付のフォーマットは、fmt:formatDateタグを使うのが基本ですが、fmt:formatDateタグは、値がjava.util.Dateでなければフォーマットできません。Strutsでは、入力値を受け取るためには、文字列でプロパティの型を定義するのが普通なので、標準だと、日付用の入力値をフォーマットすることができません。
そこで、日付用の文字列で定義された入力値をDateに変換するのが、f:date()です。基本的な使い方は次のとおりです。

<fmt:formatDate value="${f:date(hireDate, 'yyyyMMdd')}"

  pattern="yyyy/MM/dd"/>

同様の理由で、f:number()も用意しました。

<fmt:formatNumber value="${f:number(salary, '####')}"

  pattern="#,###"/>

f:h()は、文字列だけでなく、Objectを受け取って、配列の場合は、Arrays.toString()を使って文字列に変換してから、HTMLエスケープするようにしました。配列以外の場合は、toString()の結果をHTMLエスケープしています。
後、テキストエリアに入力した文字列を表示するときに、改行を<br />に変換するf:br()のファンクションも追加しました。