1001コメント284KB

国産DIコンテナSeasar その15

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2009/03/17(火) 20:48:19

0137デフォルトの名無しさん

2009/05/24(日) 04:26:38

ｷﾘｯ

0138デフォルトの名無しさん

2009/05/24(日) 07:06:40

だっておｗｗｗっｗ

0139デフォルトの名無しさん

2009/05/24(日) 07:14:36

クスクス

0140デフォルトの名無しさん

2009/05/24(日) 08:15:40

で、結局、slim3の通常のrdbms操作は何使えばいいのさ

0141デフォルトの名無しさん

2009/05/24(日) 14:49:15

>>134
>>136

どうなんだろうね。JavaEEに関して悲観的になっているのが、少し気になるね。
GAEに意識が集中しているようで、もちろん僕よりも業界や幅広い技術的な情報を収集している人だろうけど、
完全にさ、Struts系のフレームワークを捨てるとなるとさ、僕なんか少しがっかりしちゃうよね。
新しい事に挑戦するとこは悪いことではないので否定はしないけど、Struts系のフレームワークを
完全に捨てる方針は、もう少し慎重に判断してもらいたいと思いますね。

0142デフォルトの名無しさん

2009/05/24(日) 16:13:39

>>140
GAE/JでRDBは使えないから心配するな

>>141
GAE/J専用フレームワークSlim3でStrutsを捨てただけ
SAStrutsが捨てられたわけじゃない

0143デフォルトの名無しさん

2009/05/24(日) 16:25:51

日本語読解力が弱い人が多いと思う
だからMLで聞けないで掲示板で一方的に懸念を表明する

0144デフォルトの名無しさん

2009/05/24(日) 17:03:33

>>142
そうですか。GAEに関しては調べましたが、僕の視点からはPHPと同レベルに見え、
スクリプトレベルの開発環境と判断。したがって、僕の視点からはGAEは軽視しますね。
僕としては企業用のコアなJavaEEの方が、好きだけどね。
仮にSeasarがGoogleとの互換性を重視するあまりに、軽量なJavaを選択するのであれば、
僕としてはSpringに移行する事も想定に入れなければならない。

0145デフォルトの名無しさん

2009/05/24(日) 17:04:49

ｽﾘﾑｻﾝがテストで対応してる環境に対して
それは方向性が違う俺たちは捨てられたとか騒ぐなよ
アホかお前ら

0146デフォルトの名無しさん

2009/05/24(日) 17:06:36

>>144
僕はバカまで読んだ

0147デフォルトの名無しさん

2009/05/24(日) 17:10:39

好きなら文句言わずにJavaEE使ってればいいと思うんだけど

0148デフォルトの名無しさん

2009/05/24(日) 17:16:28

GAEがPHPと同レベルって笑うところ？笑えないけど

0149デフォルトの名無しさん

2009/05/24(日) 17:21:39

slim3はseasarじゃないって知らない人がいるね

0150デフォルトの名無しさん

2009/05/24(日) 17:23:35

アホだから直接ｽﾘﾑｻﾝのblogで質問したりMLに投げたりできないんだろ
違いますよ何言ってるんですかって1秒で言われて終わりになるのが
自分でも解ってるから

0151デフォルトの名無しさん

2009/05/24(日) 17:25:28

>>147
ひがやすを氏が、SeasarとSlim3のプロジェクトを兼務しているので、論理が倒錯する局面が発生するので、
ユーザーとしては、そういう時に若干戸惑うかもしれないね。

0152デフォルトの名無しさん

2009/05/24(日) 17:31:28

>>144
Seasar2もSpringもJ2EEに対するアンチテーゼとして生まれ、
当時は軽量コンテナと呼ばれていた
これ豆知識な

0153デフォルトの名無しさん

2009/05/24(日) 18:12:07

どなたかSeaser.NETをお使いの方いらっしゃいませんか？
利用実績がある程度あればプロジェクト採用になるのですが・・・

0154デフォルトの名無しさん

2009/05/24(日) 20:47:40

>>153

どうなんだろうね。僕はJavaしかやったことがないで、解らないけど誰か.NET詳しい人います？
.netでもさ、S2Daoと同じ仕様なんで、例えばデータベースアクセスの際にVersionNoやTimestampによる
排他制御が実装されている。僕は.netでもSeasarを使う利便性は高いと思うけどね。

0155デフォルトの名無しさん

2009/05/24(日) 20:55:05

.NETならS2よりEnterprise Libraryのほうが提案しやすいけどな

0156デフォルトの名無しさん

2009/05/24(日) 20:55:34

>>153

うちではQuillつかってるよ。

DotNetって標準のWindowsFormsじゃあちょいとばかり非力だし
生のAdo.Netは使いにくいし、LinQforAdo.Netはカオスだし
S2Dao＋Quillコンテナは、なんだかんだで便利。

まあ個人的にはDBアクセスはIBatis.Netのほうがいいじゃんって気もするけど。

0157デフォルトの名無しさん

2009/05/24(日) 21:13:19

>>141
嫌いなら別に使わなくていいと思う。
Servlet/JSPやJTAもJavaEEだから使うのやめればいいのに。
1からサーブレットAPIもどきから作るといいと思う。

0158デフォルトの名無しさん

2009/05/24(日) 21:15:03

みんなでGAE/Jすりゃ怖くないってか

0159デフォルトの名無しさん

2009/05/24(日) 21:36:24

GAE はまだまだ趣味レベルとしか見られないな

0160デフォルトの名無しさん

2009/05/24(日) 21:54:04

GAEのJava自体がまだテスト段階なんだから当たり前だと思うが

0161デフォルトの名無しさん

2009/05/24(日) 22:19:12

>>154 155 156
サンクス、助かります(;´Д`)
Enterprise Libraryはあまり馴染みがないのですが、
MS謹製ならちょっと考えようと思います

0162デフォルトの名無しさん

2009/05/24(日) 22:47:19

>>153
そういやSpringにも.NET版があるけど、どれ位使われているのかな？

0163デフォルトの名無しさん

2009/05/24(日) 23:56:22

>>162
それは、spring板の人に聞いてよ。でもさ、僕の視点では国産DIを利用した方がいいよ。付随するSAStrutsも高機能だからね。
前々、から言おうと思っていたけどさ、DAOクラスでさ、排他制御も書けない人がspringなんて使っても意味ないよ。

0164デフォルトの名無しさん

2009/05/25(月) 00:08:23

.NET版にもSAStrutsがあるのか。初耳だ。

0165デフォルトの名無しさん

2009/05/25(月) 01:06:10

ないよ
ってか事例だったらMLで聞いたら嫌でも殺到するのになんでまたこんな所で

0166デフォルトの名無しさん

2009/05/25(月) 01:08:33

PHP版はMapleとかあるけど、.NET版はかなり放置プレーだな

0167デフォルトの名無しさん

2009/05/25(月) 01:11:26

僕はJavaそしてSeasarを推薦するよ。S2Daoについて、僕が解りやすく説明するよ？
VersionNoでの排他制御に関しては、PrimaryKeyに属する行の内容を更新する際に、
VersionNoが自分の取得したVersionNoと異なるケースでは、他のユーザーが同じ行を先に更新している事になるので、正確な排他ができる。
Timestampでの排他制御に関しては、PrimaryKeyに属する行の内容を更新する際に、
Timestampが自分の取得したTimestampと異なるケースでは、他のユーザーが同じ行を先に更新している事になるので、正確な排他ができる。

Webシステムにおいては、多数の人が同時に同じDBにアクセスする事になるので、排他制御が抜けているシステムは致命的になる。

0168デフォルトの名無しさん

2009/05/25(月) 02:20:42

しかしながら、S2Daoの排他制御は不完全である。
理想としては、画面表示のselect時にVersionNoとTimestampを取得する仕様が好ましい。
今のS2Dao仕様では、Daoレベルでのデータベース更新の瞬間的な排他制御はできる。
そうではなくて、画面表示のselect時にVersionNoとTimestampを取得し、
｢画面単位｣で排他制御を行うのが正しい。S2Daoの排他制御もまた素人臭い。

0169デフォルトの名無しさん

2009/05/25(月) 02:36:38

カンファレンスにｷｼﾀﾞﾀﾝでないかなぁ

0170デフォルトの名無しさん

2009/05/25(月) 02:40:23

>>168の訂正

失礼、ActionクラスからselectしDTOからActionFormに詰め替え際に、VersionNoあるいはTimestampもActionFormにsetする。
データベース更新時は、ActionFormからDTOに詰め替えする際に、select時に取得したVersionNoあるいはTimestampを
DTOに設定する事で、画面単位での排他制御が実現できる。

0171デフォルトの名無しさん

2009/05/25(月) 03:07:04

これができていないWebシステムはゴミだ。

0172デフォルトの名無しさん

2009/05/25(月) 03:29:32

若干混乱したので要約すると、

>>167○この概念はSeasarの公式にも書かれているので正しい
僕はJavaそしてSeasarを推薦するよ。S2Daoについて、僕が解りやすく説明するよ？
VersionNoでの排他制御に関しては、PrimaryKeyに属する行の内容を更新する際に、
VersionNoが自分の取得したVersionNoと異なるケースでは、他のユーザーが同じ行を先に更新している事になるので、正確な排他ができる。
Timestampでの排他制御に関しては、PrimaryKeyに属する行の内容を更新する際に、
Timestampが自分の取得したTimestampと異なるケースでは、他のユーザーが同じ行を先に更新している事になるので、正確な排他ができる。
Webシステムにおいては、多数の人が同時に同じDBにアクセスする事になるので、排他制御が抜けているシステムは致命的になる。

>>168×これは僕の認識の誤りである可能性が高い
しかしながら、S2Daoの排他制御は不完全である。
理想としては、画面表示のselect時にVersionNoとTimestampを取得する仕様が好ましい。
今のS2Dao仕様では、Daoレベルでのデータベース更新の瞬間的な排他制御はできる。
そうではなくて、画面表示のselect時にVersionNoとTimestampを取得し、
｢画面単位｣で排他制御を行うのが正しい。S2Daoの排他制御もまた素人臭い。

>>170○S2Daoの振る舞いが以下の使用に適合していれば、理想的な排他制御になる。検証してみなければ解らないが、暫定でできると仮定。
失礼、ActionクラスからselectしDTOからActionFormに詰め替え際に、VersionNoあるいはTimestampもActionFormにsetする。
データベース更新時は、ActionFormからDTOに詰め替えする際に、select時に取得したVersionNoあるいはTimestampを
DTOに設定する事で、画面単位での排他制御が実現できる。

>>171○ゴミです
これができていないWebシステムはゴミだ。

0173デフォルトの名無しさん

2009/05/25(月) 11:43:47

あ、いっぱい進んでる。

Rails使ったことないんだけど、
Railsはどのあたりが本質的で面白いか聞きたいのだけど、、、。

0174デフォルトの名無しさん

2009/05/25(月) 19:12:26

やべえ…
排他バカにみんな呆れて、過疎ってきた

0175デフォルトの名無しさん

2009/05/26(火) 00:31:44

>>168は楽観的ロック知らないのかなと思った
あと更新に失敗したら再度トランザクションやりなおしさせる処理が抜けてるシステムも多い

楽観的ロックは開発者に負担を強いるからね

0176デフォルトの名無しさん

2009/05/26(火) 00:41:32

>>168の言ってるのが楽観的ロックに見えるけど？

0177デフォルトの名無しさん

2009/05/26(火) 01:26:32

通常の楽観的ロックはトランザクション開始前に取得したものを使う

0178デフォルトの名無しさん

2009/05/26(火) 03:25:49

>>175
更新用データ取得時にバージョンカラムの値も取得しておいて
画面上ではhidden値にでも入れておいて
更新するときのBeanにその値を詰めておくだけだろ
アップデート文はFWが自動発行してくれるんだし
この程度を負担とか言っていたら、何も任せられないよ

0179デフォルトの名無しさん

2009/05/26(火) 08:16:32

>>178
負担ってのはどう考えても更新失敗時の例外処理の面倒さだろ。

0180デフォルトの名無しさん

2009/05/26(火) 13:34:25

節子、それ楽観ロックやない、悲観ロックや

0181デフォルトの名無しさん

2009/05/26(火) 13:54:48

>>178 が言っていることも楽観的ロックだと思うけど？

悲観的ロックというのは、その画面を誰かが開いている間、
ロックテーブルとかにレコードを入れて、他のユーザは強制的に入れないようにするような手法だと思っています。

0182デフォルトの名無しさん

2009/05/26(火) 18:26:02

そうだね。S2Daoによる楽観的ロックを行い、
後はさ、ユーザーに最終更新日によって確認してもらうのがいいよね。
楽観的ロックでもさ、多数のユーザーが同時に同じ操作を行った際には、
エラーメッセージによって、PrimaryKeyや名称を表示して、
「他のユーザーが同じ操作を行っています。
しばらく待つかまたはシステム管理者にお問い合わせください。」等の
メッセージとしてユーザーに対するお知らせが可能になるよね。
但し、この排他制御はユーザーが同時に同じ操作を行ったケースなんで、
5分前や1時間前に更新されたケースに関しては、
最終更新日の表示によってユーザーに気をつけてもらうしかなかなか方法がないよね。
もちろん、間に承認システムやバッチ処理があれば、
承認者が重複等の異常に気づくことも可能ではあるし、
そういった方式を取ることもあると思いますが、
後はさ、お金が絡む対象も存在するのでログテーブルも必要でしょう。

こういう事も考えていくとさ、僕なんかはやっぱりJavaEEを採用する方がいいと思うけどね。
単純でリスクの少ないWebアプリであれば、何を使用してもいいと思うけど、
実際に企業用のWebシステムとなると、こういう事もきちんと実装しないと正常稼働しないからね。
もちろん、僕はさ、ほらIT志望の大学生なんで、まだ皆さんよりは詳しくはないんですが、
話がSEよりになってしまっているので、プログラミング技術よりの話を展開していくのがいいと思いますし、
実際に、Webシステム作って排他制御とAOPを検証してみるよ。

0183デフォルトの名無しさん

2009/05/26(火) 19:12:59

５分前だろうが１時間前だろうが、更新用に取得したデータを
他に誰も更新していない状態で自分が更新したときにだけ成功するのだから関係ない

あと、JavaEEで楽観的排他をサポートしているのはJPAだが、
基本的にやってることは同じだから特に違いはない

0184デフォルトの名無しさん

2009/05/26(火) 21:22:47

>>178がいってるのはアプリケーションコントロールのロックな
更新時には悲観的ロックかもしれない

0185デフォルトの名無しさん

2009/05/26(火) 21:25:23

>>181
おいおい
このスレでわかりやすい嘘つくんじゃない

0186デフォルトの名無しさん

2009/05/26(火) 21:49:34

>>183

そうだね。DBの仕様が通信販売や予約システム等の早い者勝ちの仕様であれば、
あるいは銀行等の常に上書きされべき対象であれば、楽観的ロックだけで済む問題だけど、
民間企業用のさ、顧客に対する情報の更新等は、複数の担当者が重複して入力する可能性もあるので、
それは楽観的ロックだけでは、回避できないって話だよ。

0187デフォルトの名無しさん

2009/05/26(火) 21:52:55

>>183の追記

失礼、銀行のDBであれば参照用からマスターへの更新の際には、整合性チェックも含め
間に、承認やバッチ処理が必要だけどね。わかりやすく表現しただけなんで、そこの差異は理解して貰えると思います。

0188デフォルトの名無しさん

2009/05/26(火) 21:55:50

ジミ・ヘンドリックス
グリーン・デイ
ニルヴァーナ
チャック・ベリー
エルヴィス・プレスリー
ローリング・ストーンズ

0189デフォルトの名無しさん

2009/05/26(火) 22:02:18

ロックしないのに楽観的ロックって言葉が変だよね
ビールじゃないのに第三のビールみたいでさ

0190デフォルトの名無しさん

2009/05/26(火) 22:04:42

>>186

こういったケースでは、楽観的ロックだけでは回避できないので、画面に表示されている最終更新日によって、
ユーザーに変更していいのかを判断してもらいたい。また、間に承認システムやバッチ処理があれば、
重複した際に、承認者によって、どちらが正なのかを判断してらわなければならないということですよ。
その問題は、同時にシステム管理者への問い合わせとして、誰がいつどのDBを変更したかを把握しなければならないので、
ログテーブルも必要でしょう。と、僕がおっしゃってるわけですよ。

0191デフォルトの名無しさん

2009/05/26(火) 22:15:52

>>188そっちのロックじゃねぇ

0192181

2009/05/26(火) 22:19:35

>>185
え、ちがうの？？

○楽観的ロック：

・画面表示(HTML 表示時)に、そのレコードの version_id なり最終更新日時を hidden で持たしておく
・HTML にデータを入力して submit 後、サーバサイドに渡ってきた version_id や最終更新日時を where 句にして

　select * from HOGE where 受注番号 = **** and versin_id = {画面から渡ってきたもの} for update

　して、レコードが取得できればそのまま update 文で更新
　レコードが取得できなければ、version_id がインクリメントされていることが考えられるので、
　画面に「他のユーザがすでに更新しました。データを再検索してください」

　こんな感じ

○悲観的ロック：

　ある画面を開いた時点で、その画面に排他制御をかけ、誰も入れなくする
　（業務仕様上、その画面が編集するテーブルは、その画面でしか更新できないことが条件)

だとおもっていたよ。

誰か添削してくれ

0193デフォルトの名無しさん

2009/05/26(火) 22:34:31

>>192
いちいちせぇctしないでうpだてすりゃいいだろjk

0194デフォルトの名無しさん

2009/05/26(火) 22:41:29

>>190の追記

楽観的ロックでも悲観的ロックでも、同じ振る舞いになる。

0195デフォルトの名無しさん

2009/05/26(火) 23:02:58

>>192
悲観的ロックがすごいな
俺ならそんなシステム使いたいと思わない

>>194
俺も回避できないからどうリカバリーするかを考える方が好きだ

0196デフォルトの名無しさん

2009/05/26(火) 23:04:30

>>192
それはアプリケーション制御の話。つまりただの仕様であり運用方法。

通常楽観的ロックや悲観的ロックというのはDBアクセスで読み込み中心ならば
ロックをかけないようにしよう、後から来たほうはトランザクションをリトライさせればいいんじゃね?
というお話だからミリ秒単位のお話。

だからリトライ制御等がはいってないのは楽観的ロックですらなく、書き込みもそれなりにあるのならば
普通に悲観的ロックをかけたほうが良い。

よくあるATMでの振込みと引落の同時アクセスを考えてみると良い。

ただ、読み込みでロックかけるようなDBなら楽観的ロックのほうが有利にはなりやすい可能性あり。

楽観的ロックというのはデータベースのロックを積極的に利用しようという話ではないので
開発者側に負担を強いる方法。楽観的であれ短い時間だろうが更新時にはどうせロックかけるので
実はアクセス順序を意識しないとデッドロックの可能性が普段から意識する悲観的ロックより
大幅に増える。IF文等によりアクセスするテーブルや行が変わる可能性があるからね。

0197181

2009/05/26(火) 23:05:15

>>195
おっしゃるとおりなので、悲観的ロックをかける場所は、
たとえば「年次締めバッチ起動画面」など、重要で、誰か一人しか使えなくすべき画面にのみに適用し、
普通のところは、 >>192 の楽観的ロックを使う、と思っているのですが。

0198デフォルトの名無しさん

2009/05/26(火) 23:12:33

I do not recommend that you use Teeda if you could not read the document.
（´；ω；）ｶﾜｲｿｽ

0199デフォルトの名無しさん

2009/05/26(火) 23:13:01

なんで今更こんな話題で盛り上がってる？
POEAA読めば終わりだろ？読んでないの？素人？

0200デフォルトの名無しさん

2009/05/26(火) 23:36:49

>>199
たまには動物園に行きたくなるだろ？

0201デフォルトの名無しさん

2009/05/26(火) 23:42:34

>>193
俺もupdateのwhere句に条件加えればいいじゃんと思うんだが

0202デフォルトの名無しさん

2009/05/26(火) 23:57:59

>>199
まあそういうな
s2コミッタ＝素人
s2ユーザ＝ど素人
なんだからさｗ

0203181

2009/05/26(火) 23:58:45

>>193 >>201
select .... for update してレコードが取得できたかどうかをせずに、
いきなり update 文を実行した場合、
update 文の結果(PreapredStetement#exeucte())で、0 が返って来た場合、
version_id がずれて更新できなかったのか、
そもそも、当該受注番号のレコードが、一瞬先に別ユーザによって消されたのかわからない。

select .... for update してレコードが取得できたかチェックしておいて、レコードが得られなかったら、
「他のユーザがすでに更新しました or 他のユーザがそのデータを消しました」
とエラーメッセージを出すことが出来る。

とここまで書いたが、いきなり update 文を実行して、update 文の結果が 0 だったら、
同じようなメッセージを出せばいいのか。

画面で、ユーザにもう一度画面を開いてもらい、当該受注番号のレコードが消されたら、
画面を開き直したときに、そのレコードは現れなくなるし。

0204デフォルトの名無しさん

2009/05/27(水) 00:20:41

おやすみ僕ちゃんｗ

0205デフォルトの名無しさん

2009/05/27(水) 00:33:30

一生懸命にたくさんの長文を書いてくれたけど、
どうしてJavaEEのほうがいいという結論に達したのか、全然わからなかった。

0206デフォルトの名無しさん

2009/05/27(水) 00:35:25

ぶっちゃけどれでもいいよね
実装が違うだけで目的は同じなんだから
JavaEEでもできるだろうけど他でもできるわけで
だからといってJavaEEが最高ってことにはならん

0207デフォルトの名無しさん

2009/05/27(水) 00:38:23

僕ちゃんがJavaEEわかってるわけないに1票

0208デフォルトの名無しさん

2009/05/27(水) 03:10:52

>>203
実際のところ、楽観的排他制御対応を謳っているFWはほとんど
UPDATE文にバージョンカラム値を条件に加えて、結果が０だったらエラーにする実装をしている
更新なのか削除なのかは、エラー後に再検索して判断する
そもそも「楽観的排他」は「あまり起こらない」ことを前提として、起こった場合は最初からやり直し
という方針で採用されることが多いから、SELECT FOR UPDATEを使う実装は少ないと思う
（オプションによって、一度空更新してトランザクション的なロックをかけたり・・・とかはあるけど）

0209デフォルトの名無しさん

2009/05/27(水) 05:59:32

>>196ありがとう

楽観的ロックでは、1つのトランザクションで複数のテーブルまたは複数のレコードを更新する際には、
デッドロックやそれに伴うデータの不整合になる危険性がある。したがって、1つのトランザクションで
1つのテーブルと1つのレコードを更新する事によりデッドロックの回避が可能になりますが、
これに基づいてDB設計と画面設計は相当慎重に行うべきである。また、S2Daoの排他制御は楽観的ロックなんで、
標準的なDaoクラスでDriverManager.getConnection().setAutoCommit(false)の設定をして
SelectForUpdateによる悲観的ロックを採用した方がシンプルでいいかもしれないね。

加えて、1つのトランザクションで複数のテーブルまたは複数のレコードを更新するケースでは、
rollbackを行えば、データの不整合は改善されるが、Webシステムで更新順序によるデッドロックの回避が
できるのかについては、現時点では僕の把握ではできないと思ってる。

0210デフォルトの名無しさん

2009/05/27(水) 06:15:43

>>209の追加

要約すると、
・1つのテーブルと1つのレコードを更新する仕様にする(デッドロックが起きないケース)
・デッドロックが起きた際には、rollbackよって回復する(デッドロックをrollbackによって回復するケース)

0211デフォルトの名無しさん

2009/05/27(水) 07:42:20

SelectForUpdateによる悲観的ロック()笑

やはりこの程度の認識だったのか・・・

0212デフォルトの名無しさん

2009/05/27(水) 08:33:38

select for updateで悲観的ロックになると思ってたのかよ。

0213デフォルトの名無しさん

2009/05/27(水) 08:41:39

悲観的ロックだろうが楽観的ロックだろうが、
複数テーブルを更新するときはFOR UPDATEを付けるし、
設計次第ではデッドロックも起きる。
そこは悲観的・楽観的とは関係ないんだよ。僕ちゃん。

0214デフォルトの名無しさん

2009/05/27(水) 08:47:22

>>210

さらに要約すると、排他制御はSelectForUpdateによる悲観的ロックを行い、デッドロック対策としては
1画面に可能な操作は、1つのトランザクションで1つのテーブルと1つのレコードを更新するだけに限る。
また、最終更新日を表示することにより、ユーザーによって変更してもよいデータであるかを判断してもらう必要がある。

0215デフォルトの名無しさん

2009/05/27(水) 09:31:39

>>214の追記

これを実現する画面設計としては、検索リストから詳細画面へ遷移し、登録/更新/削除を行う。
DB設計も、1画面に可能な操作は、1つのトランザクションで1つのテーブルと1つのレコードを更新する事を踏まえ
データモデリングしていく必要があるね。

0216181

2009/05/27(水) 11:03:15

でもいいのですが、
181=192=197=203 です。

182=209 、その他ではありません
(まぁ似たようなレベルかも知れませんが)

0217デフォルトの名無しさん

2009/05/27(水) 11:10:48

まぁ、一言で表現すると、スレッドセーフになるね。

0218デフォルトの名無しさん

2009/05/29(金) 14:09:32

ｾｯｼｮﾝすくねーw

0219デフォルトの名無しさん

2009/05/30(土) 00:51:17

確かにえらい寂しいな。
しかも事例紹介を大部屋でやって、ひがさんのセッションを30人の部屋でやるとは…

0220デフォルトの名無しさん

2009/05/30(土) 00:57:08

ｽﾘﾑｻﾝはSlim3の発表がメインなんじゃね

しかし実務やってる人には新技術より事例発表の方があるから人は集まるだろうけど
実例がSAStrutsとかみたいな今企業でよく使われるような物じゃないから
微妙なんだよなぁ

0221デフォルトの名無しさん

2009/05/31(日) 01:06:48

S2クリックとS2クロノスがいっぱい聞きたかったけど
15分か。。

0222デフォルトの名無しさん

2009/05/31(日) 01:10:04

携帯の事例発表とmobyletのセッション同時間にやるのってなんの嫌がらせなの

0223デフォルトの名無しさん

2009/05/31(日) 02:59:51

>>222
今からメールしたら、変えてくれるかも。
Seasar カンファレンスは、いつも聞きたいのが重なりすぎて困る。

0224デフォルトの名無しさん

2009/06/01(月) 22:55:40

@Resource(arg="@Arg(arg1="aaa",arg2="bbb",arg3="ccc"))
SearchSearvice searchSearvice;

てな感じで、SearchSearviceのオブジェクトのコンストラクタとかプロパティにデフォルトで値をセットできればええのになぁ。

0225デフォルトの名無しさん

2009/06/02(火) 00:13:35

別に普通に要素に代入すりゃええやん
アノテでやったら型が違ってたら何処でエラー出てるのか解らん

0226デフォルトの名無しさん

2009/06/04(木) 13:30:45

オレはむしろ
@Resource(arg="@Arg(arg1="aaa",arg2="bbb",arg3="ccc"))
SearchService searchService;

てな感じで、SearchSearviceのオブジェクトのコンストラクタとかプロパティにデフォルトで値をセットできればええのになぁ。
と思うぞ。

英語勉強しろよ。

0227デフォルトの名無しさん

2009/06/04(木) 17:39:14

例えばarg1がDateだったらどうすんの
タイプセーフにならんだろ

0228デフォルトの名無しさん

2009/06/04(木) 23:59:48

SAStrutsでつまってる。FormにMapを使いたいんだ。

form.TestForm.java に、
public Map<String,String> testMap;
を宣言して、
action.TestAction.java で
@ActionForm
@Resource
public TestForm testForm;
とした。
jspに、
<html:text property="testMap(test)" ></html:text>

として、入力した値が、testMap.get("test")で取れるようにしたい。。しかし、、
java.lang.UnsupportedOperationException: get
org.seasar.struts.action.ActionFormWrapper.get(ActionFormWrapper.java:113)
と出てしまう。どこか間違ってるか別の方法があるか、、、教えてえろいひと

0229デフォルトの名無しさん

2009/06/05(金) 00:18:01

ちょっと酷すぎてまず何を伝えればいいのか迷ってる
testMap(test)ってそもそもなんなんだよ

0230デフォルトの名無しさん

2009/06/05(金) 00:24:26

イロイロと初心者で面目ない…書式とか間違ってるのは勘弁を…
やりたいことはsubmitした時のアクションでtestForm.testMap.get("test")で取れるようにしたいんだ。。
testFormに
public String test;
とは置きたくないんだ。Mapに自由に格納したいのだです

0231デフォルトの名無しさん

2009/06/05(金) 00:27:17

いやだからその自由にって部分をだれかが実装してるの？
マニュアルに載ってなくてお前も実装してないならだれもそう実装してないってことでしょ
BeanUtilの該当箇所ラップして自分でカスタマイズしなよ

0232デフォルトの名無しさん

2009/06/05(金) 00:35:33

>>230
HttpServletRequestから取ってくればええやん

0233デフォルトの名無しさん

2009/06/05(金) 00:45:12

フレームワーク使わなければい（ｒｙ

0234デフォルトの名無しさん

2009/06/05(金) 00:52:43

ﾌｲﾀ

0235デフォルトの名無しさん

2009/06/05(金) 00:55:22

S2に限らず、フレームワークスレでいつも思うけど、
素で書いたら簡単にできるのにこのフレームワークはこんなこともできないんですか！
みたいな質問が多くて、じゃあフレームワーク使わないで素で書けよって思うことは多々ある。
自由な開発の弊害で苦労して一周回った上で、規約を縛ることの必要性を経験しないと理解できない部分なのかもね。

0236デフォルトの名無しさん

2009/06/05(金) 06:58:31

s2clickかs2wicketならできそう
sastrutsはstrutsに縛られてるから仕方ない部分がいくつかある

■ このスレッドは過去ログ倉庫に格納されています