SQLファイル内のOGNL式でクラスフィールドの参照ができない。
SQLファイル内のOGNL式でクラスフィールドの参照ができない。
初期のS2Daoではバインド変数コメントで、OGNLが使えましたが、
nullの時にバインド変数の方が決められないという問題が出たため、
"."によるプロパティアクセスしか認めないようになっています。
つまり、OGNLが使えないのは仕様です。
なるほどなあ。
/*IF value == @com.deftrash.enum@ONE.value()*/ AND value_ext IS NOT NULL /*END*/
という書き方はOKだけど
/*IF value != null*/ AND value=/*@com.deftrash.enum@ONE.value()*/1 /*END*/
という書き方はNGで展開されない。
定数フィールドを参照するときはどうしたものかしら。ハードコーディングは気持ち悪い。パラメータのオブジェクトに定数フィールド値への参照を持たせておけば良いのかな。面倒くさいけど。
SAStruts を改造した理由
SAStruts は非常によくできたフレームワークだと思います。そのまま使うことで十分なメリットを得られる。
それでも、例外的な要件や、社内独特のルールみたいなのも良くある話で、それをフレームワークに求めるのは酷だ。そこは今までどおり、みんなで Struts を改造して、Spring を改造しながら使ってきたように、SAStruts を改造しながら使えば良いかなと思っている。何より、SAStruts は、要望に全て応えるような重厚なつくりでなく、結構淡白なフレームワークに敢えてなっている節がある。「ここ以上は作らないから、必要なら改造して何とか頑張ってね」というスタンスだと勝手に解釈して、改造して使わせてもらっている。ありがたや。
正直、SAStruts の枠からはみ出る要件や設計って、どうなのかと思う点もなくはない。
いわゆるローカル・ルールって保守性を下げる主因になる。先にも書いたように、改造のための保守コストも結構かかる。対応できる人材の確保も厄介だ。それとのトレードオフで、はみ出ることのメリットって、いかほどかな、と。見合っているのかな、と。もちろん見合っていると思ったから自分は改造したわけだけど、おいそれと「SAStrutsじゃコレができねーよ、使えねえなあ」という前に、もう一度自分の考えた方法のセオリーがどんなもんか、振り返ってみることも重要だなーと思った。
ちなみに連呼している「改造」というのは、ソースそのものに手を入れるのではなくて、RequestProcessor を入れ替えたりとか、そういう類のことです。「改造」じゃないんだけど、正しい日本語が思い浮かばない…。
SAStruts 1.0.4-sp2 リリース
SAStrutsがファイナルリリースとのこと。お疲れさまでした。
SAStruts 1.0.4-sp2をリリースしました。
リリースノートはこちら。
http://sastruts.seasar.org/releaseNotes.htmlダウンロードはこちら。
http://sastruts.seasar.org/download.htmlこのバージョンがファイナルリリースかな。安心してお使いください。
機能変更は今後ありません。
これで安心して改造したり機能追加できる。ここ半年くらい、リリースごとに改造部分と修正点を比較して、自分の方でもバグフィックスなり対応をしていた。最初からその覚悟はできていたんだけど、いざ初めてみるとツライ。半年で終わったのは、運が良すぎ。良かったあ。
不定貫商品のEC
不定貫商品の通販ってどうするんだろうと思ったら、結構あたりまえに行われていたのでビックリした。
「不定貫」というのは、1製品あたりの重量が決まっていないもので、スーパーの精肉コーナーで、豚バラブロックの全パックで重さと値段が違ってるアレのこと。
これを通販するには、スーパーの売場のバーチャル化ということで、商品アイテムとして「ブロック320g 640円」、「ブロック290g 580円」みたいに用意しないといけないかと、まずは考えた。でも、重量が決まった商品が並べられるということは、要するに在庫が確保できているということ。在庫リスクがあっては、メリット無いからおいしくない。却下。
在庫を持たないためには、「豚バラブロック 2円/g」という商品アイテムを用意して、それをどのくらいの分量だけ買うか指定させる形式にすれば良いか。これは、街のお肉屋さんの対面販売のバーチャル化。けれども、極端な話、ブロックを2gで売るわけにはいかないわけで。ブロックは、ブロックとして売りたいから、これもダメ。
仕入れてみるまで、量も価格も不透明な商品を、どう商品アイテムとして扱うのか。そんなことできんのかと思ったら、世の中もっと曖昧で良いみたい。平均重量と平均価格でもって、カートに入れてもらう。仕入れた時点で、重量と価格が決定して、それで精算しようという。それで良いのか。よほど金額差がなければ不問なんだろう。
不定貫とは言え、ある程度、誤差の範囲が見えているからこそできるんだろうな。さすがに、仕入れたらいくらになるか見えない商品を買う人ってのは、いないだろう。でも、そういう商品アイテムのある通販も存在するのかな？
validwhenでハマる
ハマると言うほどのことでも無かったのだけど、2つ値が一致しているかどうかというvalidwhenを書いたが、これが思ったように動かない。
<field property="foo" depends="validwhen"> <arg0 key="labels.foo" resource="true" /> <var> <var-name>test</var-name> <var-value>(bar != *this*)</var-value> </var> </field>
思ったように動かないというより、真逆の動きになる。よくよく考えてみれば、validwhen だから、テスト式が成立のときに valid という意味なんだよね。なぜか勝手に脳内で、「このテストが成立するときにエラーにする」という意味になっていた。ううう。
ということで
<var-value>(bar == *this*)</var-value>
で思うとおりの動作になりました。
パスワードの確認欄との整合性チェックなんかの場合に、有用でしょうか。今回は鍵認証で使ったんですが、まあ似たようなもんでしょう。
LinkageError の原因判明
HotDeploy 対象でない Util クラスにて、HotDeploy 対象の Dto を引数で受けるような作りになっていたのが原因だった模様。
public class SampleUtil { public static String getName(SampleDto sampleDto) {
という、やり方がマズかった。引数の型にとるだけでも、クラスローダの問題が出てくるのかあ…。うむむ。そんなわけで、SampleDto を渡す代わりに、SampleDto のフィールドの値を複数、引数として渡すようにしたら問題なく動き始めた。
うーん、でもユニットテストするまでは、ちゃんと動いていたんだけどなあ…。根本を理解していないと、こういう綱渡りになっちゃうんだな。ふぅ。
