DBFlute Time型カラムについて
TIME型のカラムを、検索条件にしたときだったと思うのですが、正しく検索できませんでした。
（たしかConditionBean使ったときの検索のときだったと思います）
どうやらスキーマ情報から自動生成するとき？に使うテンプレート（.vmファイル）に、TIME型に対するIF文だかが抜けていたのが原因だったと思います。
たしかjava.sql.Timeが、java.util.Dateかなにかとして判断されていて、DATE型と判定されてしまっていたと思います。
テンプレート直して対応したのですが、どこだっただろう。。。
会社行けば、どの部分だったかわかるのですが。
ちなみに、DBはPostgreSQLですが、他DBでもなっていたような気がします。
また、DBFluteもだいぶバージョンが上がっているので、直っているかもしれないです。
- かなりうる覚えですいません。詳しくわかったら追記します。
Teeda disabled項目の値引継ぎ
下記によると、disabledにした項目もhiddenを用意しておくと引き継げるとあるのですが、引き継げませんでした。
たしか、この２つは引き継がれたと思います。
- selectManyCheckbox
- selectOneMenu
が、その他はうまくいかなかったように記憶してます。
- inputRadio
- selectOneRadio
- selectBooleanCheckbox
hiddenの位置によっても、動作が変わっていたように思います。
また、disabledの項目を送信（サブミット）してしまうと、サブアプリケーションスコープやページスコープで保持していても、空の値で上書きされてしまっていたと思います。
結局、ラジオボタンやチェックボックスにdisabledは使いませんでした。
どうしたかというと、
通常は、入力項目だけど、ある条件のときは表示だけしたいという場合、disabledにせず、spanとかdivを使った表示に切り替えるというようにしました。
（値はページスコープとかで保持）
もちろんテキストボックスとかは、readonlyで大丈夫でした。
あと、hidden定義するときの名前が、
aaa-hidden
と書いてあるサイトと、
aaa-hid
と書いてあるサイトがあって、どっちが本当かなとも思ってます。
どっちも正しい？
（リニューアルされたサイトに書かれているか確認してないですが）
Teeda クエリーストリングによるプロパティ値の上書き
少し早く帰れたので、時間があるときになるべく更新します。
クエリーストリングを使った場合、クエリーストリングのパラメータ名と、Pageで定義しているプロパティ名が一致している（setterがある）と自動で上書きされるようです。
（たぶんこれは仕様）
たとえば、次のような場合です。
- URL：http://xxx/view/xxx/xxx.html?prop1=abc
- XxxPageクラスのprop1プロパティは、abcで上書きされる。
- setProp1メソッドがあると上書きされる。
- setProp1メソッドがなければ上書きされない。
このことを、あまり気にせず作ると、次のような場合、問題になりそうかなと思います。
入力画面(xxxInput)→確認画面(xxxConfirm)→完了画面(xxxFinish)
という遷移があるとし、確認画面のボタン押下（doXXX）でDB更新しにいくとします。
このとき、入力画面での入力値(項目prop1とする)を、
サブアプリケーションスコープのプロパティで定義しているとします。
また、確認画面ではこのprop1の値を表示するとします。
（通常、だいたいこんな作り方すると思うのですが。）
確認画面に移ってから、ブラウザのアドレス欄から確認画面のURLにクエリーストリングprop1を付けて画面表示すると、prop1の値は上書きされます。
確認画面では、Validatorもつけていないでしょうから適当な値入れられたり
useridのようまキー項目だと、勝手に人のデータを書き換えられたりするかも？？
気にしながら作れば問題ないと思いますが。
（previousViewIdで画面遷移チェックしたり、paramプロパティ付けてチェックしたり）
- 【追記】
- 対策考えていたときには、アノテーションで自動上書きしないみたいなのができても良いかなと思っていました。
Teeda @ByteLengthはデフォルトエンコード
もう１つ思い出しました。
バイト数についてのValidator
@ByteLength
ですが、デフォルトエンコードが使われているため、気をつける必要があるようです。
プラットフォームが変わると、バイト数が変わってしまいます。
ただ、自分でValidator用のannotation作れば簡単に対応できます。
↓みたいな感じでよかったような。
@Retention(RetentionPolicy.RUNTIME)
@Target( { ElementType.FIELD, ElementType.METHOD })
@Validator("TByteLengthValidator")
public @interface XXByteLength {
int minimum() default -1;
int maximum() default -1;
String target() default "";
String minimumMessageId() default "";
String maximumMessageId() default "";
String charSet() default "Shift_JIS";
}
Teeda レイアウトのパーツ部分でエラーが起きた場合
Teedaのレイアウト機能を使うと、１つの画面を複数のHTML（Pageクラス）で構成することになります。
これら画面は、次の２つに分類されると思います。
- メイン部分（アドレス欄に表示されているURLが示す画面）
- レイアウトのパーツ（ヘッダやフッタ、メニューなど）
このうち、レイアウトのパーツにあたる部分でエラーが起きると、メイン部分のinitializeメソッドが呼ばれないようです。
この結果、メイン部分にプルダウンやラジオボタンがあると、空の項目だけになったり、表示されなかったりします。
たとえば、レイアウトのパーツ部分にテキストボックスがあり、その項目でバリデーションエラーやAppFacesException（Messagesにメッセージを表示するようなエラー）が発生した場合です。
実際のアプリケーションですと、ログインフォームとかがある場合が当たるかなと思います。
現在のTeedaのレイアウト機能としては、未対応なのかもしれません。
対応としては、
メイン部に入力がある場合は、レイアウトのパーツ部分にはエラーが発生するような処理をしないようにするといった感じでしょうか。
このような設計はしないようにしないといけないようです。
Teeda AJAX関連のエラー
Teeda AJAX関連でうまく動作しなかったものを挙げます。
- GridとdoOnce(te:renderJs)を同時に使うとJavaScriptエラーとなる。
- doOnceでte:renderJsが、FireFoxだとJavaScriptエラーになる。
- FireBugが入ってるとなるだけかも？
結局、te:renderJsは使わないことで対応しました。
使い方が悪かっただけかもしれないです。
doOnceはあるとありがたい機能だと思います。
