[YMIR-284] Page/DTOクラスでString型以外(Dateなど)を定義して変換エラー時にnullになる Created: 2009-01-19 Updated: 2009-02-02 Resolved: 2009-01-27 |
|
Status: | Closed |
Project: | Ymir |
Component/s: | ymir-core |
Affects Version/s: | 1.0.0 |
Fix Version/s: | 1.0.1 |
Type: | Improvement | Priority: | Major |
Reporter: | jflute | Assignee: | skirnir |
Resolution: | Fixed | Votes: | 0 |
Labels: | None |
Description |
【概要】 【環境】 【解決案】 <2> Dateなら、Setterに@Datetimeを自動的に付与する。 【補足】 |
Comments |
Comment by skirnir [ 2009-02-02 ] |
確認ありがとうございました。closeとします。 |
Comment by jflute [ 2009-01-27 ] |
> 変換エラーのログ [DateConverter#doConvert():25}] - Conversion error occured. You may add a constraint annotation to the corresponding property in order to notify validation error to a user: aaa
java.text.ParseException: Unparseable date: "aaa"
at java.text.DateFormat.parse(Unknown Source)
...
|
Comment by jflute [ 2009-01-27 ] |
Conversationの件は、確認しました。ありがとうございます。 変換エラーのログは、まだ確認出来ていません。 |
Comment by skirnir [ 2009-01-27 ] |
おっしゃる問題(Conversationから復元された値のフォーマットが不適切)に対処しました。ZPTでプロパティ名だけを書いたTAL式でフォーマットが効いていなかったのが原因でした。 また、変換エラーのログを出力するようにしました(r2709)。 これでこのissueに関する対処を完了しました。確認をお願いします。 |
Comment by jflute [ 2009-01-26 ] |
まず、「tal:define=」でDTOを作るべきでないということで、 ZPT上の書き方も指摘通りこのようにしました。 <input type="text" name="birthdate" tal:attributes="value birthdate"/> 続いて、別の画面から戻ってきたときやページングでの自分へのリダイレクト時に |
Comment by jflute [ 2009-01-26 ] |
試しに、Extendedでのオーバーライドを消して、 |
Comment by jflute [ 2009-01-26 ] |
こちら「dbflute-ymir-example」で再現します。 会員検索一覧(/member/search/list.html)の検索条件「正式会員日」に <table border="1" tal:define="cond self/condition"> ...(略) // 「正式会員日」 <input type="text" name="formalizedDateFrom" class="T_date" size="14" tal:attributes="value cond/formalizedDateFrom"></input> // 「PageクラスのBase」 @org.seasar.ymir.annotation.Meta(name="formProperty",value="condition") public java.util.Date getFormalizedDateFrom() { return this.condition.getFormalizedDateFrom(); } @org.seasar.ymir.annotation.Meta(name="formProperty",value="condition") @org.seasar.ymir.scope.annotation.RequestParameter public void setFormalizedDateFrom(java.util.Date formalizedDateFrom) { this.condition.setFormalizedDateFrom(formalizedDateFrom); } // 「PageクラスのExtended」 @Override @RequestParameter @Datetime("yyyy/MM/dd") public void setFormalizedDateFrom(Date formalizedDateFrom) { super.setFormalizedDateFrom(formalizedDateFrom); } // 「Dto」 public void setFormalizedDateFrom(java.util.Date formalizedDateFrom) { this.formalizedDateFrom = formalizedDateFrom; } > freyja-1.0.12-20090122.161429-2.jar |
Comment by skirnir [ 2009-01-26 ] |
こちらでは@Datetime("yyyy/MM/dd")をSetterにつけて正しく動作しているようなので、すみませんが今度現象の詳細を確認させて下さい。 |
Comment by jflute [ 2009-01-24 ] |
SNAPSHOT試してみました。 freyja-1.0.12-20090122.161429-2.jar Setterに@Datetimeを付けない状態でのDate型プロパティは、 Setterに@Datetimeを付けた状態でのDate型プロパティは、 |
Comment by jflute [ 2009-01-23 ] |
ありがとうございます。 |
Comment by skirnir [ 2009-01-23 ] |
そうですね、ではログを出力するようにします。 具体的には、Conversionに失敗した場合に「Conversionに失敗した」ということと、「Constraintがないと変換エラーが起きてもアプリ利用者にフィードバックできないのでConstraintをつけてね」ということをログ出力する感じで考えたいと思います。 |
Comment by jflute [ 2009-01-23 ] |
> DateについてはString→Date変換と同じ日付パターンで表示されるようにしました。 > 自動生成時に型を見てconstraint annotationを付与することは可能ではありますが、生成→ユーザが手動でconstraintを変更→再生成 Constraintが定義されるまでは「Constraintがないよ」という |
Comment by skirnir [ 2009-01-23 ] |
<2>でDateの際にZPT中のパターンを見るという意見がありましたが、これの代わりにプロパティに制約が付与されていない場合のプロパティの入出力の対称性を高めました。 対称性とは、あるプロパティのGetterが返すオブジェクトがHTMLに埋め込まれる場合の文字列表現と同じ文字列がリクエストパラメータとして渡されてきた場合、それがそのプロパティのSetterによって設定されるということを意味します。現状ではStringやIntegerについては対称性が保たれていますが、Dateについてはそうなっていません。 そこで、DateについてはString→Date変換と同じ日付パターンで表示されるようにしました。これでDateについても対象性が保たれることになります。さらに、Setterに@Datetimeでパターンが指定されている場合はそのパターンに従ってDateを文字列に変換して表示するようにしました。 一方、自動生成時に型を見てconstraint annotationを付与することは可能ではありますが、生成→ユーザが手動でconstraintを変更→再生成、とした場合にユーザが手動で変更したconstraintを残して追加でconstraintを生成しないということが難しい(単にもともとある場合に生成しないようにするだけだと、生成→型を変更→再生成、とした場合に以前のものが残ってしまう)ため、対応するかは考えさせて下さい。 |
Comment by jflute [ 2009-01-21 ] |
Exampleポリシーとしては、Date型は使わないようにしてますが、 そういう意味では「2」も優先度はIntegerのが高いです。 |
Comment by skirnir [ 2009-01-21 ] |
まず、Ymirの型変換の挙動は、基本的にこの世界のデファクトスタンダードであるStrutsの型変換の挙動に合わせてあります。そのため変換エラー時は何もしないという挙動にしています。 ただ、<1>ログに出力したいというニーズは理解します。また、<2>型に対応するconstraintを自動的に付与するというアイデアは良いと思いますので、ともに検討します。 |