5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

△△さらにStrutsの良さを教えて下さいSession3

1 :デフォルトの名無しさん:04/07/04 01:09
jakarta Tapestryがいいのか? JSFがいいのか? それともApache Strutsがいいのか?

Apache Strutsフレームワークについて語るスレ

The Apache Struts Web Application Framework
http://struts.apache.org/

Strutsファンページ
http://homepage2.nifty.com/ymagic/struts/

Strutsメモ
http://muimi.com/j/jakarta/struts/
前スレ
△△もまいら漏れにStrutsの良さを教えてください
http://pc5.2ch.net/test/read.cgi/tech/1048030962/
△△つづいて漏れにStrutsの良さを教えてくだっさい
http://pc5.2ch.net/test/read.cgi/tech/1068207164/

2 :デフォルトの名無しさん:04/07/04 01:11
エクリプス+Struts開発
http://pc5.2ch.net/test/read.cgi/tech/1086356759/l50


3 :デフォルトの名無しさん:04/07/04 01:12
じゃあ、Velocityでいかがでしょうか?

4 :デフォルトの名無しさん:04/07/04 01:15
語ることも無いし。

5 :デフォルトの名無しさん:04/07/04 01:16
Tapestryについて語ろうよ!
http://pc5.2ch.net/test/read.cgi/tech/1067531714/

6 :デフォルトの名無しさん:04/07/04 01:19
>>1
よそすれに貼るのはいいが、あげるな。うっとおしい。

7 :デフォルトの名無しさん:04/07/04 01:50
Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/


8 :デフォルトの名無しさん:04/07/04 17:53
>>3
うーん・・・別にVelocityはフレームワークじゃないし。
Strutsと組み合わせても使えるし。

9 :デフォルトの名無しさん:04/07/04 18:16
Velocityってさ、普通にJSP+Strutsのカスタムタグでも
ほとんど同じ事できるよねぇ。

10 :デフォルトの名無しさん:04/07/04 18:17
VelocityってWebアプリとは関係ないから


11 :デフォルトの名無しさん:04/07/04 18:18
ベロシティーって何ですか?
MIDIの音量設定ですか?

12 :デフォルトの名無しさん:04/07/04 18:19
ベム!
ベラ!
ベロシチィ!

妖怪人間 じゃ〜ん!

13 :デフォルトの名無しさん:04/07/04 18:22
>>12
ちょっと静かにしてもらえませんか?

14 :デフォルトの名無しさん:04/07/04 18:27
>>11
Jakarta velocityの項を参照

15 :デフォルトの名無しさん:04/07/04 19:26
>>9
でも、JSP+Strutsのカスタムタグはややこしいよね。

16 :デフォルトの名無しさん:04/07/04 19:43
VelocityはJSPみたいにコンパイルが必要ないよ。
アホみたいに画面上部にJava関係のヘッダーつかないよ。

でも、Tapestryみたいにhtmlでは綺麗に表示できないよ。

そんな感じ。

17 :いなむらきよし:04/07/04 19:52
キケー!

18 :デフォルトの名無しさん:04/07/04 19:53
>>15
つうか、ELでOKな気が

19 :デフォルトの名無しさん:04/07/05 02:14
>>18
今となってはそうかもしれんな・・・。
ELもヒマな時に試してみておかないとなあ。

20 :デフォルトの名無しさん:04/07/05 02:27
>>18
ELとStrutsタグを使い分けるのが通。

21 :デフォルトの名無しさん:04/07/05 03:47
>>20
htmlタグだけね。
logicタグとか、あぼーん。

22 :デフォルトの名無しさん:04/07/05 08:38
>>21
beanタグ使わんでどーすんの

23 :デフォルトの名無しさん:04/07/05 16:11
>>22
beanタグが一番つかいものにならんでしょ。
strutsタグは代用きかんだろうけど。

24 :デフォルトの名無しさん:04/07/05 19:53
>>23
>beanタグが一番つかいものにならんでしょ。
>strutsタグは代用きかんだろうけど。

? ? ?

25 :デフォルトの名無しさん:04/07/05 20:05
>>24
beanタグの何使うの?
bean:strutsタグみたいな、Struts固有の動きをするもの以外は不要でしょ。

26 :デフォルトの名無しさん:04/07/05 20:13
>>25
>bean:struts
よくわかってないなら、黙ってる方がいいと思うよ・・・

27 :デフォルトの名無しさん:04/07/05 20:17
意味がかみ合っていないような気がするけど…
ここで言うStrutsタグというのは
struts-html.tld
struts-logic.tld
struts-bean.tld あと各el
これらを指しているんだよな?

>>23>>25は何を言いたいんだ?

28 :デフォルトの名無しさん:04/07/05 20:36
わかってないのは26、27あたりだと思ふ・・・・
24がbean:strutsタグをどう使うのかは興味津々だが。
しかも、代用効かない訳じゃない。
org.apache.struts.Globalsにある定数をキーにして
requestスコープに入ってるだけだから。
ソース見りゃ一目瞭然。

29 :デフォルトの名無しさん:04/07/05 20:45
でもcoreタグ使おうと思ってもスコープの違いがあるから
結局beanタグ使った方が楽、というかそうできてるし。

30 :デフォルトの名無しさん:04/07/05 20:46
strutsタグはvelocityっぽく使えていいと思うが。

31 :デフォルトの名無しさん:04/07/05 20:50
結局、coreタグとかlogicタグとか使いたおしたところで
MVCなんか全然分離できていないんだよな。
正確にはプレゼンテーションロジックが入り組みすぎてて結局よくワカンネっつーか。
それでもスクリプトレットよりはずっと見やすいからいいんだけど、
EL使いまくりのソースはそれでも汚く見えるよな。

32 :デフォルトの名無しさん:04/07/05 21:54
というわけでVelocity+Struts+Spring/Seasar+HibernateでFAでしょ。

33 :デフォルトの名無しさん:04/07/05 22:38
>>32
velocity使ったから解消するもんじゃないよ。
むしろstrutsのhtmlタグだけ使ってれば似たコードになるし

34 :デフォルトの名無しさん:04/07/05 23:51
カスタムタグをちゃんと使って、スクリプトレット0
ついでに複雑な制御文も0

35 :デフォルトの名無しさん:04/07/06 00:51
>>31
表示のためのロジックがVに入るのは、当たり前っちゃあたりまえ。

36 :デフォルトの名無しさん:04/07/06 00:53
>>29
ほんと?
JSTL + ELでもちゃんとスコープの指定できると思うけど。

37 :デフォルトの名無しさん:04/07/06 00:57
できればStrutsタグのみで済ませたいが、
どう考えても機能的に足りないので、JSTL使わざるを得ない

38 :デフォルトの名無しさん:04/07/06 00:58
おれは逆に、Strutsに依存するものよりは、標準のJSTL+ELで済ませたい。

39 :デフォルトの名無しさん:04/07/06 01:07
ELは見た目が汚いんだよなぁ…
それにELったってやってることがスクリプトレットと大してかわらんし

40 :デフォルトの名無しさん:04/07/06 01:46
strutsのbeanタグならかわるのか?

41 :デフォルトの名無しさん:04/07/06 01:55
正直、EL使うよりはわかりやすいと思うが、そのかわりできることが少ない。
まー併用だな。

42 :デフォルトの名無しさん:04/07/08 14:45
山田ナントカってつくづくいいかげんなヤツだと思ふ。
ヤツを切らない@ITも同罪。

@IT > Java Solution > Java TIPS >Eclipseで.warファイルを作成する
http://www.atmarkit.co.jp/fjava/javatips/043eclipse016.html
で「.warファイルは「Web Application Resources」の略」
なんて言ってる。

Servlet API 仕様2.3(servlet-2_3-fcs-spec)によれば

SRV.9.6 Web Application Archive File
Web applications can be packaged and signed into a Web ARchive format (war)
file using the standard Java Archive tools. For example, an application for
issue tracking might be distributed in an archive file called issuetrack.war.

だそうだ。


43 :デフォルトの名無しさん:04/07/08 16:20
そんなのどうだっていい

44 :デフォルトの名無しさん:04/07/08 16:34
>>43
42じゃないけど、仕様と違う略ってことになるのか気になる。
「わからなかったら推測で書く」という方針でかかれた記事なんか、怖くて読めん。

45 :デフォルトの名無しさん:04/07/08 16:52
>>44
同意。しかも断定調だしw
この人の書いた書籍(10日でわかる・・・・シリーズ)とか
Web上の記事をみてもとりあえず「ホントかな?」と疑ってかかるのが
習慣になってしまった・・・・

46 :デフォルトの名無しさん:04/07/08 17:33
そうやって大人になっていくんだよ

47 :デフォルトの名無しさん:04/07/08 17:35
オレは小人のままでいい。

48 :デフォルトの名無しさん:04/07/08 17:37
皮はむけたほうがいい。

49 :デフォルトの名無しさん:04/07/08 17:44
皮はパリっと焼いてたべようよ。

50 :デフォルトの名無しさん:04/07/08 18:19
おまいら、細かいこと気にしすぎ。
トリビアじゃあるまいし。

51 :デフォルトの名無しさん:04/07/08 21:17
>>45
それがねらいなんだよ。

52 :デフォルトの名無しさん:04/07/08 21:31
山田はわざとやってるだろ。これは。

53 :デフォルトの名無しさん:04/07/08 21:46
昔からUnix触ってる香具師なら、
arコマンドがARchiveからとったコマンド名だということを知ってるし、
tarコマンドがTape ARchiveからとったことも知ってる。
tarとコマンド体系を似せて作ったjarがJava ARchiveだということも推測できるし、
warはWeb ARchiveであろうことは当然の暗黙知である。
よって山田はアホ。

54 :デフォルトの名無しさん:04/07/08 22:04
これを知ったかぶりと言わずして何を知ったかぶりというのだろう。
百歩譲って「知らない」ことは許せてもしれっと嘘書くのはどうかと。
こんな奴、普通に一緒のチームにもいてほしくない。
ましてや、何の縁でこんなエバンジェリスト的な仕事を・・・

55 :デフォルトの名無しさん:04/07/08 22:29
>>54
プログラムの仕事が任せられないから、原稿書きにまわされた、とか。

56 :デフォルトの名無しさん:04/07/08 23:52
電波マンまたやっちゃったか。。

57 :デフォルトの名無しさん:04/07/08 23:56
またまたやなださんとやらの誹謗中傷か?おまえら名誉毀損で訴えられてもしらんぞw

さっさとstrutsの話でもシコシコしとれや

58 :デフォルトの名無しさん:04/07/09 00:00
これで訴えたら恥の上塗りだねw

59 :デフォルトの名無しさん:04/07/09 00:07
法律も知らんのだろうな。まぁせいぜい叩きまくってこのスレ1つくらいつぶせば
十分だろう。

60 :デフォルトの名無しさん:04/07/09 00:12
おいまいら、そんなに山田をいじめると、またこっそりと版管理無しで更新しちゃうぞ。
ttp://www.atmarkit.co.jp/fjava/rensai3/struts03/struts03_1.html

61 :デフォルトの名無しさん:04/07/09 00:13
つまらん、雑魚どもだ

62 :デフォルトの名無しさん:04/07/09 00:42
>>59
法律の問題ではない。
嘘を書いたことを法の場で明らかにされてでも訴えるかね?w
ってこと。
ヘタに動いて訴訟騒ぎ起こすよりより2ちゃんで雑魚が騒いでる程度にしておく方が賢明じゃないの?

63 :デフォルトの名無しさん:04/07/09 06:01
もう一度書いておく。
山田某は、M$マンセーの@ITがJava潰しの為に遣わした刺客。

64 :デフォルトの名無しさん:04/07/09 07:24
>>63
というか、単に書いている記事のレベルが低いだけ。
リファレンスとかに載っている文章を文体変えてるだけでしょ。

あれって、初心者向けには良いの?

65 :デフォルトの名無しさん:04/07/09 09:54
>>64
よいの。
・・・かな?

66 :デフォルトの名無しさん:04/07/12 09:56
1.2.1Betaリリースage

67 :デフォルトの名無しさん:04/07/12 09:57
ageてなかった・・・・qz

68 :デフォルトの名無しさん:04/07/12 22:10
Validatorを使ったiterate内のradioのチェックされているかの
チェックってどうやるんですか?
requireもききません。

69 :デフォルトの名無しさん:04/07/13 23:11
漏れにはstrutsが向いていない…ってかEJBが向いてない
ぜんぜんわかんねーもん

70 :デフォルトの名無しさん:04/07/13 23:37
>>69
どこに関連があるのか、と。

71 :デフォルトの名無しさん:04/07/14 00:25
>>70
だから向いてないんだよ

72 :デフォルトの名無しさん:04/07/14 00:29
そだね。

73 :デフォルトの名無しさん:04/07/16 09:06
Tomcat5.0.27リリースage

74 :デフォルトの名無しさん:04/07/19 18:49
message-resourcesが複数あり判別のために
key="xxxx"としている場合に 、
クライアント側でvalidatorを行いたい場合、
message-resourcesを判別するためのbundleを
どこで、指定すればいいのでしょうか?

validation.xmlの<arg0>では可変引数が無い場合指定できませんし、
実際そこにbundleを指定しても、

java.lang.NullPointerException
org.apache.struts.validator.Resources.getMessage(Resources.java:209)

と言われmessage-resourcesを見つけられていないようです。
validateメソッドを使う場合には

<html:errors bundle="xxx">

でうまくいくのですが、クライアントでの検証の場合うまくいきません。
クライアント側での検証を同じように行いたいのです。

もしどなたか方法をご存じの方いませんか?

75 :デフォルトの名無しさん:04/07/19 21:32
>>74
できねーよ。将来のバージョンで検討するって開発者MLで話題になってたことがあった。

76 :デフォルトの名無しさん:04/07/19 22:57
いまプロパティファイルの分割を検討しているんだが、
むずかしそうだな・・・
とりあえず分割して
デプロイ時にAntで結合すっか・・・

77 :デフォルトの名無しさん:04/07/19 23:30
Struts でいくつかのページを管理するんだけど、例えばどのページにアクセスするときでも最初に必ず認証チェックをする。
こういう場合って全てのアクションでいちいち処理する訳じゃないと思うのですが、何か手段が用意されてるんでしょうか?


78 :デフォルトの名無しさん:04/07/19 23:38
>>77
フィルター使えば?

79 :デフォルトの名無しさん:04/07/19 23:39
>>76
あまり分割の必要もないと思うが。
分割が必要なほど大きくなったら、ツールかXDoclet使うだろ。

80 :デフォルトの名無しさん:04/07/19 23:44
>>77
Servletコンテナの認証使えば?

>>79
XDocletはプロパティファイルの生成には対応してないだろ。
それとも自分でテンプレート作れって意味?

81 :デフォルトの名無しさん:04/07/19 23:47
あぁ、プロパティファイルか。

82 :74:04/07/19 23:51
>>75
。゚(゚´Д`゚)゚。
そうなんですか。。。
ありがとうございます。
別の方法を考えます。
ちなみにサブアプリケーション化しても同じことでしょうか???


83 :74:04/07/19 23:53
あ、それでもmessage-propertiesはデフォルトしか使えないから
一緒か。。。
クライアント側での検証メッセージは全てデフォルトにまとめる
って方法しかないのかな。。。

84 :デフォルトの名無しさん:04/07/20 00:16
>>77
やり方はいろいろある。>>78>>80、独自の認証処理を組み込んだクラスを継承させるなど
好きにしろ

85 :デフォルトの名無しさん:04/07/20 00:21
ここでAOPですよ。

86 :デフォルトの名無しさん:04/07/23 21:38
77ではないけど便乗質問。認証と権限判定の処理は既にあるとして、
各Actionにアクセスするたびに、既に認証済をチェックして、
未認証だったらエラーで跳ねる仕組みというのは、
>>78のフィルタ、>>84のActionを継承したまとめクラスを作るほかに、
RequestProcessorを使う手などもあると思うけどどれが一番おすすめ?
利点、欠点の対比表みたいな情報があったら教えてください

87 :デフォルトの名無しさん:04/07/23 22:34
そういう情報があったら俺も欲しいけど、多分無いから
自分はこう思うけど、どう?
という書き方をしてはどうだろうか。

88 :86:04/07/23 23:28
ではさっそく
1. フィルタ→Strutsに依存しない。ActionだけでなくJSPにアクセスされた
 場合もフィルターすることができる。
2. ActionServletを自分で拡張して、doPost()の中に書く。
3. Actionを自分で拡張して、execute()の中に書く。
4. 自分のRequestProcessorを作って、struts-configで組み込む。
2.-4.はどれも同じに見える…

89 :デフォルトの名無しさん:04/07/23 23:41
Struts依存のAPIにアクセスする必要が無いのなら、
Struts依存になる方法(RequestProcessorのカスタマイズなど)よりも
Strutsに依存しない方法(フィルタなど)の方がいいと思う

90 :デフォルトの名無しさん:04/07/24 10:25
Struts依存の方法を使ってしまうと、Strutsを使う必要のないところまでStruts使わないといけなくなるね。

91 :デフォルトの名無しさん:04/07/24 14:51
Strutsのサンプルはカスタムタグでやってるね。
あれじゃ画面遷移時にしか判定されない。

92 :デフォルトの名無しさん:04/07/24 17:53
>>91
Strutsのサンプルは、Strutsの機能を見せるのが目的だから
アプリの設計として正しいとは限らない。

93 :86:04/07/24 20:39
>>89-90
他のフレームワークを使うときには結局それに合った仕組みを使うことに
なると思うので、現状はStruts依存でもより便利ならば気にしません
フィルタに対するActionやRequestProcessorの利点としては、
エラーで跳ねるときにglobal-exceptionでフォワード先を論理名で
指定できることかな。しかしそれだけだと弱すぎる…
>>91-92
そうだ、タムタムタグという手もあったね。それは漏れがStrutsを知らなかった
時やっていた方法で津。が、Actionに対するアクセスを止められないですね

94 :デフォルトの名無しさん:04/07/24 20:44
>93
でもアプリケーション全体にかかわる処理は、
リクエストプロセッサー拡張などのフレームワークに依存する
処理にしないほうがいいと思う

95 :デフォルトの名無しさん:04/07/24 23:55
>>93
> 他のフレームワークを使うときには結局それに合った仕組みを使うことに

struts依存じゃない方法なら、その「他のフレームワーク」にも依存しないので、それに合った仕組みに作り変える必要もない。
それに、「他のフレームワーク」が「それに合った仕組み」を提供してるとは限らない。

96 :デフォルトの名無しさん:04/07/25 00:12
Struts使う、って前提の話なのになにトンチンカンなこと言ってんの?

97 :デフォルトの名無しさん:04/07/25 00:45
>>96
なのになにトンチンカンなこと言ってんの?

98 :デフォルトの名無しさん:04/07/25 00:51
>>97


99 :デフォルトの名無しさん:04/07/25 00:55
なんでも汎用に作りたがるバカがいらっしゃるようで・・

100 :デフォルトの名無しさん:04/07/25 01:03
>>99
っていうか、認証をフィルターとかコンテナの認証機構使わずにStruts独自の仕組み使ってやる意味の方がわからない。

101 :デフォルトの名無しさん:04/07/25 01:04
>>93
> タムタムタグ

萌えー

102 :デフォルトの名無しさん:04/07/25 01:58
>>100
認証の方法にもよるだろ、んなもん。

103 :86:04/07/25 02:10
社内に複数の業務システムがあって、ログインは独立した
アプリケーションとして動いているポータル窓口で一括でやります。
各業務システムはポータル窓口から蹴られるときに隠しパラメータで
ログインユーザを受け取るので自分で認証はしません
(偽サイトを立てられたらどうするかという問題はありますが、
リファラーを見て跳ねる等で対応します)
こういう外部からログインしたかどうかの情報を受け取って、
何かのAPIによってコンテナ自身のsecurity-constraintを有効にさせる
ことはできるのかな?(あくまで認証の話で権限は別問題として)
タムタムが5番目とするとこれが可能なら6番目の選択肢になるのですが…

104 :デフォルトの名無しさん:04/07/25 02:27
>>103
JNDIとか使って、ちゃんとやったほうがいいと思うのだが。
リファラーで対応ってことは、あんまり重要な情報は扱わないのかな。

>>102
Struts独自の方法を使ったほうがいい場合の例をあげてくれ。

105 :デフォルトの名無しさん:04/07/25 02:35
必ずスレタイから話をそらそうとする奴がいる

eclipseスレでも
O/Rマッピングスレでも
Strutsスレでも
「もっと汎用的に」

じゃあそんなツールなんか使うな。

106 :デフォルトの名無しさん:04/07/25 02:45
>>105
だから、フィルターやらコンテナ認証ではなく、Struts独自の仕組みでやったほうがいい例を教えてくれ。
別に、汎用だからいいっていってるわけじゃない。

Struts使うなら全てをStruts使ってやらないとダメなのか?
Strutsを使うべきところと、使わない方がよいところを議論するのがスレタイから話をそらしてることになるとは思わないのだが。

107 :デフォルトの名無しさん:04/07/25 02:48
>>105
そういうお前はStrutsアプリケーションなら
java.util.ArrayList使わずにorg.apache.commons.collections.FastArrayList使うのか?
java.util.HashMap使わずにorg.apache.commons.collections.FastHashMap使うのか?

標準APIでこと足りるのに、特定ライブラリに依存する物を
わざわざ使う理由がわからんって言ってんだよ


108 :デフォルトの名無しさん:04/07/25 14:19
>>107
そんなのケースバイケースだろ。
FastArrayListが便利だと思うときに使えばいいだけじゃん。
使って便利ならいいと思うんだけど。
Strutsなんか使わずにgetRequestDispatcher()使えば?って言ってるようなもんだぞ。

109 :デフォルトの名無しさん:04/07/25 14:44
strutsを使ってる限り、どう実装しようが勝手。
個人的には拡張Actionクラスを作って処理が実現できるなら、それでもかまわないと思うよ。
問題は目的を達成できるかどうかだからね。
極端な話、WebアプリがJavaである必要すらないんだから。

ただ、そんなことしてていざstrutsから離れた時に困るだろうけど。

110 :デフォルトの名無しさん:04/07/25 14:53
>>108
だろ?だから、標準API使うよりStruts依存APIを使った方が便利な場合を教えろよって言ってんだよ。


111 :デフォルトの名無しさん:04/07/25 15:38
はじめはまともな意見だと思っていたが、こうしてみると単なる粘着だ。

112 :デフォルトの名無しさん:04/07/25 15:45
>>111
というか、ただ話の流れを乱したいだけのバカがいるだけ。

113 :デフォルトの名無しさん:04/07/25 15:58
111⊂(゚ー゚*⊂⌒`つ≡≡≡≡≡≡≡≡≡≡3

114 :デフォルトの名無しさん:04/07/25 16:30
struts依存APIって例えば何

115 :デフォルトの名無しさん:04/07/25 16:37
>>114
話に加わる以前の問題だなw

116 :デフォルトの名無しさん:04/07/25 16:50
>>114
Action

117 :デフォルトの名無しさん:04/07/25 17:09
プッ Struts使ってんだからArrayListなんて使わずに
FastArrayList使えばイイじゃないですか。
フィルタなんて使わずにRequestProcessor拡張すればイイじゃないですか。
何でも汎用的にしたがるヴァカが集まるスレはここですか?

118 :デフォルトの名無しさん:04/07/25 17:51
>>117
この文章のどこをどう読めば面白くなりますか?

119 :デフォルトの名無しさん:04/07/27 01:11
[tiles.xml]
<definition name="xxx" path="template.jsp">
<put name="aaa" value="insert.jsp"/>
</definition>

[template.jsp]
<%@ page contentType="text/html; charset=MS932" %>
<%@ taglib uri="/WEB-INF/taglib/struts-html.tld" prefix="html" %>
<%@ taglib uri="/WEB-INF/taglib/struts-tiles.tld" prefix="tiles" %>
<html:html>
<body>
<tiles:insert attribute="aaa" beanName="aaForm"/>
</html:html>

[insert.jsp]
<%@ page contentType="text/html; charset=MS932" %>
<%@ taglib uri="/WEB-INF/taglib/struts-bean.tld" prefix="bean" %>
<bean:write name="???" property="date"/>

上記のような状態で、template.jspで指定したBean(aaForm)の中身の値を
insert.jspに渡したいのですが、どのようにtilesの下の属性のJSPに
beanの値を渡せるのでしょうか。aaFormの内容は動的に変化します。

120 :119:04/07/27 12:16
解決しました。今携帯なのでどうやって解決したかはまた後で報告します。

121 :119:04/07/27 21:59
bean:defineで解決しました。

[template.jsp]
<%@ page contentType="text/html; charset=MS932" %>
<%@ taglib uri="/WEB-INF/taglib/struts-html.tld" prefix="html" %>
<%@ taglib uri="/WEB-INF/taglib/struts-tiles.tld" prefix="tiles" %>
<html:html>
<bean:define id="form" name="aaForm"/>
<body>
<tiles:insert attribute="aaa" beanName="form"/>
</html:html>

[insert.jsp]
<%@ page contentType="text/html; charset=MS932" %>
<%@ taglib uri="/WEB-INF/taglib/struts-bean.tld" prefix="bean" %>
<bean:write name="aaa" property="date"/>


122 :デフォルトの名無しさん:04/07/27 22:14
>>121


123 :デフォルトの名無しさん:04/07/27 22:24
最後の1行間違えた。
誤:<bean:write name="aaa" property="date"/>
正:<bean:write name="form" property="date"/>

>122
ども

124 :デフォルトの名無しさん:04/07/28 01:53
ttp://www.exglue.jp/
これほんとに5倍なら良さそう。有償だけど。

125 :デフォルトの名無しさん:04/07/29 20:02
>>124
宣伝乙。
そして二度とくるな。

126 :デフォルトの名無しさん:04/07/29 21:13
>>124
何度も紹介してるんじゃねーよ。
本当に良い物なら、一度の宣伝で話題になる。

127 :デフォルトの名無しさん:04/08/02 00:31
>>124
生産性5倍にならなかったら開発費から何から「全額保障」してくれるのだろうかと...
糞ツールなのかな?

128 :デフォルトの名無しさん:04/08/02 03:14
それより、ケムマキって「煙に巻く」からケムマキなのか?

129 :デフォルトの名無しさん:04/08/03 00:43
>>128
うおー、そうなのか。
ドラゴンボールのビビディとバビディとブウがあわせてビビデバビデブウなのは知ってた?


130 :デフォルトの名無しさん:04/08/03 00:47
ピンクのモンキーだからピンキー

131 :デフォルトの名無しさん:04/08/04 11:41
struts+velocityは標準で国際化に対応しているため、クライアントのAccept-Languageを判断してリソースバンドルを開きますが、
ここで任意の言語(バンドル)を指定するにはどうやれば良いのでしょうか。

response.setHeader("Accept-Language", "en")ではうまくいかず、日本語のメッセージが表示されてしまいました。


132 :デフォルトの名無しさん:04/08/04 11:44
age

133 :デフォルトの名無しさん:04/08/06 05:41
selectタグの選択項目を設定するのって、どこでやればいいんでしょか?
単純にActionでやっちゃうと、入力チェックに引っかかってしまいます。
初期画面とSubmit時でふたつのActionつくるのもばからしいと思うのですが。

134 :デフォルトの名無しさん:04/08/06 05:43
あ、あげときます。

135 :デフォルトの名無しさん:04/08/06 05:45
>>131
レスポンスって、意味わかってる?

136 :デフォルトの名無しさん:04/08/06 16:45
>>131
そういうハック的な手法が好みなら、filterでRequestの方をかえなくちゃ。

137 :デフォルトの名無しさん:04/08/07 13:10
>>133
そんな基本的なことを、まわりに聞けないお前に同情するよ。。

138 :デフォルトの名無しさん:04/08/07 13:34
>>129
GNU特戦隊・・・

139 :デフォルトの名無しさん:04/08/07 14:12
>>137
まわりにはStruts知ってる人がいないんです。

140 :デフォルトの名無しさん:04/08/07 22:36
>>139
可哀想だね。
きっと入門書を買うお金もないほど貧乏なんだね。

141 :デフォルトの名無しさん:04/08/07 23:22
>>140
入門書には、なぜか書いてない。

142 :デフォルトの名無しさん:04/08/07 23:25
で、結局、選択項目を設定する場合どうするのがいいの?

143 :デフォルトの名無しさん:04/08/07 23:41
>>141
書いてるよ、ヴァーカ

144 :デフォルトの名無しさん:04/08/08 02:18
>>143
なんか、選択項目を動的に生成するサンプルはあって、入力チェックするサンプルもあるんだけど、両方やってるサンプルがないんです。
2つのアクションを作らないとだめなんでしょか。

145 :デフォルトの名無しさん:04/08/08 03:50
>>144
1.選択項目を動的に生成して表示
2.ブラウザがsubmit
3.入力チェック(して結果表示)
は一連の動作ではあるけど、異なる動作だよね?

1.でActionつかおうがJSPだけでやろうが勝手だけど3.のActionとは別物だから、
> 2つのアクションを作らないとだめなんでしょか。
は意味不明の疑問。

146 :デフォルトの名無しさん:04/08/08 04:33
そういう考え方なんですね。
選択項目の設定を「動作」ととらえるのにすごく違和感があって、もっと宣言的にできないのかと思ってました。

147 :デフォルトの名無しさん:04/08/08 04:49
同じページなら同一のアクションでやるのもありかも。


148 :デフォルトの名無しさん:04/08/09 10:05
StrutsBoxって、どうよ?
ttp://www.strutsbox.de/


149 :デフォルトの名無しさん:04/08/09 11:28
XDocletに対応してなさげなので、魅力なし。
コンフィグエディタとか、コンフィグビジュアライザとかいらんから、XDocletタグを生成してくれるウィザードが欲しい。
JSPのハイライトとかは間に合ってるし。

150 :デフォルトの名無しさん:04/08/09 13:53
Strutsを使ったアプリケーションで、アプリケーション固有の設定を読み込みたい場合は
どのようにしたらいいでしょうか?
たとえば、Perlで書かれた掲示板なら設定ファイルで掲示板名を変えたり、表示数を変えたりしますよね。
ActionServletを拡張してサーブレットコンテキストに起動時に読み込むようにするものなのか、
それとも必要になったときにActionで毎回読むものなのか…
どういうものがセオリーなのでしょうか?

151 :デフォルトの名無しさん:04/08/09 14:43
>>150
Actionはひとつのインスタンスが使いまわされるから、
コンストラクタで読み込めば毎回読むようなことはないはず。

152 :デフォルトの名無しさん:04/08/09 14:46
>>151
コンストラクタ>初回

コンストラクタは引数空だった。

153 :デフォルトの名無しさん:04/08/09 14:50
>>151
ばーか

>>150
Javaでも設定ファイル使えばいいじゃん
java.util.ResourceBundleとか、それを拡張したorg.apache.struts.util.MessageResourcesとか。
java.util.ResourceBundleならActionServletじゃなくてorg.apache.struts.action.PlugInの実装クラスや
javax.servlet.ServletContextListener使ってServletContextに読み込ませればいいし、
org.apache.struts.util.MessageResourcesならそのままActionクラスの中で読み込める。

154 :デフォルトの名無しさん:04/08/09 20:33
>>150
Struts使わないときと同じ。

155 :デフォルトの名無しさん:04/08/10 01:27
まー普通はApplicationResource.propertiesじゃね?

156 :デフォルトの名無しさん:04/08/10 07:50
Pluginだな

157 :デフォルトの名無しさん:04/08/10 08:00
native2ascii使わないとダメ?

158 :デフォルトの名無しさん:04/08/10 08:17
>>157
エンコードしてくれるプロパティエディタ使えば、native2ascii使う必要はない。

159 :デフォルトの名無しさん:04/08/10 08:50
Strutsでユーザー認証ありのアプリ作ってる人、HttpSessionの管理はどこでどうしてます?


160 :デフォルトの名無しさん:04/08/10 09:28
・・・なにか特別気にする必要があるんだろうか

161 :デフォルトの名無しさん:04/08/10 09:36
> まー普通はApplicationResource.propertiesじゃね?
そのリソースバンドル名は普通か?

162 :150:04/08/10 14:13
なるほど、Propertyを読み込んで使ったり、PlugInではじめに読み込んで使うのがセオリーなのですね。
わかりました。皆さんありがとうございました。

163 :デフォルトの名無しさん:04/08/10 14:35
>>159
Filter

164 :デフォルトの名無しさん:04/08/11 08:38
>>160
毎回Actionの先頭でチェックするのも手間だし、普通どうやるものなのかなあと。
その気にしないやり方と言うのを知りたいのです。


>>163
servletののfilter使ってやろうとして、ちょっと詰まってしまいました。
とりあえず(略してますが)下の用に書いてみてfilterが機能するのは確認出来ました。

<filter>
<filter-name>Session Check</filter-name>
<filter-class>filter.HttpSessionChecker</filter-class>
</filter>
<filter-mapping>
<filter-name>Session Check</filter-name>
<url-pattern>/action/*</url-pattern>
</filter-mapping>

<servlet-mapping>
<servlet-name>struts</servlet-name>
<url-pattern>/action/*</url-pattern>
</servlet-mapping>


ところでこの場合当然全てのactionにfilterが効いてしまうのですが、あるactoinだけ(具体的にはlogin処理部分のaction)対象外にすることって可能でしょうか?
strutsのmappingの指定の仕方を工夫すればいけるのかなと思いurl-patternの書き方も調べたのですが、上手くやる方法が見つからず。


165 :デフォルトの名無しさん:04/08/11 08:59
>>164
そもそも、認証の仕組みはどうしているのかを書かないと。
それから、HttpSessionの何をチェックしたいのか?
認証の仕組みはServletコンテナの認証を使っているのか?
自作するのもいいが、コンテナ認証並の堅牢な仕組みを
作るのは大変な手間だと思う。どこかに穴ができるものだ。

Filterの中で特定のURLパターンを除外したいのなら、
リクエストパスを取得して、その文字列を解析するしか
ないかな。

166 :デフォルトの名無しさん:04/08/11 15:40
ApplicationResourceの値を変更したとき、Tomcatを再起動せず再読み込みするにはどうやれば良いんでしょうか。

167 :デフォルトの名無しさん:04/08/11 15:52
reloadableか。自己解決。

168 :デフォルトの名無しさん:04/08/11 16:07
struct

169 :デフォルトの名無しさん:04/08/11 19:01
>166

Tomcatマネージャーから再起動

170 :デフォルトの名無しさん:04/08/15 05:44
ttp://www.exglue.jp/
Strutsコード自動生成だって。生産性5倍超らしいwww

171 :デフォルトの名無しさん:04/08/16 02:50
あちこちのスレにマルチで宣伝、ホントにお疲れ様。

172 :デフォルトの名無しさん:04/08/16 06:39
逆コンパイルしてやろうかと思ってるの俺だけ?w

173 :デフォルトの名無しさん:04/08/16 08:55
中に人が5人ぐらい入ってるんだよ。きっと。

174 :デフォルトの名無しさん:04/08/16 23:37
Strutsタグのリファランス本なりサイトなりってのはないの?
入門書開いて調べるのだるいんですけど。

175 :デフォルトの名無しさん:04/08/17 00:00
応用例とかじゃなくてリファレンスてんなら
本家サイトでいいんじゃん。

176 :デフォルトの名無しさん:04/08/17 00:15
>>174
http://struts.apache.org/

177 :174:04/08/17 00:15
>>175
見てみた。用は足りるんだけど、ぶっちゃけ日本語じゃないと厳しいんです。
Strutsファンページとかで日本語化されるの待つしかないんかな?
JSPの標準タグと合わせた書籍があれば売れると思うんだけど

178 :デフォルトの名無しさん:04/08/17 00:36
>>165
ありがとうございました。
返事遅れました

・認証は自前で、コンテナ認証は使ってません。
・ログインが成功した段階でHttpSessionにユーザ情報を格納しておき、それをチェックします。


> Filterの中で特定のURLパターンを除外したいのなら、
> リクエストパスを取得して、その文字列を解析するしか
> ないかな。

で、それで行くことにしました。

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
HttpServletRequest httpServletRequest = (HttpServletRequest) request;
String requestUri = httpServletRequest.getRequestURI();
(後略)

}


/testapp/action/loginAction
みたいな文字列が取り出せるので、それをチェックすることで解決できました。


// なんかこのへんで悩んでる人あんまりいないんですね
// ぐぐっても全然出てこなかったり...



179 :デフォルトの名無しさん:04/08/17 01:07
あの程度の英語が厳しい奴が
「入門書開いて調べるのだるい」
とかいってんじゃねーよ。
おまいにはオプソは無理ぽ

180 :デフォルトの名無しさん:04/08/17 07:05
>>177
日本語で見ればいいじゃないか。
ttp://www.ingrid.org/jajakarta/struts/

181 :デフォルトの名無しさん:04/08/17 07:49
>>180
バージョン1.0.2でいいのならね

182 :デフォルトの名無しさん:04/08/17 13:24
>>178
特定のURLパターンをチェックするよりも、モジュールに分割するからね。

183 :デフォルトの名無しさん:04/08/17 14:19
モジュール分割なんてクソみたいな機能まだ使ってる香具師いたのか

184 :デフォルトの名無しさん:04/08/19 13:18
>>183
釣れませんね。

185 :デフォルトの名無しさん:04/08/19 21:41
>>184
今日はぼうずですか。

186 :デフォルトの名無しさん:04/08/27 18:29
tomcat+struts+velocityで、propertiesファイルが動的に更新される(書き換えられる)仕組みを作ってるんですが、
propertiesファイルを毎回動的に読み込むにはどうすればよいのでしょうか。
server.xmlのreloadableをtrueにすると、毎回読み込んではくれるのですが、再デプロイされるため、セッションが切れてしまいます

187 :デフォルトの名無しさん:04/08/27 18:45
>>186
クラスローダに頼らずに読み込めばいいんじゃないかしら。
InputStream in = Hoge.class.getResourceAsStream("/hoge.properties");
としているところをFileInputStream使うとか。

188 :デフォルトの名無しさん:04/08/27 19:05
そうですね。

189 :デフォルトの名無しさん:04/08/28 01:34
ちょっと聞いていいですか?
ぶっちゃけStrutsっていいですか?
便利さとめんどくささを天秤にかけると。

190 :デフォルトの名無しさん:04/08/28 19:20
ぶっちゃけ、君が作ったソースを俺が見ると思うと、かなり便利。


それとも他のフレームワークと比べての話か?

191 :デフォルトの名無しさん:04/08/28 19:40
> ぶっちゃけ、君が作ったソースを俺が見ると思うと、かなり便利。

言い得てるなぁ。。。

189が作ったものに対して、Struts並の情報量とノウハウを提供できるのなら話は別だけどね。
情報量とノウハウ、それらを既に持っている技術者の数を考えるとStrutsに優るフレームワークってあるのかな。


192 :デフォルトの名無しさん:04/08/29 03:08
そうかなぁ。
なんかマッピングがStruts-config.xmlとかvalidator.xmlとかに分散してて、めんどくさそうだけど。
他に同じようなフレームワークがないから、という消極的な理由でしか、便利といえないような気がするんだけど。

193 :デフォルトの名無しさん:04/08/29 04:09
???
「マッピングが分散してる」とはどういうこと?


194 :デフォルトの名無しさん:04/08/29 04:32
>>192
XDocletって知ってる?

195 :デフォルトの名無しさん:04/08/29 04:55
>>194
知ってるけど、問題が出たときに、やっぱりいろんなところに原因が分散することにはあまり変わりがない気がする。
使わないよりかなりマシだけど。

フレームワークとして、あまりよろしくない設計になってる部分が多いと思うんだけど。
ActionFormが継承ベースであることを筆頭に。

196 :デフォルトの名無しさん:04/08/29 05:01
とにかく>>191みたいな、「他に優れたものがないからStrutsマンセー」みたいな思考停止状態になってるような気がして嫌。


197 :デフォルトの名無しさん:04/08/29 08:46
>>195
>ActionFormが継承ベースであることを筆頭に。

それの何が問題なの?


俺はStrutsは機能が足りないところが不満。


198 :デフォルトの名無しさん:04/08/29 08:49
>>196
191のどこをそう読んだらそう思えるんだ?
他に普及しているものがないからってんなら分かるけど。


199 :デフォルトの名無しさん:04/08/29 10:51
一人で使ってるなら、俺流フレームワークを改良していけば
一番使いやすいんだろうけどね。
人数を増やすために低スキルの派遣を呼んだりした時に、
面接で「Struts出来る?」「Struts勉強しておいてね」
で通じるんだから便利だ。

>>196みたいにStrutsよくわからないから攻撃的になるってのは、
端で見ていて可哀想だ。

200 :デフォルトの名無しさん:04/08/29 16:26
>>199

人数を協力会社から集めるときに便利ってのは確かにそう思う。
独自フレームワークだと,研修から始まって設計から実装の仕方まで
教えなきゃならんから…(もちろん,その囲い込みで商売しているところにとっては
今後は厳しい状況になるのかも)

けど,Strutsを使っているとはいえそれをベースに作りこんでいるところは多いわけで,
その部分については独自フレームワークといってもいいから,結局そのコストは
ゼロにはならんのだなあと思ったりもする。

201 :デフォルトの名無しさん:04/09/01 04:05
>>200
独自フレームワークのとこで仕事してるけど、
>研修から始まって設計から実装の仕方
なんて教わったことな(ry

というか、面接では「Strutsに似たフレームワークです」
と聞いてたのに実際は似ても似つかない糞だったってのが腹立つ。

202 :デフォルトの名無しさん:04/09/01 04:20
sessionスコープにform入れたら、なんか妙なエラー出るし。
formが無かったら勝手に作ってくれるような気がしてたけど、エラーになるような。



203 :デフォルトの名無しさん:04/09/01 07:31
>>202
セッションに入れるなら素直に別Beanを用いるべき。

実際はフォーム名をキーとしてセッションに入ってるけど
ActionFormの管理はStrutsに任されてるし、
アクセスはActionからに限ったほうが無難。

204 :デフォルトの名無しさん:04/09/01 10:30
>>200
Strutsも、協力会社からかきあつめてきたようなヤツがちゃんと使えるほど浸透してるの?
後からかきあつめてきたやつが細部まで知っておく必要もないとは思うが、それならStrutsじゃなくてもあまり変わらん気が。
結局200の言うようにラップして使うなら。

205 :デフォルトの名無しさん:04/09/01 10:32
>>199
低スキルのやつに「Struts勉強しておいてね」で間に合うのなら、別のフレームワークでも大差ない気がするが。
ほんとに「Struts出きる?」で出きるといったヤツがStrutsできてるの?

206 :デフォルトの名無しさん:04/09/01 10:47
少なくとも、他のフレームワークよりは普及・浸透しているだろう。
できないヤツに教えるにしても、Web上や書籍の情報は豊富だしね。

207 :デフォルトの名無しさん:04/09/01 15:59
struts 1.2.2 オフィシャルリリース age

# 忙しくて変更について行けない...

208 :デフォルトの名無しさん:04/09/01 16:18
>>207
でも、パッケージミスがあったりJDK1.3で動かなかったりで
もめてるね。すぐに1.2.3になりそう・・・・

209 :デフォルトの名無しさん:04/09/01 22:39
>>205
分かった。君は「Tapestry勉強しておいてね。」って言うことを許す。

210 :デフォルトの名無しさん:04/09/02 01:52
>>207
技術についていけなくなった負け犬の遠吠え・・・

211 :デフォルトの名無しさん:04/09/02 03:43
Strutsにあらずんばフレームワークにあらず。
似非Java技術者は去れ。

212 :デフォルトの名無しさん:04/09/02 03:58
>>211
なるほど。

213 :デフォルトの名無しさん:04/09/05 10:19
>>192
俺も最初はそう思っていた。けど設計がころころ変わらないなら
struts-configなんてそうそういじるもんでもないし
まあ使ってみるくらいの時間は割いて損はないんじゃない

>他に同じようなフレームワークがないから、という消極的な理由でしか
正直、Webがいつまで続くかも分からない。あっというまにリッチクライアントに
移行するかもしれんしね。だからWebフレームワークにあれこれ手を出して比較検討する、
という余裕はないなあ

214 :192:04/09/05 11:14
>>213
ま、ぶっちゃけ、JSFが定着すればおわりかと思ってんだけどね。

215 :デフォルトの名無しさん:04/09/05 15:30
何の気なしに wikipedia の Apache Struts の項を見てみたら、

>フレームワークにはModel-View-Controller (MVC)アーキテクチャーが適用されている。
>類似したフレークワークとしてJSF(Java Server Faces)がある。

ってなってて、これどーなのよと思った。
(両方MVCですよ、ってことだとは思うんだが・・)

216 :デフォルトの名無しさん:04/09/05 16:43
え、なんかおかしい?

217 :デフォルトの名無しさん:04/09/05 17:57
JSFはStrutsの類似品ですかΣΣ(゚д゚lll)

218 :デフォルトの名無しさん:04/09/05 18:46
StrutsとJSFは同じ人が作ってるからねぇ・・・
その人物はTomcatのリリースマネージャだったこともあるし。
Craig R. McClanahan氏。

219 :デフォルトの名無しさん:04/09/05 23:08
類似品つーか、かぶってるつーか。

220 :デフォルトの名無しさん:04/09/05 23:29
まあそれは、あんまんと肉まんは似ているか否かみたいな議論だべ

221 :デフォルトの名無しさん:04/09/05 23:35
いや、豚まんと肉まんでしょ
>中身は大して変わらない

222 :デフォルトの名無しさん:04/09/05 23:53
>>221
(゚Д゚)ハァ?

223 :デフォルトの名無しさん:04/09/06 22:19
君たち。豚まんの中に肉は入っているのかね?

224 :デフォルトの名無しさん:04/09/06 22:57
入ってるでしょ。肉まんのことを関西では豚まんと呼ぶ。
http://www.kuidaore-osaka.com/2top/deep/02_tabu/0006.html

225 :デフォルトの名無しさん:04/09/07 10:10
ほんでもstruts-config.xmlよりfaces-config.xmlの方が
100倍読みやすいと思うのオレだけ?
後出しジャンケンの勝利ってヤツ?

あと、UIViewRootの思想って使い勝手がいいと思うが。


226 :デフォルトの名無しさん:04/09/07 19:10
>>225
XDoclet使ってるからstruts-config.xmlなんて読まない。

227 :デフォルトの名無しさん:04/09/08 01:54
XDocletでstruts-config.xmlつくるっていうけどさー。
大規模システムでもつかえんのか?

やたらメモリ喰ってつかえねーって話聞いたんだけど?


228 :デフォルトの名無しさん:04/09/08 02:05
>>227
ソースファイルが多いとOutofMemoryでもくりです。
数人規模の小プロジェクトで使うが吉


229 :デフォルトの名無しさん:04/09/08 02:27
227、228 はヒープサイズをいじれないド素人。

230 :デフォルトの名無しさん:04/09/08 05:45
大規模プロジェクトでstruts-configをみんなでいじるほうが怖いね。
たとえ分割したとしても。

231 :デフォルトの名無しさん:04/09/08 11:18
>>229
どこで設定するのでしょうか?教えちください。

232 :デフォルトの名無しさん:04/09/08 22:30
>>231
横から口出してすまんが、漏れはXDocletでOutOfMemoryの経験が無いので純粋に聞きたいんだが、
それは本当にヒープサイズの弄り方がわからないのか?
それともヒープサイズ大きくしたって意味無いよ、ってことを皮肉ってるのか?
それとも他の皮肉か?
-Xms -Xmx

233 :デフォルトの名無しさん:04/09/09 01:07
>>229
ちっこいシステムしか担当したことないんですね?

-Xms -Xmxを設定してますが、ソース数と比例して増やす必要があり、
使い勝手がいいとは思えません。

234 :デフォルトの名無しさん:04/09/09 01:14
>>233
「大きいシステムでは-Xms -Xmxを設定するぐらいならStrutsの設定ファイルをみんなでいじるほうが使い勝手がいい」ということ?
ほんとかよ。

235 :デフォルトの名無しさん:04/09/09 02:05
>>234
ちがうって
有償のソフトウェアつかってるの

フリーのしか使えない貧乏会社のエンジニアはだまっとけ

236 :デフォルトの名無しさん:04/09/09 09:52
>>235
何使ってるの?

237 :デフォルトの名無しさん:04/09/09 10:01
まぁ、何でも金かけりゃいいってもんじゃねぇ


238 :デフォルトの名無しさん:04/09/09 10:11
金かけたシステムが良いシステムとは、必ずしも言えない。

239 :デフォルトの名無しさん:04/09/09 10:19
技術が足りなきゃ、金かけようが何しようが結果に大差なし。

240 :デフォルトの名無しさん:04/09/09 10:27
>>239
いや、残業代もでるし、休みもとれるし、給料いいし、責任ないし、プロジェクトの結果には大差ないけど、生活には大差ある。
先のことはわからんがねw。

241 :デフォルトの名無しさん:04/09/09 10:28
>>233
ちなみに、クラス数って、どのくらいなの?

242 :デフォルトの名無しさん:04/09/09 11:15
で、235は何を使ってるの?

243 :デフォルトの名無しさん:04/09/09 11:20
お金のかかるツールで、大量のクラスが扱えて、大人数で編集してもコンフリクトしないstrtus-config編集ツールってなに?

244 :デフォルトの名無しさん:04/09/09 11:35
>>235
何使ってるの?

245 :デフォルトの名無しさん:04/09/10 06:57
>>235
俺も知りたい。
何使ってるか教えてください。

246 :デフォルトの名無しさん:04/09/13 18:56:25
既存のhtmlタグを壊してstrutsのタグにするメリットを教えて下さい。

247 :デフォルトの名無しさん:04/09/13 19:01:54
>>246
君がメリットを感じないのならわざわざ使うこと無いよ

248 :デフォルトの名無しさん:04/09/13 19:02:21
>>246
スクリプトレット(<%=value%>)を避けるためではないか。

249 :デフォルトの名無しさん:04/09/13 20:50:41
>>248
それだけ

250 :デフォルトの名無しさん:04/09/13 23:02:42
使うかどうかはおいといて、
html:formやhtml:javascriptのようなコアなやつ以外にも
国際化対応とかhtml:linkがあるじゃん。

251 :デフォルトの名無しさん:04/09/14 01:33:19
とりあえず、ELとJSTLで間に合うやつは、使う必要なし。

252 :デフォルトの名無しさん:04/09/14 11:09:44
すみませんが どなたか教えてください。
html:image タグでイメージボタンを作りたいのですが、ボタンの大きさを
指定することはできないのでしょうか?

普通のHTMLだと
width="80" height="30"
のように指定できますよね?

これをどのように指定するのかが わからないのです。

253 :デフォルトの名無しさん:04/09/14 18:54:28
<form >
<input type="image" src="../img/xxx.gif" name="submit" alt="ボタン"></input>
<input type="image" src="../img/xxx.gif" name="submit" alt="ボタン2"></input>
</form>

これと同じことをstrutsでやるにはどうしらよいでしょうか。
<html:submit name="submit">では怒られてしまいます。
1ページにボタンが2つあり、それぞれの値を取りたいのです。

254 :デフォルトの名無しさん:04/09/14 18:57:21
訂正します。

<input type="image" src="../img/xxx.gif" name="submit" value="ボタン"></input>
<input type="image" src="../img/xxx.gif" name="submit" value="ボタン2"></input>

こうです。
上のボタンが押された時は、submitに「ボタン」が入っていて、
下のボタンが押された時は、sumibtに「ボタン2」が入っていてほしいです。


<input type="submit" name="submit" value="ボタン"></input>
<input type="submit" name="submit" value="ボタン2"></input>

普通にHTMLで書けば成功しました。

255 :デフォルトの名無しさん:04/09/14 21:13:00
使えるかな?
http://struts.apache.org/api/org/apache/struts/util/ImageButtonBean.html


256 :デフォルトの名無しさん:04/09/15 07:42:17
初期値を設定するフォームについて質問。

データ更新なんかのときに
@既存データを初期値として設定するアクション(path="first")
A選択項目を設定するアクション(path="set")
B入力後の処理を行うアクション(path="proc" input="set.do")
と3つのアクションを作ると思います。

このとき、Aのアクションに直接アクセスされないようにするにはどうすればいいですか?
set.doのようにして初期値が設定されてないフォームが表示されることがないようにしたいです。

257 :デフォルトの名無しさん:04/09/15 08:16:00
>>256
TransactionTokenを使う

258 :デフォルトの名無しさん:04/09/15 12:04:33
>>255
すみません、アクションフォームでどうやってvalue値を受け取ればよいのでしょうか。

import org.apache.struts.util.ImageButtonBean;

private ImageButtonBean submit = null;

public ImageButtonBean getSubmit(){
return ( submit );
}
public void setSubmit( ImageButtonBean submit ){
this.submit = submit;
}

これでよいのでしょうか?

259 :デフォルトの名無しさん:04/09/15 21:43:31
>>257
それはちょっと違うので。
Aがset.doでブラウザからアクセスできないようにしたい。
@からのフォワードや、Bでのエラーじの入力だけで使いたいです。

260 :デフォルトの名無しさん:04/09/15 21:55:06
とりあえず、Aのpathを/WEB-INF/setにしました。

261 :デフォルトの名無しさん:04/09/16 10:04:10
2ちゃんねるの個々のスレッドの書き込み数は、そのスレッドで扱う事柄の
メジャー度や人気度、普及率を表していると思うのだけど、
1日10個もないということはstrutsはまだ全然普及していないと考察する。

262 :デフォルトの名無しさん:04/09/16 10:57:22
>>261
とんだ見当違いだな。何と比較しているんだか。
・スレが立っているうちでは一番書き込みが多い
・複数のスレがある(WebProg板にも)
2ちゃんねるの個々のスレッドの書き込み数は、そのスレッドで扱う事柄の
メジャー度や人気度、普及率を表していると思うのなら、Strutsは一番じゃないのか?
それとも、これ以上に書き込み数の多いフレームワークがあるのか?


263 :デフォルトの名無しさん:04/09/16 11:32:30
>>256
私は、 Struts 側の機構として、そういう風にアクションを完全に制御する手段は用意されてないと理解しています。
やるならサーブレットコンテナ側の filter とか。

と書こうとおもってたら、WEB-INF 以下に入れる方法があったか。。。


264 :デフォルトの名無しさん:04/09/16 11:55:27
かっこわるいけどforwardしかさせないファイルは、
ファイル名の先頭にアンダースコアを付加してる。

単純なルールだからfilterで弾けるし。

265 :デフォルトの名無しさん:04/09/16 13:14:22
strutsで変数のHTMLタグを全部除去する方法ってありますか?

266 :デフォルトの名無しさん:04/09/16 14:14:47
表形式のJSP で、行数が可変で、各行にラジオボタンがある場合、
-----------------------------------------------------------------
<logic:iterate id="userData" name="userInfoBean" property="userList" indexId="index">
<input type="hidden" name="id<bean:write name="index" />" value="<bean:write name="userData" property="userID" />">
<input type="radio" name="accept<bean:write name="index" />" value="0">社員
<input type="radio" name="accept<bean:write name="index" />" value="1">非常勤
<input type="radio" name="accept<bean:write name="index" />" value="2">常駐
<br>
</logic:iterate>
-----------------------------------------------------------------
とやると、
-----------------------------------------------------------------
<input type="hidden" name="id0" value="10001">
<input type="radio" name="accept0" value="0">社員
<input type="radio" name="accept0" value="1">非常勤
<input type="radio" name="accept0" value="2">常駐
<br>
<input type="hidden" name="id1" value="10002">
<input type="radio" name="accept1" value="0">社員
<input type="radio" name="accept1" value="1">非常勤
<input type="radio" name="accept1" value="2">常駐
<br>
<input type="hidden" name="id2" value="10003">
<input type="radio" name="accept2" value="0">社員
<input type="radio" name="accept2" value="1">非常勤
<input type="radio" name="accept2" value="2">常駐
<br>
-----------------------------------------------------------------
みたいなHTML を吐き出すのだけど、このとき、ActionForm はどんな風に書けば
いいのかな?


267 :デフォルトの名無しさん:04/09/16 15:27:38
>>261
普及して安定すると、かえって投稿は少なくなるよ。


268 :デフォルトの名無しさん:04/09/16 17:50:18
>>266
http://www.freeml.com/message/struts-user@freeml.com/0003295

まるちぽすと〜
どこの誰だか丸わかり〜

269 :デフォルトの名無しさん:04/09/17 04:39:02
XDocletの@struts.validatorのarg1valueなんかを使うと、arg1のnameにはdependsに指定したものがそのまま使われます。
そうすると、dependsに2つ以上指定したときにうまく動きません。
arg1のnameを指定する方法はありませんか?
というか、みなさまどうやってますか?

XDocletがメンテナンスされてないのも気になるけど。
やっぱSGenかな。

270 :デフォルトの名無しさん:04/09/17 09:54:17
>>269
@struts.validator-args を使う
http://xdoclet.sourceforge.net/xdoclet/tags/apache-tags.html#@struts_validator-args__0__1_

271 :デフォルトの名無しさん:04/09/17 13:37:24
>>270
つまり、nameの指定はあきらめろと。

272 :デフォルトの名無しさん:04/09/17 14:21:38
糞なもののよさをわかろうとしても無駄

273 :デフォルトの名無しさん:04/09/17 14:25:36
>>235のが気になるのだけど。

274 :デフォルトの名無しさん:04/09/17 15:12:46
そーいや昔アクセンチュアのフレームワーク使ったことあったな。
2年前にしちゃ出来は良かった気が。なんつーなまえだっけな〜

275 :デフォルトの名無しさん:04/09/17 15:13:14
>>271 ハァ? @struts.validator-args でname指定されるんですが何か?

276 :デフォルトの名無しさん:04/09/17 15:16:12
>>275
ヘルプ見てもわからんのだけど、どうやるの?

277 :デフォルトの名無しさん:04/09/17 15:31:05
>>275
できないだろ。
>>269
dependsにルール名を複数指定するんじゃなくて、
@struts.validator を2つとか複数書くんだよ。ドキュメントにも(0..*)と書いてあるだろ?

278 :デフォルトの名無しさん:04/09/17 15:39:13
あ、@struts.validatorでtypeに複数指定するんじゃなくてdependsごとに@struts.validator書くんだね。
いままで
@struts.validator
 type="required, maxlength"
ってやってたからだめなんだ。
@struts.validator
 type="required"
@struts.validator
 type="maxlength"
 arg1value="${var:maxlength}"
ってやったらうまくいった。

279 :デフォルトの名無しさん:04/09/17 15:43:41
って、すでに>>277が答えてくれとった。

ところで、Struts1.2で、XDoclet1.2.1使って大丈夫ですか?
strutsconfigxmlタスクのversionには1.1を指定するしかないけど

280 :デフォルトの名無しさん:04/09/21 01:22:56
なぜ未だに配布アーカイブファイルの名前がjakarta-struts-x.x.x.zip/tar.gz なのだろうか。
Antはとっくにapache-ant-x.x.x.zip/tar.gz なのに。

281 :デフォルトの名無しさん:04/09/24 19:56:05
Struts難しいと思ったんですが、僕が頭悪いのでしょうか?

282 :デフォルトの名無しさん:04/09/24 20:15:54
>>281
絡む要素が多いからな。
慣れるまでのコストは高い。
最初に良いチュートリアルに出会えばいいんだけどね。

283 :デフォルトの名無しさん:04/09/26 00:46:59
Strutsって、画面(JSP)の項目とアクションFORMビーンのフィールドが1対1で対応づいてますよね?

画面がヘッダ部と明細部にわかれてて、1対Nの画面を
アクションFORMビーンに関連付けるときってどうやったらいいんですか?

伝票番号が1個あって、それに付随する明細情報がN行あるような画面です。
まさか明細行の数は可変です。

今回初めてだから、すごいアフォなこと言ってたらゴメン。

284 :283:04/09/26 00:49:04

「まさか明細行の数は可変です。」
「まさか」は削除して読んで下さい。

285 :デフォルトの名無しさん:04/09/26 01:42:20
ActionFormはあくまで入力に必要なものなので、
出力には好きなオブジェクト(Bean)をつかってもいいです。
もちろんActionFormもBeanに違いないので、
そのN項目を返すGetterをつくってあげれば使えます。

286 :283:04/09/26 02:08:47
>>285
レスありがとうございます!

・あらかじめNの最大値分のGetter(フィールド)を作る
・ActionFormでは管理せずに、Actionクラスで画面の値を取得し、別のBeanを作成する

のいづれかといった感じなのでしょうか?
(後者の場合はActionFormはほとんど意味をなさないことになりますね。たぶん)

287 :デフォルトの名無しさん:04/09/26 02:18:02
List

288 :デフォルトの名無しさん:04/09/26 02:34:54
仕事でStrutsでWebアプリ作らされました。

リクエストをまたがって情報を保存する機構がデフォで無い。
forward するときパラメータを書き換えられない。
タグライブラリがちょぼい。
同じラベルのボタンの処理を分ける仕組みが無い。
日本語対応問題。

など正直使いにくくて、かなり手を加えないと使い物にならなかったのですが。
これが人気な理由って何なんでしょうか?
(人気あるらしいというだけで早々に採用を決めてしてしまったPLを恨みます・・・。)
確かにシンプルなサブミットフォームとかならかなり使えそうですが、
その程度なら Struts 使わなくても困らないし・・。
.NET WebForm を使ったことがある自分にはかなり見劣りしてしまいます・・・。

なんか実は自分が無知で詰まってたところがスパッと解決されてたりしたら泣けてくる・・・。

289 :デフォルトの名無しさん:04/09/26 02:50:43
>>286
過去レスで何度かでてるけど、
formの入力コントロールのproperty属性を同じ値(名前)にすれば、
ActionFormのsetter/getterで配列としてやりとり可能なので、
これを利用できるかな。

290 :デフォルトの名無しさん:04/09/26 03:18:04
>>288
わりと同意
フレームワークといってもStrutsだけの操作でアプリ構築できないから。
基本のServletで簡単に済むことまでラップしない方針なんだろうけど。

> リクエストをまたがって情報を保存する機構がデフォで無い。
一連のリクエストをひとつのものとして扱う仕組みは絶対いる。
というか、ないのに愕然とした。
その上でstruts-config.xmlからサイトマップを出力できればよし。

> forward するときパラメータを書き換えられない。
Servletはリダイレクトせずフォワードするのが基本だから、
request変数をつかえということでしょうね。
なので他アプリとの連携ではURLを直接扱うことに……。

> タグライブラリがちょぼい。
このへんはELや外部ライブラリに移行していくんでしょうけど、
<html:messages>回りはもうちょっと扱いやすくしてほしいです。

> 同じラベルのボタンの処理を分ける仕組みが無い。
よくわかりません

> 日本語対応問題。
FilterでUTF-8に統一させるのが楽ちんです。
外字が絡まない場合はですが。

291 :デフォルトの名無しさん:04/09/26 03:27:19
>>288
薄いコントローラフレームワークなので手を加え易い、ってのは
Strutsのメリットでもあると思うが。そのままじゃ使いにくいのは確かだと思う。
共通系作る人がある程度がんばらないと。

人気の理由は、デファクトスタンダードになってるから人を集め易い、とかだろ。

292 :デフォルトの名無しさん:04/09/26 06:08:24
>>289
なるほど。これって、各項目で格納順(インデックス)がずれたりしないのかな?
わかりました!ちょっとやってみます!

293 :デフォルトの名無しさん:04/09/26 11:15:07
>>292
Bean のリストをフォームに持たせるんじゃ不満なのか?

294 :デフォルトの名無しさん:04/09/27 09:37:42
>290

> 同じラベルのボタンの処理を分ける仕組みが無い。

<html:form>
<html:text />
<html:submit property="submit" value="送信" />
<html:textarea />
<html:submit property="submit" value="送信" />
</html:form>

フォームの中にボタンが二つあって、それぞれで処理を分けたい時、
どうするのってことだと思います。推測ですが。

295 :デフォルトの名無しさん:04/09/27 09:55:32
同じラベルのボタンで処理が違ったら、ユーザーは迷惑だね。

296 :デフォルトの名無しさん:04/09/27 11:00:10
>>295
[  項目A  ][参照]
[  項目B  ][参照]
[  項目C  ][参照]
    :

といった感じのUIはWebでなくても頻繁に使用されていると思うが。
むしろこの参照ボタンのラベルが一個一個違ってたらどーよ。

297 :デフォルトの名無しさん:04/09/27 11:48:39
>>296
webの場合、ひとつのフォームのラベルが同じsubmitは結局判別できないと思うが。
strutsうんぬんの問題ではないよ。
javascriptでhidden項目切り替えるか、フォームを複数にするか。
基本的にはスレ違い。

298 :デフォルトの名無しさん:04/09/27 11:52:57
>>297
submitのnameを変えれば出来ると思うが。
Strutsはそれ(nameによるディスパッチ)に対応してない。

299 :デフォルトの名無しさん:04/09/27 12:10:53
>>298
あぁ、そうね。

300 :デフォルトの名無しさん:04/09/27 12:24:03
> リクエストをまたがって情報を保存する機構がデフォで無い。
これってどういうものをイメージしているのでしょうか?
セッションを使うか、イヤならhiddenに入れればいいような気がするが。

301 :デフォルトの名無しさん:04/09/27 15:27:10
>>288
日本語対応問題ってなに?

302 :デフォルトの名無しさん:04/09/27 15:33:13
>>301
入力の文字エンコーディング指定のことだろ。
別にStrutsでもStrutsじゃなくても同じだと思うけど?

303 :デフォルトの名無しさん:04/09/27 15:39:04
>>302
フィルターかますだけだから、そんな問題でもないねぇ。

304 :デフォルトの名無しさん:04/09/27 16:08:46
>>296
ボタンごとにフォームを変えるってのはだめですか?

305 :デフォルトの名無しさん:04/09/27 16:39:31
まさか同意する人がいるとは思わなかった・・・。
セッションは同じフォームなら別画面でも共有されちゃうので使えません。
ブラウザで新しいウィンドウ開いたりとか。
hidden に全部入れるのも現実的でなかったので、フォームごとに ID を割り振って、
hidden にはその ID を入れておくことでリクエストをまたがっても情報を復元できる仕組みを作りました。

>>301-303
マルチパートとかすこし面倒でした。
Strutsは送られてきたデータをActionFormに自動格納するのだから
エンコーディングまで面倒見るべきだと思います。

>>304
フォームを分けたら、そのフォームに含まれてるコントロールの値しか送信されないので使えません。
どのボタンを押しても、画面全部の情報が送信されないといけないんです。

306 :デフォルトの名無しさん:04/09/27 17:18:31
>>305
> hidden に全部入れるのも現実的でなかったので

オブジェクトままシリアライズしてエンコードしてhiddenはりつけで。

> Strutsは送られてきたデータをActionFormに自動格納するのだから
> エンコーディングまで面倒見るべきだと思います。

フィルターで処理するべきだな。
通信の問題なのだからサーブレットに処理が渡る以前に処理するべき。

> どのボタンを押しても、画面全部の情報が送信されないといけないんです。

じゃあ、JavaScriptでhidden切り替えで。

307 :デフォルトの名無しさん:04/09/27 20:03:12
>>305
> hidden に全部入れるのも現実的でなかったので、フォームごとに ID を割り振って、
> hidden にはその ID を入れておくことでリクエストをまたがっても情報を復元できる仕組みを作りました。


公開してください!
まじでお願いします。


308 :デフォルトの名無しさん:04/09/28 01:07:25
>>305
<html:submit property="処理1" value="OK"/>
<html:submit property="処理2" value="OK"/>

これじゃダメか?
押されたボタンの「name」で処理を判断する。

Struts1.2から導入されたMappingDispatchActionとか、
Struts in Actionに掲載されてるFindForwardActionがこんな感じ。


309 :デフォルトの名無しさん:04/09/28 01:08:20
あぁ、ガイシュツだった。ハズカシ。

310 :デフォルトの名無しさん:04/09/28 01:10:13
>>307
それよりも、やりとりするデータをMapにほりこんで、シリアライズしてエンコードしたものを渡してやると、戻るときにちゃんと戻れるからいいぞ。

311 :デフォルトの名無しさん:04/09/28 08:25:40
>>305
セキュリティ上問題は無いですよね?

312 :デフォルトの名無しさん:04/09/28 09:16:01
EclipseでStruts使っているのですが、JSPを色々いじっている間に、
いつのまにかフォームのパラメータがアクションフォームに渡らなくなってしまいます。
なにか原因はあるのでしょうか。
いちいちプロジェクトを作り直すと直ったりします。

313 :デフォルトの名無しさん:04/09/28 09:19:25
Strutsって、いつまで使えますか?
いつからJSFの波がくるでしょか?

314 :デフォルトの名無しさん:04/09/28 09:23:38
>>313
あと2年ぐらいかなぁ。
今のJSFは2年ぐらい前のStrutsの状況に似ている感じがする

315 :デフォルトの名無しさん:04/09/28 09:25:08
>>307
そんなことしたらクビになる

>>308
1.2 からは導入されているのですね。(知らんけど・・・)

>>310
数百MBのファイルをアップロードした後、もし同名ファイルがサーバー上にあれば
上書きするか名前を変えるかキャンセルできるような処理の場合、毎回数百MBがCS間でやり取りされるのでしょうか?

>>311
フォームの ID はセッションごとに分断されているので、他人の情報を見たりということは出来ません。
意図的に過去の情報を表示することは出来ますが、ブラウザの戻ると同じです。
データそのものはやり取りしないのでクライアントに書き換えられる心配はありません。

316 :デフォルトの名無しさん:04/09/28 09:37:15
>>315
> 数百MBのファイルをアップロードした後、もし同名ファイルがサーバー上にあれば
> 上書きするか名前を変えるかキャンセルできるような処理の場合、毎回数百MBがCS間でやり取りされるのでしょうか?

そんだけ大きいファイルだと、どっちにしろ一時ファイル作るわけだから、そのファイル名でいいんでは?


317 :デフォルトの名無しさん:04/10/01 11:59:03
Tilesってどんなときに有用ですか?
ほとんどの場合jsp:includeでインクルード先を動的に切り替えればいいような気がするんですが。

318 :デフォルトの名無しさん:04/10/01 12:46:23
>>317
・レイアウトも共通化したい場合
・レイアウトと共通部品の組み合わせを継承して差分だけを定義したい場合
・struts-config.xml の<forward>要素にJSPファイルのパスを直接書きたくない場合

<jsp:include>だとレイアウトの共通化は無理だね。

319 :デフォルトの名無しさん:04/10/01 13:35:22
レイアウトの共通化ってどういうこと?
<td>
<jsp:include page="${left}">
</td><td>
<jsp:include page="${right}">
</td>
みたいな感じ?

320 :デフォルトの名無しさん:04/10/01 13:43:59
>>319
考え方としてはまあそんなもん。
319で書いてあるようなレイアウトを定義したテンプレートとなるJSPを作って、
left や right の箇所にどのリソースをincludeするのかは XML形式の設定ファイルに書く。
で、その設定を継承した設定をさらに作ることもできて、right だけオーバーライドする、みたいに
差分だけオーバーライドした設定をどんどん作ることができる。

321 :デフォルトの名無しさん:04/10/01 14:53:36
ページの数だけ定義書かないといけないのが、かなりめんどくさいんだけど。
ほとんどの場合、1〜3パターン程度のフレームがあって、その中に数十のページが収まるっていう感じだよね。
そうすると、いちいちタイル定義書くのってめんどうな気がする。
たとえば*.tmplateを処理するサーブレット作って、*.template→*.jspを$rightに入れてテンプレートJSPにフォワードっていう仕組み作ればいいんじゃないかな、と。

322 :デフォルトの名無しさん:04/10/01 15:02:37
>>321
Tilesはそれもできるぞ。定義は設定ファイルだけじゃなく、
JSPページ上で実行時に動的に作ることもできる。

323 :デフォルトの名無しさん:04/10/01 15:04:02
ついでに*.htmを処理するサーブレットを作って、*.htmを*htmlに変換したものを$rightに入れてテンプレートJSPにフォワードっていう仕組み作れば、静的なHTML置いて拡張子を*.htmにしてアクセスするだけでテンプレートが使える。

324 :デフォルトの名無しさん:04/10/01 15:06:18
>>322
あんまりTilesの意義ってなくなるような。
includeでいいじゃん。

325 :デフォルトの名無しさん:04/10/01 15:24:18
>>324
Tilesはレイアウトの共通化ができるんだってば。includeだとできないだろ。

>>323
リクエストがPOSTの場合は静的HTMLだと動作しないぞ。
動作してしまうコンテナも存在するが。

326 :デフォルトの名無しさん:04/10/01 15:33:13
>>325
レイアウトの共通化が319のようなものなら、できるよね。
そうではないレイアウトの共通化ってなに?

TomcatではPOSTでもちゃんと動いた。
「動作してしまうコンテナ」がTomcatのことなら、全く問題はない。

327 :デフォルトの名無しさん:04/10/01 15:39:21
ってかPerlでもPHPでもレイアウトうまくまとめる人もいるんだから
includeだってやってでにないはずはないだろう

それとも「レイアウト」「共通化」の考え方が違う?

328 :デフォルトの名無しさん:04/10/01 15:44:26
> 「動作してしまうコンテナ」がTomcatのことなら、全く問題はない。
それはおまいにとって問題ないだけだろう。

329 :デフォルトの名無しさん:04/10/01 15:47:05
ていうか、リクエスト受けるのはサーブレットだからPOSTだろうがGETだろうが関係ないと思うんだけど。
どういうルールで、POSTだったらサーブレットマッピングが無効になるの?
それともPOSTのときはincludeで静的ファイルを読み込めないとかあるの?

330 :デフォルトの名無しさん:04/10/01 15:51:24
>>327
319のようなものだと思ってるんだけど。
つまりjakarta.apache.orgで言えば、上部にタイトル、左にメニュー、右にコンテンツがある。
で、タイトルは共通で左のメニューは1〜3パターン、コンテンツはたくさん。

331 :デフォルトの名無しさん:04/10/01 16:00:45
>>329
<jsp:include>はRequestDispatcherが処理するから。
元のリクエストがPOSTだったらインクルードされる側にもPOSTのリクエストが転送される。

「サーブレットマッピングが無効になるの?」なんて聞いている時点で
全くわかってないだろうけどねw。サーブレットマッピングなんてどこから出てきた?


332 :デフォルトの名無しさん:04/10/01 16:01:33
>>331
>>323

333 :デフォルトの名無しさん:04/10/01 16:06:44
わかりにくいようだから>>323に書いた静的HTMLにテンプレートを適用する流れ
・ファイルは拡張子htmlで保存しておくとする

1.*.htmをサーブレットにマッピング
2.サーブレットでhtmをhtmlに変換してrequest.setAttribute("file", ***)
3.テンプレートJSPにフォワード
4.テンプレートJSPで<jsp:include page="${file}"/>

拡張子htmでリクエストすると、htmlファイルにテンプレートがついたものが表示される

334 :デフォルトの名無しさん:04/10/01 16:13:10
>>333
それだとPOSTでの動作は保証できないと何回言えば(ry

335 :デフォルトの名無しさん:04/10/01 16:14:46
>>334
どこの部分が?

336 :デフォルトの名無しさん:04/10/01 16:17:04
<jsp:include page="hoge.html"/>
としたら、POSTのときはうまく動かないコンテナがあるってこと?

337 :デフォルトの名無しさん:04/10/01 16:27:50
まあ、実際にはPOSTで静的ファイルに飛んだりしないし。
ここ見る限りでは、問題なさそうなんだけど。
http://java.sun.com/products/jsp/syntax/1.2/syntaxref1214.html

ところで、Tilesの利点は・・・?

338 :デフォルトの名無しさん:04/10/01 16:34:07
>>336
そういうこと。

<jsp:include>では、"実行時"にincludeする側からincludeされる側にリクエストが転送され、
そのレスポンスデータが挿入される。このとき、コンテナの実装によっては元のリクエストが
POSTだった場合はincludeする側からincludeされる側に転送されるリクエストもPOSTになる。
従って、includeされる側もPOSTを受け、レスポンスを返せるコンポーネントである必要がある。
どうしても静的ファイルをincludeしたいのなら<%@ include %>を使うべき。
こちらはJSPコンパイル時にマージされる。

339 :デフォルトの名無しさん:04/10/01 18:20:22
>>338
337に挙げたJSPの仕様を見る限りでは
「If the resource is static, its content is included in the calling JSP page.」
となってるから、問題ないと思うんだけどねぇ。
実際にPOSTで静的ファイルjsp:includeしたときに動かないコンテナってなに?

340 :デフォルトの名無しさん:04/10/01 18:25:06
「The results of including static and dynamic resources are quite different.」
とも書いてあるし。1.0の仕様には明確な記述はないけど。1.1から追加されてる。


341 :デフォルトの名無しさん:04/10/04 09:50:11
TigerのAnnotation使って@Overrideとか書くと、XDocletがエラーって文句いってくるんだけど、どうしたらいいんだろう?
executeには@Override書いておきたいんだけど。
StrutsにはXDoclet必要だし。XDoclet2ってどうなってるんだろうか。

342 :デフォルトの名無しさん:04/10/04 10:03:21
>>341
AntビルドファイルにexcludedTagsを指定するんじゃダメなの?

343 :デフォルトの名無しさん:04/10/04 10:06:44
>>342
パースエラーになるから、そういう話ではなさそうだけど。
excludedTagsってJavaDocタグに対してのものでしょ?
そもそもAnnotationに対応していなさそう。

344 :デフォルトの名無しさん:04/10/04 10:32:39
>>343
ああ、そうか・・・
Tigerはまだまだ周辺ツールがととなわないね・・・・

345 :デフォルトの名無しさん:04/10/04 10:46:52
というか、XDocletの動く気配がないのが一番不安。

346 :デフォルトの名無しさん:04/10/04 11:04:49
>>345
XDoclet2はまだ気配が見えないねぇ・・・
1.2系は1週間ぐらい前にRCがリリースされたりとメンテされてるみたいだけど。

347 :デフォルトの名無しさん:04/10/04 11:24:22
>>346
え、マジでですか?
sourceforgeは更新されてないし、codehouseには何もないし、どこに行ってるんでしょうか?

348 :デフォルトの名無しさん:04/10/04 11:38:52
>>347
え?いやそのSourceForgeだけど?
http://sourceforge.net/project/showfiles.php?group_id=31602

1.2.2rc1 2004-09-25 15:00


349 :デフォルトの名無しさん:04/10/04 11:47:11
あ、ちゃんとプロジェクト動いてるんだ。
ttp://xdoclet.sourceforge.net/xdoclet/status.htmlは更新されないんだね。

350 :デフォルトの名無しさん:04/10/04 12:08:58
サイトやドキュメントのメンテはいい加減だね。>XDoclet

351 :デフォルトの名無しさん:04/10/04 12:18:03
Strutsのバージョンが1.2指定できるようになって一安心
web.xmlも2.4指定できるのかな。
@Overrideはもちろん通らず

352 :デフォルトの名無しさん:04/10/04 14:25:51
ところで、>>338はどうなったんだろうか。
仕様みる限りそうではないように読めるんだが。

353 :デフォルトの名無しさん:04/10/04 21:48:09
Action側で、
userListという(id=hogeId,name=hogeName)の組み合わせの
Map型リストをsession.setAttribute("userList",userList)にセットして、
jspで
<html:select property="user">
<html:option value="hogeId">hogeName</html:option>

<html:option value="hogeId">hogeName</html:option>
</html:select>
という感じにしたいのですが、どうすればできますか。
value値にhogeIdを入れて、表示に名前を入れたいのです。
tomcat4ですので考慮お願いします。

354 :デフォルトの名無しさん:04/10/04 21:56:03
WebLogicに切り替えてセッションBean

355 :デフォルトの名無しさん:04/10/04 21:57:40
LabelValueBean使えば

356 :デフォルトの名無しさん:04/10/04 22:44:37
うん。LabelValueBeanとlogic:iterateとhtml:optionCollection使えばできるね。

357 :デフォルトの名無しさん:04/10/04 22:59:30
JSTLが使えるところはStrutsのタグ使わないのがいいけどな。
好みだけど。

358 :353:04/10/04 23:09:29
具体的にコード書いて頂けると嬉しいのです。
お人よしの人、お願いします。

359 :356:04/10/04 23:37:45
[JSP]
<logic:iterate id="list" name="xForm" property="userList">
<html:optionCollection name="xForm" proeprty="checkBoxName" value="value"><bean write name="list" value="label"></html:optionCollection>
</logic:iterate>

[ActionForm]
private List userList = new ArrayList();
private String[] checkBoxName;
とそのgetter,setter

[Action]
List list = new ArrayList();
list.add( new LabelValueBean( "ユーザー名1", "ユーザーID1" );
list.add( new LabelValueBean( "ユーザー名2", "ユーザーID2" );
list.add( new LabelValueBean( "ユーザー名3", "ユーザーID3" );

form.setUserList( list );

// 選択済みにするならば
form.setCheckBoxName( new String[]{"ユーザーID1"} );

こんな感じだと思う。
なんもみないで書いたからたぶんどっかまちがってる気がするけど。


360 :356:04/10/04 23:43:35
うわ。所々括弧閉じがぬけてる_| ̄|○

361 :デフォルトの名無しさん:04/10/05 01:48:31
おひとよしのひまじんっているものだねぇ

362 :デフォルトの名無しさん:04/10/05 03:10:37
自分も前に作ったやつのコピペしようとしたら先越されてた。
っていうか大した手間ではない>361


363 :デフォルトの名無しさん:04/10/05 10:18:46
おめぇら、すげぇな!

364 :デフォルトの名無しさん:04/10/05 10:23:15
おれはJSTL版出そうかと思ったけど、struts-elタグの使い方調べるのがめんどくさくてやめた

365 :356:04/10/05 14:40:51
まちがえた。
上の例はcheckboxつくるときの例だった。しかもhtml:optionsCollectionをhtml:multiboxにおきかえないとだめ。
でもやってることは近いので参考に、という程度にはなるかも。

366 :353:04/10/06 09:58:53
自分で考えたらできましたので、一応ソースを張ります。

<html:select property="userId">
<logic:iterate id="row" name="users">
<bean:define id="id" name="row" property="userId" />
<html:option value="<%= String.valueOf(id) %>"><bean:write name="row" property="userName" /></html:option>
</logic:iterate>
</html:select>


367 :デフォルトの名無しさん:04/10/06 10:31:35
JSTL使えばこんな感じかな。
struts-el使うようにする必要があるけど。

<html:select property="userId">
<c:forEach items="${users}" var="row">
<html:option value="${row.userId}"><c:out value="${row.userName}"/></html:option>
</c:forEach>
</html:select>

368 :デフォルトの名無しさん:04/10/06 22:28:49
これでハッとしてグー。

<select name="userId">
#foreach($row in $users)
<option value="$row.userId" #if($row.userId == $xForm.userId) selected #end>
$row.userName
</option>
#end
</select>

369 :デフォルトの名無しさん:04/10/07 03:34:10
>>368
velstrutsかよっ

370 :368:04/10/09 19:15:56
>>369
なかなかツッコミが入らなくてどうしようかと思ったよ。
しかしhtmlで元絵作ってアプリに仕上げるような場合はVelocityに限るね。


371 :デフォルトの名無しさん:04/10/11 13:15:07
Strutsで開発するとき、クラス図とか作ってますか?
画面単位にクラスを作って、単にDBにアクセスするだけしかなくて、
名前もTS0011みたいな画面IDをつけたクラスばかり。
それ以外に作るクラスといったら、データを一時的に保持するクラスと
ユーティリティとDBアクセスクラスだけの場合、
クラス図、シーケンス図を作る意味ありますか。


372 :デフォルトの名無しさん:04/10/11 14:03:28
Webアプリの場合、層分けが大切で、クラスは独立するようにするべきだから、全体のクラス図は必要ないと思われ。
そのまえに、画面IDってなんですか?ネタ?

373 :デフォルトの名無しさん:04/10/11 14:24:23
>>372
画面IDって何か変かな。普通に使っているけど。

374 :デフォルトの名無しさん:04/10/11 14:34:29
それは、かなり侵されてますな・・・・
「IDをつけたクラスがある」というのは、普通に笑い話だけの世界だと思ってたんだけど。

375 :デフォルトの名無しさん:04/10/11 14:47:12
>>371
さてはCOBOLerだな。

376 :デフォルトの名無しさん:04/10/11 15:21:58
IDをつけたクラスの話は悪い例としてよく書かれてるけど、疑問に思ってる。
画面数が数百〜千以上とかのシステムだと、番号をつけて一覧表で管理した方が分かりやすい気がする。
実際、関わったことがあるシステムではそう感じた。
「悪い例」として挙げてるときって、例がシンプル過ぎて現実的じゃないと思う。
要はケースバイケースじゃないのかな?

377 :デフォルトの名無しさん:04/10/11 15:24:29
そのIDの名前をしたクラスを再利用するときは、どうするんですか?

378 :デフォルトの名無しさん:04/10/11 15:32:34
1000以上あると、一覧表のメンテの方が大変そうだが。
パッケージで名前空間をわけるシステムもあるわけで、適切な名前付ける方が楽。
画面が1000以上あるということは、いくつかのサブシステムに分類することが可能なわけで。
識別子の文字数が制限されていた古代の話だね。

379 :デフォルトの名無しさん:04/10/11 18:50:04
うーん、場所によってだいぶ常識が違うもんだな。

380 :デフォルトの名無しさん:04/10/11 19:08:43
IDを振ったクラス名というの是とする場所の方が少ないし、時代遅れ気味だけどね。

381 :デフォルトの名無しさん:04/10/11 20:27:06
IDで名前付けるってのは、名前付けをさぼってるだけでしょ。
「面倒くさいからXYZ0415.javaでいいや」という。

382 :376:04/10/11 20:47:58
ID肯定派はいないみたいですね。

>そのIDの名前をしたクラスを再利用するときは、どうするんですか?

>パッケージで名前空間をわけるシステムもあるわけで、適切な名前付ける方が楽。

たしかに。

ID付けないときって、名前聞いただけでは何の業務の何のクラスなのか、
想像付かなかったりすることが多くて、番号が振ってあった方が逆に予想が付いたりしました。
微妙に違う機能名が付いてたりすると、どっちがどっちかすぐに分からなくなったりするもんで。
名前の付け方が悪いってことかな、、、


383 :デフォルトの名無しさん:04/10/11 20:55:31
確かにクラス名を考えるのって、無駄に悩む事もあるしめんどくさい。
スペルミスなんてしようものならもう(^^;;
しかし、IDのクラス名ではソースの可読性を著しく損なうのは事実。
大規模になるほど、パッケージを最大限に活用するべきでは?

384 :デフォルトの名無しさん:04/10/11 21:28:29
tilesで画面IDはうめこんでるが

385 :デフォルトの名無しさん:04/10/11 22:19:13
Tilesって便利?
画面ごとにタイル定義書くのめんどくさいんだけど。

386 :デフォルトの名無しさん:04/10/11 23:42:55
>>385
どの画面でも使えるように書く(w

387 :デフォルトの名無しさん:04/10/12 03:12:04
>>386
そういうのってできるの?

388 :デフォルトの名無しさん:04/10/12 21:14:46
>>382
パッケージ名でだいたい判断つくんじゃないの?

389 :デフォルトの名無しさん:04/10/12 21:22:37
>>388
きっと、パッケージ名もIDなんですよ。
jp.co.hoge.prj041.pkg03.CZX0108みたいな感じで。

390 :デフォルトの名無しさん:04/10/12 22:05:49
IDって、覚えてるつもりでも、ちょっと仕事から離れるとすっかり忘れるんだよね。

391 :デフォルトの名無しさん:04/10/13 01:06:21
>>389
それ最悪。。
パッと見、なんのクラスかワカランし。

そんな設計する人と一緒に仕事したくないね

392 :デフォルトの名無しさん:04/10/13 01:19:37
>>391
そのためのID一覧表ですよ。
そのIDがなにを表すかは、JavaDocコメントで記述すれば問題なし。w

393 :デフォルトの名無しさん:04/10/13 10:23:46
>>387
こんな感じ
<html:html>
<title><tiles:insert attribute="title" /></title>
<body>
<table>
<tiles:insert attribute="bodyA" />
<tiles:insert attribute="bodyB" />

</table>
</body>
</html:html>

>>392
その一覧表が変更されリ、更新されなかった悲惨だ・・・

394 :デフォルトの名無しさん:04/10/13 11:24:23
>>393
それって、タイル定義はそれぞれのページに対して書かないといけなくない?

395 :デフォルトの名無しさん:04/10/13 21:26:36
>>394
そりゃあtiles-defs.xml内の定義はページごとになりまんがな。
しかし、基本となるレイアウトを定義して継承し、違うとこだけ書けばいいのでメンテ
は楽ちん。
大体xml一発で全ての画面の構成を管理できるのはデメリットではなく大きなメリットだろうに。

必要なもの:
(1)レイアウトファイル
(2)共通部品(ヘッダ・フッタ・メニュー)
(3)各ボディ部
(4)tiles-defs.xml
ということで、ボディ部の数+(1)の数+(2)の数+1くらいでインターフェースの統一ができる。
先々のことを考えれば安いもんだね。

396 :デフォルトの名無しさん:04/10/13 22:25:52
まぁ俺的に言わせてもらえば。
お前らXSLT使えよ。

397 :デフォルトの名無しさん:04/10/13 22:46:00
それよりTiles Definition使えよ。

398 :デフォルトの名無しさん:04/10/13 23:06:28
>>395
>>333みたいなことをすると、一旦サーブレットを作ってしまえば、あとは新たに手を加えることなくJSP追加するだけだから。
それに静的HTMLでも使えるし。Strutsにも依存しない。
(4)の変わりにサーブレットを作って、あとはレイアウトパターンが増えない限りは触らなくていいし。

そう考えるとTilesのメリットってなんかなぁと。
もっと宣言的に、こういうパターンのURLはこういうテンプレ使うと定義すれば、あとは個々の定義を書く必要がないようになってれば、いいんだけど。

399 :デフォルトの名無しさん:04/10/13 23:13:26
Tiles Definitionでgoogle検索したら一番最初に出てくる@ITのフォーラム。
jspが全部コード名になってて>>371が言うようなのってこんな感じかなぁと思った。

400 :デフォルトの名無しさん:04/10/14 01:10:14
>>392
なんでわざわざメンテするものを増やすのか・・・
理解不能っす。

ID一覧表ってどうせexcelでしょ?
ウゼー

401 :デフォルトの名無しさん:04/10/16 13:03:19
「自分は理解できない」って事を一々表明しなくて結構。

402 :デフォルトの名無しさん:04/10/16 18:02:16

   ,、,、
  (・e・)<「自分は理解できない」って事を一々表明しなくて結構。
   ゚しJ゚




( ´д) ヒソ (´д`) ヒソ (д` ) 


403 :デフォルトの名無しさん:04/10/16 18:49:43
英語で書かれても意味がわからんから、IDでもいっしょ。

404 :デフォルトの名無しさん:04/10/16 20:36:12
英語が苦手な香具師とは仕事したくないなぁ

405 :デフォルトの名無しさん:04/10/16 21:09:44
日本語しか使えないのに日本語が苦手なやつと仕事するのが一番いやだぞ。

406 :デフォルトの名無しさん:04/10/17 19:55:55
XDoclet使うより設定ファイル直書きの方が便利な事ってあります?
今、XDoclet覚えてるとこなんですが・・・
ちなみに発音は「えっくすどっくれっと」でいいのかな。

407 :デフォルトの名無しさん:04/10/17 19:57:34
また先頭打者を出しちゃった・・・

408 :デフォルトの名無しさん:04/10/17 19:57:56
松坂バント失敗しろ!

409 :デフォルトの名無しさん:04/10/17 20:00:40
スリーバント失敗ナイス!

410 :デフォルトの名無しさん:04/10/17 21:07:04
>>406
同じActionを使いまわすとき。

いばた、ナイスヒット。

411 :デフォルトの名無しさん:04/10/17 21:13:08
StrutsでXDoclet使う解説してるページってある?


412 :デフォルトの名無しさん:04/10/17 21:33:20
>>410
XDoclet使わない理由になってない。

>>411
この辺とか、
http://www.itmedia.co.jp/enterprise/0404/26/epn01.html
書籍なら
http://www.gihyo.co.jp/books/syoseki.php/4-7741-1998-9
とか。

413 :デフォルトの名無しさん:04/10/17 21:42:28
>>412
XDocletを使わない理由などだれも聞いてないだろ。

414 :デフォルトの名無しさん:04/10/18 01:10:35
>>411
お前、少しでも検索しようと思ったことあるか

415 :デフォルトの名無しさん:04/10/18 02:31:50
質問なんですが、
ActionFormにBeanの配列なんかを持たせて、
JSPからの入力を受ける事は出来ませんか?

例えば、、、
SampleBeanというクラスで、
String id_;
String name_;
のセッター/ゲッターを書く。

ActionFormで
SampleBean sampleBean_;
のセッター/ゲッターを書いて、
JSP側で
<html:text property="sampleBean.id">
<html:text property="sampleBean.name">
は、出来る。

これを配列にしたくて、
ActionFormで
SampleBean[] sampleBean_ として
JSPで<logic:iterate>の中に
<html:text property="sampleBean.id">
<html:text property="sampleBean.name">
を記述、、、なんてやっても出来ないんです。

ActionFormでid[] とname[]を作れば出来るんですが、
できれば情報をBeanで固めておきたくて、、、
どなたか方法ご存知ないですか?

416 :415:04/10/18 03:12:54
なんか分かりづらいな(汗

要はDBのデータを一覧表示して、
それを自由に編集させたいんです。

id / nameをカラムに持つDBを表示させる時に
テキストボックスにして編集可能にしておいて、
ボタンクリックでDBを一括更新、、、みたいな。

やり方が見つからなくて困ってます。

417 :415:04/10/18 05:07:44
ごめんなさい、自己解決しました。

418 :デフォルトの名無しさん:04/10/18 05:16:36
最近は、自己解決したら解決方法書かないやつ多いな。

419 :デフォルトの名無しさん:04/10/18 05:33:05
教えてください。
class Beans {
  String name;
  BeansList list;
  // setter getter //
}
ってクラスがあった場合、jsp側では、nestedタグやbeanタグを使って、扱えますよね。
REQUESTアトリビュートするとかで。
で、nestedタグ使って表現するときは
<nested:root name="id" property="dataSet(Beans)">
とかすると
<nested:write property="name">
で、Beansクラスのnameの奴が出力される。
んじゃリストのlistが持ってるオブジェクトを使いたいときってどうすればいいんですか?
Beans自体をリストとかにするとiterate使って表現できるんですが、ネストしてイテレータ使う方法が
わかんないです。<nested:nest >を使うんだろうなぁぐらいは予測できんたですが
インデックスアウトオブバウンドや、そんなリストはないとか言われてしまいます。


420 :デフォルトの名無しさん:04/10/18 06:18:39
> jsp側では、nestedタグやbeanタグを使って、扱えますよね。

扱えるけど、いまどきは使いません。
JSTLとEL使ってください。

421 :デフォルトの名無しさん:04/10/19 23:28:41
>>419

#foreach($row in $Beans.list)
<tr>
<td>$row.foo</td>
<td>$row.bar</td>
</tr>
#end

##それはそうと、そもそも型BeansListはjava.util.Collectionsをimplementしてるのか?

422 :デフォルトの名無しさん:04/10/19 23:33:29
>>419

<logic:iterate id="list1" name="beans" property="list">
 <logic:iterate id="list2" name="list1" property="bean">
  ....

でOK

423 :デフォルトの名無しさん:04/10/20 02:03:36
ActionFormでリストを扱うのって、

getXxxList()
setXxxList()
getXxxList(int i)

で出来ることがWebを見て分かったんですが、
これが掲載されている書籍はありませんか?
それぐらい詳しい本が欲しいのですが。

424 :デフォルトの名無しさん:04/10/20 14:42:02
html:checkboxを使っているのですが、値がfalseなのに
チェックボックスがオンになってしまう現象がおこり困っています。

jspはこんなかんじです。

<html:checkbox name="form" property="hoge" />
<%=form.getHoge()%> //デバッグように表示

実行すると、
<%=form.getHoge()%>がfalseを表示しても
常にチェックボックスがonになってしまいます。

どなたか、なにかご存知の方いらっしゃったら教えてください。

425 :デフォルトの名無しさん:04/10/20 20:11:58
Struts使っているやつでVelocityも使っているやつってどれぐらいいるの?


426 :デフォルトの名無しさん:04/10/20 20:35:06
メールの本文生成にはVelocity使うなぁ。
JSP2.0が使える環境なら、HTML生成にVelocity使う必要はないでしょ。

427 :デフォルトの名無しさん:04/10/20 23:30:29
>>425
プログラム全く出来ないデザイナさんだと、
JSPファイル作ってもらうよりVMファイルの方が理解されやすかったです。
ですのでStruts-Velocityバリバリ使ってます。
JSPだと<>で囲われちゃうから、いろいろと面倒が....

JSP2.0は全然触って無いんですが、PGじゃない人でも扱いラクチンです?>>426

428 :デフォルトの名無しさん:04/10/21 00:17:34
JSPってコンパイルに1〜2秒掛かるんで
それ回避できるだけでもVelocity使う
価値がありそうなんですが。

って、Velocity使ったことないんですが
レスポンスはどうなんですか?



429 :デフォルトの名無しさん:04/10/21 00:21:33
> JSPってコンパイルに1〜2秒掛かるんで
はじめの一回だけだろ。イヤならプリコンパイルという手段もあるし。

430 :デフォルトの名無しさん:04/10/21 02:03:59
>>427
<c:if>とかなら、囲まれてても問題はないと思うんだけど。
#ifとc:ifなら同じ程度じゃないかと。
値は${xxx}だし、部品化がタグファイルで簡単にできるという魅力もある。

431 :デフォルトの名無しさん:04/10/21 02:07:06
Velocity使ってる人で、$validator.getJavascript()がちゃんと使えてる人いる?
引数にフォーム名渡すとExceptionするんだけど・・・

432 :デフォルトの名無しさん:04/10/21 02:07:09
とりあえず、式言語が使えるようになった以上、Velocityのメリットってあまりない気がする。

433 :427:04/10/21 11:46:57
>>430
${xxx}なんて書式が出来たんですか!知りませんでしたトンクス。
JSPに戻る気になってきましたw

434 :デフォルトの名無しさん:04/10/21 16:30:56
>>428
ビューのDEBUG中はほぼ毎回コンパイルみたいなもんだから、プロジェクト全体でみると
その差は歴然。
てかJSPのコンパイル1〜2秒ってええ開発環境やなぁ。
うちでは数秒から十数秒ってトコ。だからJSPのロスタイムもバカにならん。
Velocityの場合は、まぁ「瞬時」に出る感じだな。

> って、Velocity使ったことないんですが
> レスポンスはどうなんですか?
ロッドジョンソンの本によると、平均してVelocityはJSPの二倍程度。
しかし、体感速度は圧倒的にVelocityが速い。
なんかトートロジーっぽいが。

435 :デフォルトの名無しさん:04/10/21 19:12:42
VelocityとJSPの違いを体感できるっていうのは、それはそれですごいと思う。
JMeterとかで計った違いしかわからん。

436 :434:04/10/21 19:53:58
>>435
開発環境がしょぼければしょぼいほど差が顕著に判るよ。w
いやまったく。

437 :デフォルトの名無しさん:04/10/21 21:21:42
ActionやJSPをちょっといじるたびにローカルのコンテナにdeployして確認してるのですが、
この作業にやたら時間がかかって、そのたびに2〜3分はタイムロスしてしまいます。
# そのうえLombozがアホみたいにメモリ食うらしくて頻繁にOutOfMemoryでeclipse応答無しになるし。

明らかにこの開発方法は間違ってると思うのですが、みなさんはどうしてるのですか?
この無駄な時間を何とかすれば数倍速く開発できるような気がするのです・・・。

438 :デフォルトの名無しさん:04/10/21 21:34:28
>>430
タグじゃないから、普通のHTMLエディタが使える。

439 :デフォルトの名無しさん:04/10/21 21:43:04
>>437
EJB使わないのならLombozを捨てるのもあり。Sysdeoのプラグイン使ったら?
詳細はEclipseスレでどうぞ。

もしくは、StrutsTestCaseをMockObjectアプローチで実行するとか?
これなら単体テストレベルではコンテナ不要だし。さすがにJSPはそうもいかないが。

440 :デフォルトの名無しさん:04/10/21 21:47:21
>>436
それはコンパイル時間の差でしょ。

441 :デフォルトの名無しさん:04/10/22 00:30:02
>>433
悦ぶのはまだ早い!
${xxx}ってのは、

<c:out value="${xxForm.property}"/>

っていうタグの属性部分のこと。

$xxForm.property

と直書きすれば足るVelocityとは、コードのスッキリ感、htmlとの互換性がまるで違う。
JSTLの<c:>タグ全般的にどうもVelocityの劣化コピーって感じだな。
<vel:>タグのほうがVelociMacros使えるだけましちゃうんかと。

うちではstrutsタグオンリー→JSTL+strutsタグと変遷した後、Velocityに一本化された。
新人教育時間も短くて済むし、生産性もかなり上がってるよ。

Mailテンプレートやら、Hibernate使うほどでもない案件のSQL生成エンジンやら、もう
なにから何までVelocityで事足りてる。


442 :デフォルトの名無しさん:04/10/22 01:44:35
StrutsTestCaseで、
web.xmlに書いたinit-paramを取得する方法ってないですか?

Strutsでは普通に取れるのに、
StrutsTestCaseだと取れなくて・・・。



443 :デフォルトの名無しさん:04/10/22 02:31:29
>>441
ん?ちゃんと${xxx}とどこにでも書けるけど。
ELに対応していないタグの属性にも書ける。JSP2.0って書いてるでしょ。

ま、Velocityを使う体制が整ってるなら、それでいいと思う。

関係ないけど、Hibernate使うほどでもない、というより、最近は逆に、わざわざ手書きでSQL書くほどでもない、という方がしっくりくるんだけど。
どうでもいいプロジェクトはHibernateでSQLレス。
パフォーマンスとか複雑な問い合わせが必要そうだったら、なにか考える、って感じで。

444 :デフォルトの名無しさん:04/10/22 06:45:04
>>442
setInitParameter()で解決します。
Mock版だとweb.xmlの中は見てくれない様子。web.xmlまでは面倒見切れない、ということなんでしょう。

445 :デフォルトの名無しさん:04/10/22 09:19:16
>>441
VelociMacrosって言っても、タグファイルで同じようなことできるんじゃねぇの?

446 :デフォルトの名無しさん:04/10/22 18:27:12
>>441
これから開発でVelo導入するつもりなんだけど、バグとか問題はない?
Struts1.1 + Veloは1.4、VeloToolsは1.1使いますが。

447 :デフォルトの名無しさん:04/10/23 02:22:07
新規ならStrutsは1.2の方がいいよ。
APIがところどころ整理整頓されてるし、
気づいた限りではValidatorのコードに若干修正が必要だったから。

448 :デフォルトの名無しさん:04/10/23 03:23:58
>>446
ということでVeloのメリットは「制御構造がタグではない」「パフォーマンスがちょっといい」ということだけしかないけど、大丈夫?
デメリットは、環境のサポートがないこと、対応が遅れること、タグライブラリが使えないこと、標準ではないこと、などあるけど。

449 :デフォルトの名無しさん:04/10/23 11:33:45
>>448
Velocity使ったことはなさそうだけど?
「制御構造がタグでない」
「パフォーマンスが倍」
ってメリットは「だけ」でまとめてよいものか。
制御構造がタグでないメリットは、さらに
「htmlで造ったページをJSPに「変換」する手間が不要
「htmlエディタで編集可能」
「ブラウザでプリビュー可能」
等に分けられるわけだし。これがあるからこそデザイナにもVelocityは触らせられる。
プログラマが画面作るような簡単なアプリなら話は別だけど。

「環境のサポートがない」よくわからん。
「対応が遅れる」Struts1.2でやってるが不具合は無いが。具体的に何か遅れたことでも?
「タグライブラリがつかえない」必要としないが正しい。部品化・共通化はマクロの外だしで可能。
「標準でない」Java/SunのStandard First戦略の崩壊が叫ばれている現状をなんと見る?
SpringやHibernateの隆盛を見ても分かるように。
View面ではVelocityこそがBetterでLighterでFasterなJavaの一角を担うものである。


450 :デフォルトの名無しさん:04/10/23 11:41:05
とりあえず、JSFが普及するまではStrurts+Velocityでいいんじゃない?
Tapestryよりはましな気がする。開発者とデザイナの分業に着目すればだけど。

451 :デフォルトの名無しさん:04/10/23 12:02:13
Easy Strytsつかっとると、CVSにコミットできないときあるのは
僕だけですか、そうですか。


452 :デフォルトの名無しさん:04/10/23 13:11:58
まぁ、
> 制御構造がタグではない
はある意味何事にも代えられないメリットだわな

453 :デフォルトの名無しさん:04/10/23 15:57:46
今からならVelocityよりもNirvanaじゃない?


454 :446:04/10/23 15:59:06
>>447
あ〜やっぱValidator、1.2と1.1だとフォーマット違うみたいね。
struts.jarだけ1.2に入れ得たらValidationチェックしなかった・・・
あと1.2で1ヶ月前にリリースされたばかりだから安定面で
ちょっとこわいかなぁと思い1.1に戻した。
1.1は結構実績あるしね。

>>449
正直、JSPは嫌。なんで先にVeloみたいなの考えられないのか・・・


455 :デフォルトの名無しさん:04/10/23 16:55:46
JSFが普及・・・・するのか?実際

456 :デフォルトの名無しさん:04/10/23 18:03:29
>>454
そこでS2JSFですよ

457 :デフォルトの名無しさん:04/10/23 19:36:43
>>455
本格普及はリッチクライアントが主流になってから、と見てるんだが。

458 :デフォルトの名無しさん:04/10/23 20:34:22
>>451
コミットできない時はあったかもしれないけど、忘れた。
もうあのクソなプラグインは使っていない。

459 :デフォルトの名無しさん:04/10/23 21:42:58
StrutsのEclipseプラグインでは過去に海外のを使ってみたことがあるけど、
どうもしっくりこなかったり全然使わなかったり。。。

最近また一つ出てきたのだけど、作者が日本人。
これからに期待。

StrutsEclipse
ttp://www3.vis.ne.jp/~asaki/StrutsEclipse/


460 :デフォルトの名無しさん:04/10/24 10:31:07
>>459
たけぞう乙。

461 :Strutsはじめたて:04/10/26 23:39:35
2年ぶりにServlet製造するんだけど、そのプロジェクトでStruts使うというんで、
4千円自腹で
ttp://www.amazon.co.jp/exec/obidos/ASIN/4756143075/250-0022558-6511468
買って読破してみたんだが、読んだことある人、煽らないで教えてくれ。
めずらしく大枚はたいて買ったのに、消化不良で悔しいw

この本のサンプルアプリは、画面間で2つのActionを挟むんだが、なんで1つで
済ませないのかが分かりません。画面1つに1つのActionにするより、ワンクッション
置いて画面分岐する方が再利用しやすいのか?

もひとつ、DynaActionFormって使える?ActionFormをサブクラス化して再利用できないし、
XMLに外だしすんのも、Bean作るのも手間は変わらんと重いまふ。つーかBeanなんて
AntでもEclipseでも作れるし、ファイルにまとめたらかえってファイル競合起こすんでねーの?

オプソのメリットも十分わかる気がするが、そんなに騒がれるほどのフレームワークとも
思えんのだが。。漏れの自作のへたれディスパッチャservletと大して変わらん希ガス





462 :デフォルトの名無しさん:04/10/27 00:05:01
>画面1つに1つのActionにするより、ワンクッション
>置いて画面分岐する方が再利用しやすいのか?
画面表示前処理と送信を受ける処理に分けた方が作りやすいとは思う。慣れの問題もあるが。

> もひとつ、DynaActionFormって使える?
使えない。「ファイル競合」はいまいち意味不明だが、ほぼあなたの言うとおり。

>漏れの自作のへたれディスパッチャservletと大して変わらん希ガス
技術的な完成度はともかくとして、書籍やWebによる豊富な情報量、
すでにスキルを持っている技術者の確保の容易さなどを考慮すると
既に普及しているフレームワークを採用するメリットはあると思う。
未来永劫自分一人でメンテするのならいいんだけど。

463 :Strutsはじめたて:04/10/27 00:42:16
462さんありがとう。もやもやが少しとれますた。

>画面表示前処理と送信を受ける処理に分けた方が作りやすいとは思う。慣れの問題もあるが。
BeanをViewHelperとして使いまわすには、1次受け手のActionFormにいろいろ仕込んどいた方が
いいと思うけど、複数画面から呼ばれる画面など、事前処理を共通化したいときには分けといた方が
いいかもしれませんね。
でも、1次受け手のActionFormと事前処理のActionFormの引継ぎは手動でやらなければ
いけのいのかな?←分からないまましゃべってたらつっこんでください。

ファイル競合とは・・・・新人君のCVSのコンフリクトを思い浮かべると、鬱。
そして先輩面をして、コンフリクトを解決しようとしてアボーン。トラウマになってます。。

CVSを使っても使わなくても、ソースにメタタグを埋め込んで、という最近の時流は、統制管理と
相反するけど、製造フェーズでは正解ですね。メンテフェーズで切り替えればいいし。

>技術的な完成度はともかくとして、書籍やWebによる豊富な情報量、
>すでにスキルを持っている技術者の確保の容易さなどを考慮すると
>既に普及しているフレームワークを採用するメリットはあると思う。
>未来永劫自分一人でメンテするのならいいんだけど。
まったくそのとおりですね。基本的な部分のフレームワークの教育コストが、
自前フレームワーク使用による製造コストの削減分を超えたりしていることにみんな
気づきはじめたみたい。APIといたちごっことか、あたりまえだし。

それではまた後日質問させていただきます。実際にサンプルソースも動かして。
貴重な意見ありがとうございました。

464 :デフォルトの名無しさん:04/10/27 07:23:41
前画面と後画面が作成者が違う場合なんかを想定してるんじゃないかな

465 :デフォルトの名無しさん:04/10/27 09:41:19
>>Strutsはじめたて
自分もはじめて2ヶ月そこそこですが・・・
ttp://www.itmedia.co.jp/enterprise/0404/26/epn01_3.html
ここも読んでおくとよし。DynaActionFormなんかいらない。
あとはVelocity使えばスッキリ。

466 :デフォルトの名無しさん:04/10/27 10:26:59
Velocity使ってもJSP使ってもスッキリ度は変わらないと思われ。
むしろ、JSPだとタグの形で統一されているので、スッキリ度は高い。

ただし、古いHTMLエディタだとJSTLタグを認識してくれないのでデザイナに嫌がられることがある。

467 :デフォルトの名無しさん:04/10/27 19:29:44
Strutsのみだと死ねるね。
JSTL+Struts-ELを使わないとだめ

468 :デフォルトの名無しさん:04/10/27 19:48:10
Tomcat5ならふつうのStrutsタグでおけ。

469 :デフォルトの名無しさん:04/10/27 20:39:18
Strutsインアクション一冊あればOK

470 :デフォルトの名無しさん:04/10/27 20:57:09
厚さのわりに薄い本ね。

471 :デフォルトの名無しさん:04/10/27 21:10:21
内容も古いしね。

472 :デフォルトの名無しさん:04/10/27 21:53:36
Velocity >>(超えられない壁)>>>JSTL+Struts-EL>>>>>>>>>>StrutsTagオンリー

473 :デフォルトの名無しさん:04/10/27 22:05:14
ふつうにJSP2.0+JSTL+Strutsでええやん。

474 :デフォルトの名無しさん:04/10/27 22:25:55
struts-elって <bean-el:write> とかないんだけど、どうするの?
あれは <c:out> とかのJSTL前提で作られてるの?


475 :デフォルトの名無しさん:04/10/27 22:44:03
StrutsTagオンリーだよ・・・。
俺に選択権はないのさ・・・。

476 :デフォルトの名無しさん:04/10/28 03:34:28
独自の糞タグを泣く泣く使ってる俺らに比べればマシです。
ドキュメントも無いのに「ライブラリ」を名乗るな。

477 :∫∈:04/10/28 04:45:23
>>476
正直すまんかった。

478 :デフォルトの名無しさん:04/10/29 17:51:45
Java World 12月号の黒住さんの記事は必読だ。
クリーンなView層をVelocityでつくろう。

479 :デフォルトの名無しさん:04/10/29 19:13:45
みんなが使っているという理由でStrutsを使っているので、みんなが使っているという理由でJSPを使います。

480 :デフォルトの名無しさん:04/10/29 21:40:25
Velocityでカスタムタグみたいなのは作れるの?

481 :デフォルトの名無しさん:04/10/29 21:55:16
velocimacroかな?
入れ子の制御ってできるんだろうか?

482 :デフォルトの名無しさん:04/10/29 21:57:34
Struts+JSP1.2で2本ほど作ったが、あまりの汚さに辟易。
せめてロジックをcoreタグで作るとか、タグ内タグはelに置き換えるとかしたくなる。

483 :デフォルトの名無しさん:04/10/29 23:12:11
それに比べると、JSP2.0は幸せ度高いね。
カスタムタグも、あんなアホみたいな手順踏まずにファイル一個置くだけで作れるようになったし。

484 :デフォルトの名無しさん:04/10/30 00:00:42
Tomcat 5.x + JSP2.0 + Struts 1.2.x で無問題?


485 :デフォルトの名無しさん:04/10/30 00:15:51
Velocityのがいい。

486 :デフォルトの名無しさん:04/10/30 06:16:52
>>484
制御構造がタグでいいなら無問題。
あ、JSTLも必要だぞよ。

487 :デフォルトの名無しさん:04/10/30 15:36:47
>>483
そんなことVelocityなら大昔からできてるやん。

488 :デフォルトの名無しさん:04/10/31 00:16:27
>>487
カスタムタグほどの自由度はないとおもうんだけど。
それと、「いつから出来てた」ということ自体には微塵の価値もない。
それなりの再利用可能な部品がたくさんできてるなら別だけどね。

489 :デフォルトの名無しさん:04/10/31 00:31:38
>>487
俺様フレームワーク厨みたいな言い方だな。
「Strutsなんて糞。もっと使いやすいフレームワークを大昔から自作してるよ」みたいな。

490 :デフォルトの名無しさん:04/10/31 01:42:38
>>489
そりゃただの言いがかりだな。

491 :487:04/10/31 02:00:01
>>488
>自由度
まぁそうだな。
汎用「テキスト」テンプレートなんだから、Velocimacro単体でできるのは
View上のロジックの部品化・再利用ということになる。
他の層にからむような処理をはさむ場合はToolsクラスを作ることになるが、
それでもJSP1.2時代のカスタムタグを作るのに比べりゃ手数は少ないね。
まぁ「大昔から」という言い方は厨っぽかったかもしれん。
いいたかったのはVelocityでも部品化は楽チンなんだよと。
ファイル一個置くだけなのはJSP2.0だけじゃないんだよということをだな。
マイクロソフトがWindows95でプリエンプティブマルチタスクを大々的に世界初のように
歌い上げたときに、ちょっとまてと。OS/2は随分と前からやってるんですがと
いいたかった、WARPユーザーのような・・・いや少し違うか。

まあ>>489は空気の読めない無知厨だが。

492 :デフォルトの名無しさん:04/10/31 02:25:55
>>491
Velocityの日本語サイトみたいに、JSP1.2withoutJSTLと比較してVelocityマンセーという情報が多いのが問題なんだよねぇ。
「それってTomcat5じゃなきゃ使えないでしょ」とかなら説得力あっていいんだけど。

JSP、つぎはタグじゃない形もしくはHTMLへの属性追加でJSTLやカスタムタグを使えるようになってくれんかな。

493 :デフォルトの名無しさん:04/10/31 14:17:33
/BeginAction に対応するマッピングが見つかりません
って意味がわからないし・・・

494 :デフォルトの名無しさん:04/10/31 14:30:27
JSTL,ELがあればVelocityいらね
利点もなし。

495 :デフォルトの名無しさん:04/10/31 14:37:29
>>494
ttp://www.newswatch.co.jp/theme/QTRS/sampledata/JS0800.html
ですか。なるほど、Velocityはいらないですね。

496 :デフォルトの名無しさん:04/10/31 15:03:57
Struts + Tiles + Velocity + S2 (+StrutsTestCase)の連携簡単にできますか?

497 :デフォルトの名無しさん:04/10/31 18:24:27
>>492
Velocityの日本語サイトって?

498 :デフォルトの名無しさん:04/10/31 21:12:05
>>497
ttp://www.jajakarta.org/velocity/

499 :デフォルトの名無しさん:04/10/31 21:37:10
>>496
Struts+StrutsTestCase+Tiles+Velocity+Spring+Hibernateの案件なら
最近多いよ。
フツーにカンタンに連携してます。

S2はうちはいまんとこないなぁ。

500 :デフォルトの名無しさん:04/10/31 22:30:55
>>496
S2Strutsは使わないの?

501 :デフォルトの名無しさん:04/11/01 14:24:14
Action内で入力のエラーをみつけたときにinputに戻るためには、どうするのがいいですか?

502 :デフォルトの名無しさん:04/11/01 14:38:39
>>501
return mapping.getInputForward();

503 :デフォルトの名無しさん:04/11/01 16:55:34
>>502
ありがとー

504 :デフォルトの名無しさん:04/11/02 00:43:47
ActionFormにDate型のフィールドを設けて
JSPから日付型の文字列 (yyyy/mm/dd) を受け取りたいんですが、、、。

intやlongのフィールドには、適宜キャストされて値がちゃんと入りますよね。

同様に日付もparseしてから値を代入してくれるようにしたいんですが、
Action/ActionFormでいちいち変換の実装を行わず
RequestProcessorなどで変換を行うことって出来ますか?

505 :デフォルトの名無しさん:04/11/02 03:51:00
>>498
それ、本家サイトの日本語訳。
ネタが古いなあとは思った。

506 :デフォルトの名無しさん:04/11/02 05:44:02
>>505
日本語サイトって、本家の日本語訳のことを言うと思うんだけど。

507 :デフォルトの名無しさん:04/11/02 05:47:33
>>504
入力エラーのことを考えると、ActionFormにはString型を使う方がいい。

508 :デフォルトの名無しさん:04/11/02 20:20:57
PHPが(・∀・)イイ!!

509 :デフォルトの名無しさん:04/11/03 02:57:20
Strutsを使うことに比べると、PHPは使い物にならん。

510 :デフォルトの名無しさん:04/11/03 13:02:58
PHP?
あぁpukiwikiの、カスタマイズ言語ね

511 :デフォルトの名無しさん:04/11/04 00:57:29
>>496
超簡単だよ。S2Strutsを使えば問題なし。

Struts+tiles+velocity+S2Struts+S2Dao+S2testCaseで開発している。
楽すぎる(w


512 :デフォルトの名無しさん:04/11/05 10:57:07
>>511にはS2器官が芽生えている


513 :デフォルトの名無しさん:04/11/05 15:47:39
FORMを含んだり複雑な色分けしたりする大規模なHTMLテーブルを
Strutsで作るには、JavaScriptとの絡ませ方とか大変になりそう・・・


514 :デフォルトの名無しさん:04/11/05 23:15:37
>>513
そういうのは、何で作っても苦労するもの。

515 :デフォルトの名無しさん:04/11/05 23:15:47
>>513
そこでVelocity使ってデザイナと分業ですよ

516 :デフォルトの名無しさん:04/11/05 23:18:12
>>515
カスタムタグ使えた方が、楽な気がする。

517 :デフォルトの名無しさん:04/11/07 12:46:52
色分けにCSS使えないの?

518 :デフォルトの名無しさん:04/11/11 05:06:45
Nirvanaが一般的なタグで使えるようになればいいのになぁ

519 :デフォルトの名無しさん:04/11/11 05:12:45
Strutsより例えばTapestryの方が遙かにいいと思うのだが、趣味でやってるわけじゃないので結局Struts使ってる罠。


520 :デフォルトの名無しさん:04/11/11 05:27:23
Tapeは、みんなみんなが熟練者じゃないとだめだという噂。
そうなの?

521 :デフォルトの名無しさん:04/11/11 22:10:44
のだった。

522 :デフォルトの名無しさん:04/11/11 22:25:25
つまり、天才の俺様がひとりで使うにはTapestry遥かにいいが、わけのわからぬ下賎のものと一緒に開発するには向いてないということだな。

523 :デフォルトの名無しさん:04/11/14 15:44:31
Velocityだと既存のJSPカスタムタグ使えないですよね?
そんなの捨てろと言われても使わざるを得ないのが仕事だったり。

524 :デフォルトの名無しさん:04/11/14 15:50:48
>>437
俺んところもそう。プロジェクトのポリシーでそうなっているが面倒でしょうがない。
いちいちdeployせずに、オンザフライでコンパイルして動作確認したい。
プロジェクトのディレクトリ構成とか、参考になるようなサンプルプロジェクトないかな?

525 :デフォルトの名無しさん:04/11/14 15:58:17
.properties をnative2ascii 通さなくても使えるようにして欲しいよ。



526 :デフォルトの名無しさん:04/11/14 17:56:07
やっぱeclipse + Tomcat-plugin + Tomcat + Strtusだな!

527 :デフォルトの名無しさん:04/11/14 18:00:35
やっぱNetBeans+Strutsだな。
プロパティファイルも、勝手にnative2asciiされているし

528 :デフォルトの名無しさん:04/11/14 19:16:32
StrutsStudio買ったけど、
結局いまはTomcat-Pluginしか使ってないよ。。。

529 :デフォルトの名無しさん:04/11/14 19:37:29
>>528
StrutsStudioを使わなくなった理由きぼん

530 :デフォルトの名無しさん:04/11/14 22:20:18
>>525
Eclipse使ってるならプロパティエディタプラグイン使うべし。

531 :デフォルトの名無しさん:04/11/15 00:54:13
>>530
Eclipseが重いクソ環境とか、X使えないUNIX環境とかあるのです。

532 :デフォルトの名無しさん:04/11/15 00:58:42
XDocletのタスクのついでに<native2ascii>って書くだけだから、問題なし。

533 :デフォルトの名無しさん:04/11/15 03:41:44
JSP2.0をサポートしているコンテナってtomcatぐらいか?

534 :デフォルトの名無しさん:04/11/15 03:59:17
WebSphereとかResinとか

535 :デフォルトの名無しさん:04/11/15 16:08:56
>>531
Emacs

536 :デフォルトの名無しさん:04/11/23 14:47:56
ActionFormで受け取った情報ってどうやってsessionに保存してますか?
サンプルによってはActionFormオブジェクトごと保存してるのと、
格納用のオブジェクトを生成し、それにデータをうつして、
そのオブジェクトをsessionに保存している場合がある。
後者の方がなんとなく、メモリ効率とか良さそうなんだけど、
Formのメンバが増えたとき格納用のクラスのメンバーも対応して増やさなければ
いけいないのでデータ移し忘れのミスが起きやすそう・・・


537 :デフォルトの名無しさん:04/11/23 15:30:11
>>536
ActionFormは、あくまでも入出力でやりとりするデータのためのモデルだと考えて、セッションに保存するようなロジックのためのモデルとして考えたほうがいい。
そういう考えをベースに、たまたま同じモデルだったり、変換効率や作業効率が気になるときにActionFormをそのまま格納する。

> データ移し忘れのミスが起きやすそう・・・

こういう問題が気になるときには、モデリングの時点で問題がある場合が多い。

538 :デフォルトの名無しさん:04/11/23 15:30:58
× セッションに保存するようなロジックのためのモデルとして考えたほうがいい
○ セッションに保存するようなロジックのためのモデルとは別のものとして考えたほうがいい

539 :536:04/11/23 15:37:25
>>537
>こういう問題が気になるときには、モデリングの時点で問題がある場合が多い。

今作ってるのは、入力画面が3画面遷移して最後に登録を押すとDBに
保存されるような内容です。
なので各画面に対応したActionFormのメンバは登録時に全て必要なわけです。
そういう場合は、やはりActionFormをセッションに保持した方が良いですか?

あと、2画面目、3画面目には戻るボタンがあって、戻ると前入力されていた
内容が入っていて欲しいんですが、ここでもハマってます。
各画面の次へボタンを押したときに呼ばれるActionのscopeをsessionにしておけば、
簡単に実現できるのですが、これもメモリやセキュリティ的にあまりよろしくないかなと。

540 :デフォルトの名無しさん:04/11/23 15:56:48
3画面共通でひとつのActionFormにする。

541 :536:04/11/23 16:00:23
xdoclet使ってるとそういう発想が消えがちだ・・・orz
というか素直に感動しました。
これで今日中に終われそうだ。

542 :デフォルトの名無しさん:04/11/23 16:01:40
DBにそのまま保存する場合は、DB側で扱うモデルを中心に考える。
ORマッピングとかバインディングの仕組み使ってればDBからマッピングするためのモデルができるからBeanUtils.copyPropertiesして、そっちを扱う。
最終的に保存するときはsaveとかやるだけ。

そうじゃなくて、仕組み使わずDB用のモデル作らず、わざわざ自分でSQL書いてるのであれば、最後までActionFormのままもちまわってもいいとは思う。
ActionFormに関してはメモリのことは気にしてもしかたがない。

3画面にまたがるならValidationのことを考えると、登録用のモデルを作って、ActionFormはそれぞれの入力画面ごとにつくってcopyPropertiesした方がいいと思う。

543 :デフォルトの名無しさん:04/11/23 16:05:27
>>541
> xdoclet使ってると

関係が・・・・

544 :デフォルトの名無しさん:04/11/23 16:24:41
>>542
そうですね、validationがあるから1ActionFormは無理っぽいです。
しかし、Formを分けると前の画面に戻ったときに、
前入力した内容を入れておくというやり方がわからないです。
テンプレートにVelocity使ってるんですが、
<input type="text" name="lastName" value="$!inputForm.lastName">
こうしておくとvalidationにひっかかって再びこのページが表示されたときは
入力した内容が入るんですが、他のページから戻ってきたときは
inputFormは消えているので、空になってしまいます。
sessionのattributeに保存した内容を参照するのでしょうか?
そうすると、今度はvalidationでひっかかって、
再表示されたときに、今入力したのと違うものが表示されてしまう気がします。

>>543
xdocletは確かに関係ない。単にstruts-config.xmlの理解不足。スマソ。

545 :デフォルトの名無しさん:04/11/23 16:34:56
>>544
> >>542
> そうですね、validationがあるから1ActionFormは無理っぽいです。
こういう場合にValidatorActionFormが有意。

でもActionFormを使いまわす場合、
例えば3画面のときに1画面目の項目もsubmitできてしまうので、
そういうのを防ぐかValidationが必要になる。
だから見通しを考えるとValidationも共通の方がいいと思う。
(もちろん要求を満たせるならだけど)

546 :536:04/11/23 17:01:54
自分は、使用されるテンプレートとActionFormは一対一になってる方が
わかりやすいかなと思ってます。
なので、やっぱりActionFormを別個作る事にします。


547 :536:04/11/23 17:02:41
で、前のページに戻ったときに、前入力していた内容が入る、
かつvalidationに引っかかって同じページが再表示されたとき、
入力した内容が入る方法を考えました。

-ActionFormのvalidation()メソッドで、
 まずtmpinputオブジェクトに入力内容をコピーしてsessionのattributeに設定。
 その後、validationチェックを行う。
-テンプレートではtmpinputを参照。
 <input type="text" name="lastName" value="$tmpinput.lastName">

こうしておけば、テンプレートでtmpinputを参照したとき
今表示したい内容を参照できるようになると思います。
tempinputは登録完了時に削除します。
ただ、validation()にvalidationチェック以外のロジックを入れるのは
美しくないですが・・・


548 :デフォルトの名無しさん:04/11/23 22:29:38
EasyStrutsって使えますか?
Webアプリ作るときって、htmlの紙芝居を作ってから、
JSPおよびStrutsタグに変えていく方法をとりますか?
もしそうだとすると、htmlをStrutsタグに置換する
ツールとかありますか。


549 :デフォルトの名無しさん:04/11/23 23:12:38
> EasyStrutsって使えますか?
使えない

> Webアプリ作るときって、htmlの紙芝居を作ってから、
> JSPおよびStrutsタグに変えていく方法をとりますか?
そういうことも多い

> もしそうだとすると、htmlをStrutsタグに置換する
> ツールとかありますか。
JBuilderの上位エディションにはそんな機能もあったっけ・・・


550 :デフォルトの名無しさん:04/11/25 09:08:34
>>547
結論としては、Struts Workflow Extensionを使えってことだな。

551 :デフォルトの名無しさん:04/11/27 04:35:14
ActionFormにPOJOを使用できるみたいですが、やってる人います?

552 :デフォルトの名無しさん:04/11/27 04:40:31
いつから?どうやって?

553 :デフォルトの名無しさん:04/11/27 04:54:36
>>552
バージョンは1.2.2ぐらいからじゃなかったかな?
BeanUtils 1.7が必要みたい。
一応、動いたけどvalidationとかどうするのか...
下の通り


・struts-config.xmlの定義

  <form-bean name="sampleForm" type="xxx..PojoBean"/>

・Actionクラス(以下の記述で取得)

 PojoBean bean = (PojoBean) ((WrapDynaBean) ((BeanValidatorForm) form).getInstance()).getInstance();



554 :デフォルトの名無しさん:04/11/27 11:51:09
ここまで書くなら、ふつうにActionForm作ってBeanUtilsのcopyPropertiesのままでいいね・・・

555 :デフォルトの名無しさん:04/11/27 12:43:36
>>554
 ・決まりきった長い1行のコードを記述する
 ・クラスを1個増やしてコピーするコードを記述する
こうちどちらを取るかって事だね。

556 :デフォルトの名無しさん:04/11/27 13:24:08
BeanUtilsのcopyProperties使うよりも
ActionFormにBeanのアクセサ入れる方が綺麗だと考えるこの頃。

557 :デフォルトの名無しさん:04/11/27 13:51:02
ActionForm作成を無駄と考えるよりも、必要なPOJOの方をインターフェイス定義してやった方がいい気がする
ActionFormにimplementsしてやればStrutsとの依存性を切って利用できるんだし

558 :デフォルトの名無しさん:04/11/27 17:17:11
>>557
setterとgetterしかメソッドが無くてもインターフェースを使うのですか?

559 :デフォルトの名無しさん:04/11/27 17:19:16
>>556
だから初めからPOJO使ったほうが綺麗じゃない?

560 :デフォルトの名無しさん:04/11/28 01:41:34
結局、入力モデルのActionFormとエンティティモデルのPOJOには差があるので、copyPropertiesを使う必要がある罠。
ActionFormのプロパティの型は、すべてStringにするのが都合がいいし。
そこを分けないアーキテクチャでやってるならいいんだけど。

561 :デフォルトの名無しさん:04/11/28 01:47:36
全てString ... orz


562 :デフォルトの名無しさん:04/11/28 08:58:34
>>560
だから、何故>>553のやり方ではなく
copyPropertiesでないといけないのか教えて欲しいんですけど。

563 :デフォルトの名無しさん:04/11/28 09:27:51
>>561
そうしないと、入力チェックではじかれたものが消えてしまう
たとえば、数値入力項目をintにすると、入力間違いで「123a」と入力したときに、再入力時には「0」となってしまう。
チェックはValidatorでできるし。型変換はcopyPropeties任せで。
そう考えると、ActionFormのプロパティにString以外の型を使うメリットってあまりない。
もちろんエンティティモデルのBeanには型をつけるけど。

564 :デフォルトの名無しさん:04/11/28 09:29:15
>>562
copyPropertiesでないといけないとは書いてないでしょ。
入力モデルとエンティティモデルをわけないアーキテクチャでやってるなら問題ないよ。

> そこを分けないアーキテクチャでやってるならいいんだけど。

565 :デフォルトの名無しさん:04/11/28 11:29:20
元々、リクエストパラメータはStringで取り出すからね。
他の型の場合は無理矢理(?)StringからInteger等に変換していることを
考えると、ActionFormの段階ではすべてStringで扱い、Model層で適切な
型に変換するのもありではないかとおもう。


566 :デフォルトの名無しさん:04/11/28 14:44:40
BeanUtilsがなければ、変換がめんどうだから適切な型で、ってなるけど。
もうcopyPropertiesまかせでいいじゃん。

567 :デフォルトの名無しさん:04/11/28 19:55:00
>>563
それはcommons validatorつかえば問題ないよ

568 :デフォルトの名無しさん:04/11/28 22:43:35
>>567
「それ」はなにをさしてるの?

569 :デフォルトの名無しさん:04/11/29 00:59:41
>>568
そんなのもわからないの?

570 :デフォルトの名無しさん:04/11/29 01:22:11
>>569
文が長いし、いろいろなものが出てるし。
普通にValidator使っても、型変換チェックではじかれたものが消えてしまう問題は解決できないし。

571 :デフォルトの名無しさん:04/12/01 00:45:46
>>553
どうせならActionもPOJOにしたいな。
S2JSFみたく、Stringを返すActionにできればBEST!
ActionのほうはRequestProcessorいじれば簡単そうだね。

>>553のやりかたでActionFormをPOJOにすると入力チェックはうまくいくのかな?

572 :デフォルトの名無しさん:04/12/01 00:50:48
>>560
ん?

>>入力モデルのActionFormとエンティティモデルのPOJOには差があるので

入力モデルのPOJOつくるって話してたんじゃないの?

573 :デフォルトの名無しさん:04/12/02 21:03:13
lomboz でJSP書いているけど、カーソルと実際の編集行が追従しなくなる。
こんなヘンテコなのじゃなくてスレ住人のお勧めJSPエディタ教えてくらはい。

574 :デフォルトの名無しさん:04/12/02 21:04:59
struts-config.xmlを読み込んで画面遷移を視覚化したHTMLを吐いてくれるような
ツールないかな。doxgenみたいな感じで。

575 :デフォルトの名無しさん:04/12/02 22:37:41
strutsdocはちょっと違うな

576 :デフォルトの名無しさん:04/12/04 20:15:12
Struts-ELってのがあるみたいですが
JSTLではだめなんでしょうか。

577 :デフォルトの名無しさん:04/12/04 20:23:32
商用コンテナって JSP2.0 サポートしてないのあるね。
EJBの規格とかはいち早く対応するのに変なの。

578 :デフォルトの名無しさん:04/12/04 20:33:35
>>576
なにか誤解してない?

579 :デフォルトの名無しさん:04/12/04 20:34:02
>>577
> EJBの規格とかはいち早く対応するのに

そうでもない。

580 :デフォルトの名無しさん:04/12/07 00:45:32
>>573
結局 solareclipse とか xmlbuddy とか使ってる・・

581 :デフォルトの名無しさん:04/12/07 01:05:47
>>580
JBossIDE1.4も色分け表示とかしてくれるよ

582 :デフォルトの名無しさん:04/12/07 11:47:52
まともなJSPエディタはお金出して買えってことかな・・

ところでStrutsのメッセージリソースだが、
たとえばセレクトボックスの中身を出力するときなど配列でほしいときは
なにかお勧めのやり方あります?
一つ一つJPSに書くのもあほくさいし、毎回クラスを作るのも更新が面倒。

583 :デフォルトの名無しさん:04/12/07 21:53:52
LavelBean だったかな

584 :デフォルトの名無しさん:04/12/07 22:12:55
NetBeansのJSPエディタで満足している。

585 :デフォルトの名無しさん:04/12/07 23:21:14
>>582
これどうよ
http://amateras.sourceforge.jp/cgi-bin/fswiki/wiki.cgi?page=EclipseHTMLEditor

586 :デフォルトの名無しさん:04/12/08 00:51:35
>>583
org.apache.struts.util.LabelValueBeanじゃないのか?

587 :583:04/12/08 21:50:22
>>586
さんきゅ。それそれ。

588 :デフォルトの名無しさん:04/12/10 00:27:14
システムコンサルティングを某sierで行っているセキュリティアドミニストレータです。<br>
Strutsで大変困ってます!すぐに教えて下さい!!<br>
これが実現できないと、このプロジェクトの拡張性が犠牲になってしまいます!<br>
大変なんです!<br>
strutsで画面を遷移を制御する場合、ActionServletへリクエストを投げることは<br>
よく知られたノウハウの一つですが、今回のプロジェクトリーダが<br>
私の作った汎用的な日付生成クラスに、<br>
勝手に”昭和5年”と書いてしまったんです!<br>
javac怒りまくりです!!しばらく機嫌直りません!!<br>
あれほど私がすっぱく、甘い匂いがするまで待てと<br>
念押したにも関わらず、このような事態に陥ってしまいました。<br>
本当に油断も隙もない、荒れた世の中です。

589 :<br>:04/12/10 00:28:32
すげぇ

590 :デフォルトの名無しさん:04/12/10 00:41:19
Struts-ELはstrutsのタグにELが使えるだけのやつ
JSP2.0以降は必要ない

JSTLはタグ内にELが使えるタグライブラリ。logicタグよりはるかに使える
XSLTに構文も似てるし覚えやすい

591 :デフォルトの名無しさん:04/12/11 02:26:43
>>590
いきなりどうした

592 :デフォルトの名無しさん:04/12/17 00:11:26
>>590
JSTLやELってどんな時に使えばいいのか想像できない。Actionのなかでやらばいいじゃん。

593 :デフォルトの名無しさん:04/12/17 00:14:26
>>592
プレゼンテーションロジックを書くとき。

ActionはControllerだから処理はさせない方がいい。
ビジネスロジックはModel、プレゼンテーションロジックはView

>>590は何らおかしくない

594 :デフォルトの名無しさん:04/12/17 00:32:13
ELがあれば、BeanかMapかListさえViewに渡せばいいんでJSP書くのが凄く楽になった

595 :デフォルトの名無しさん:04/12/17 00:35:50
アカウント登録のページ作ってるんだけど、
ユーザーが任意のIDを入力できて、同じIDがDBに登録されてたら
入力ページで、「すでにそのIDは使われてます」って出したい。
このIDがDBに登録されているかどうかのチェックって、
Formのvalidate()で行うべきか、Actionのexecute()で行うべきかで迷う。

596 :デフォルトの名無しさん:04/12/17 00:39:59
>>593
ていうか
>Actionのなかでやらばいいじゃん。
この書き方だとアクションクラスにメイン処理書いてる
たぶん

>>595
FormでDBアクセスなんてしたくねーな

597 :デフォルトの名無しさん:04/12/17 05:36:47
validateは入力の整合性をチェックするためにあるので、トランザクションにかかわるような処理は行うべきじゃない。

598 :デフォルトの名無しさん:04/12/17 07:39:57
>>595
それはView/Controller層の入力値検査処理ではなく、業務ロジックなので
Model層で行うべき。

599 :デフォルトの名無しさん:04/12/17 07:55:39
>>594
それってELがなくても同じでは?

600 :595:04/12/17 08:23:33
なるほど。
では、誕生日が年、月、日で入力フィールドが別れている時はどうでしょう?
年、月、日単体でのチェックだけでなく、実際に存在する年月日であることと
うるう年のチェックなんかをしなければなりませんが、
それはどちらで行いますか?

601 :デフォルトの名無しさん:04/12/17 10:04:25
>>600
「入力の整合性」
業務ロジックには関係ないだろ。

602 :デフォルトの名無しさん:04/12/17 10:07:02
>>599
たぶん、「〜さえ渡せば」じゃなくて「〜を渡しさえすれば」ということを言いたかったのだと思われ。
ELがなければ、「〜」を渡したときにそれぞれの処理をするコードを書かないといけない。
Listならイテレータ使って、MapならgetしてBeanならゲッター呼び出して

603 :デフォルトの名無しさん:04/12/18 02:35:56
>>602
Listはまぁイテレータ必要だと思うけど、
少なくともBeanならゲッター呼ばずに、ドットで繋げば良いだけだろ?
<html:text property="bean.userName"/> で。

Mapにしても、マップバックドを踏まえてるように思えん。

604 :デフォルトの名無しさん:04/12/19 16:37:45
データモデルクラスはデータを保持するためのもの。
ActionFormBeanは表示用データを格納するためのもの。

理屈は分かるんだが、イマイチ実際に開発始めると上手く行かない。
エラーチェックをするときは、データモデルクラスの方がいいんだが
(「1,000」という文字列データより、1000というint型データの方がいい、とか)
でもエラーチェックはマスタデータなんかを参照することもあるから、
EJBのビジネスデリゲータ以下のレイヤでやりたい。
でもエラーチェックには明細データのページ番号なんかも必要
(エラーが発生したときに、エラー発生ページに飛ばしたい)
だが、データモデルクラスにはページ番号のような画面表示制御用の情報を持ちたくない。
ちょっとしたジレンマを感じる。

同じ理屈で、画面上一行飛ばしで入れたデータをデータモデルクラスに変換するとき。
空の明細データを残すのがいいのか、残さないのがいいのか、すごく迷う。
空行を詰めてしまっていいのなら問題ないが、空行も入れたまま、もう一度画面を表示したい場合、
空データをデータモデルクラスに入れないといけないな・・・、とは思うが、
空行があるかどうかは表示の問題で、データクラスには空行を入れることに必然性はまったくない。

迷う。

605 :デフォルトの名無しさん:04/12/19 16:44:45
読解力が必要となるレスですね。

Validationをもっと信頼シロ。必要なら作れ。
表示の問題は、表示側で解決シロ。

606 :デフォルトの名無しさん:04/12/19 17:03:17
>>604
ちょっとしたつっこみ。
org.apache.struts.action.ActionFormBean は Struts設定ファイルの
<form-bean>要素に設定された設定値を保持しているコンポーネント。
ActionForm(のサブクラス) の間違いでしょ?

607 :デフォルトの名無しさん:04/12/19 17:04:06
>>604
> ActionFormBeanは表示用データを格納するためのもの。
は?

608 :デフォルトの名無しさん:04/12/19 17:18:14
>>605
マスタのデータ存在チェックとかもvalidatorでやるの?
名細部に社員コードを入れた。
submit。
送信されたデータがマスタに存在しない。
画面上、マスタのチェックに引っかかった明細のページを開いて、その入力欄にマークを付けたい(*)。
という場合も、validatorでやってる?

>>606
うーん。


うん。

609 :デフォルトの名無しさん:04/12/19 17:23:01
>>608
少し上のレスも読めないんだな
おまえには一生理解できないかもな

610 :デフォルトの名無しさん:04/12/19 17:30:09
>>609
読んで自分も引っかかった覚えがあったので蒸し返したんだが・・・。
って、俺、何、言ってるか分からない?

611 :デフォルトの名無しさん:04/12/19 20:38:48
>>610
蒸し返したというより、理解できなかったから繰り返しただけにしかみえない。

612 :デフォルトの名無しさん:04/12/19 20:51:22
>>610
>という場合も、validatorでやってる?

やらない、と書いてあるしな。

613 :デフォルトの名無しさん:04/12/20 23:40:22
>>600
年月日をくっつけた値を返すgetterメソッドを作って、それをValidatorに
dateチェックさせればOK。エラーになっても元の年月日のフィールドに
値は残っている

>>603
Beanを単純に表示するだけならStrutsのタグでも十分だけど
属性に値をセットして色々したいときには<%= %>で書かなきゃいけなくなるから面倒
EL使えばView表示に関するロジックは全く書く必要が無く、データを渡してやるだけで済む
JDK5.0のようにラッパーオブジェクトをプリミティヴ型のように使えるし

614 :デフォルトの名無しさん:04/12/21 00:18:12
>>613
EL使ってループや分岐の一つ書くだけでも充分ロジックだと思います

615 :デフォルトの名無しさん:04/12/21 07:48:18
140 名前: ('A`) 投稿日: 04/12/18 05:20:57
日本テレビでいい男ランキングが開催されています!2chの力を使ってパペットマペットを一位にしよう!!
日本テレビ「@サプリッ!」 http://www.ntv.co.jp/supli/
投票ページ http://www.ntv.co.jp/supli/rank/otokomae_02.html
途中ランキング http://www.ntv.co.jp/supli/rank/otokomae_03.cgi
4分半ごとに投票出来ます。
他の板のスレにもコピペしまくって下さい!
みんなで力をあわせて頑張りましょう!!


616 :デフォルトの名無しさん:04/12/21 18:47:06
>>604
>でもエラーチェックはマスタデータなんかを参照することもあるから、
>EJBのビジネスデリゲータ以下のレイヤでやりたい。

>>605
>Validationをもっと信頼シロ。必要なら作れ。
>表示の問題は、表示側で解決シロ。

>>608
>>605
>マスタのデータ存在チェックとかもvalidatorでやるの?

ということかと。
>>612


617 :デフォルトの名無しさん:04/12/23 08:14:35
しかし、マスタの存在チェックとかも、起動のタイミングはvalidatorになるね。

618 :デフォルトの名無しさん:04/12/23 08:47:39
データ更新フォームでのデータの取得って、どこでやる?
更新ページのAction?ActionFormのreset?

619 :デフォルトの名無しさん:04/12/23 23:37:48
>>618
おれはDynaActionForm派なのでActionでやっている。

620 :デフォルトの名無しさん:04/12/23 23:39:37
>>618
何度も出てるけどデータベースに接続したいならModelでやれ。

>>619
何度も出てるけどDynaのメリットなんかもはや無い。乗り換えろ。

621 :デフォルトの名無しさん:04/12/23 23:41:07
>>620
で?
そのModelの呼び出しはActionとActionFormのresetとどこでやるの?

というか、Modelってなにを表すの?

622 :デフォルトの名無しさん:04/12/23 23:45:49
Struts使う前にやるべき事があるようだな。

623 :デフォルトの名無しさん:04/12/23 23:49:15
>>621
MVCのM

624 :デフォルトの名無しさん:04/12/24 00:03:18
また、MVCとか、古臭いことを持ち出してきたね。
で、StrutsでMVCっていうなら、M(ActionForm)、V(JSP)、C(Action)だから、ActionFormでやれ、ってことかな?

625 :デフォルトの名無しさん:04/12/24 00:11:51
620は、ActionFormにデータベース処理を記述する人なんだろうか。

626 :デフォルトの名無しさん:04/12/24 00:42:16
>>624
ActionFormはModelか?
本当にそう思っているの?

627 :デフォルトの名無しさん:04/12/24 00:43:37
StrutsはControllerしか賄わないフレームワークですよ

628 :デフォルトの名無しさん:04/12/24 00:53:39
>>626
そう思ってないけど、Strutsの文脈でなんの説明もなくMVCといったときには、その割り当てが一般的だ。
それと、Strutsから先の部分ではMVCである必要もなく、むしろVO+DAOの方が最近の流行みたいだから、Struts自体がMVCのどれにあたるかという話自体が前提条件を欠いている。

629 :デフォルトの名無しさん:04/12/24 00:56:49
それから、ここでの質問は、ActionとActionFormのresetのどちらに処理の起点を置いたらいいのかという話なので、アプリケーション全体のMVCの話をされてもどうしようもないです。

630 :デフォルトの名無しさん:04/12/24 01:13:15
ActionForm内でDBにアクセスするなと書いているのに解決しないのですか?

631 :デフォルトの名無しさん:04/12/24 01:24:03
ActionForm内で、というのが、ActionForm起点の処理で書くなという話なのか、処理自体の記述を別のところに書けという話なのか、わかりづらいもので。
それと、resetメソッドの役割を考えると、Strutsの仕組み的にはresetメソッドで書くのがスッキリするのではないかと。
フォーム初期化のためだけのActionができてしまうことになるし。

632 :デフォルトの名無しさん:04/12/24 01:24:42
Modelでやれ、とか、どうとでも取れるのもあったり。

633 :デフォルトの名無しさん:04/12/24 01:47:08
>フォーム初期化のためだけのActionができてしまうことになるし。
別にかまわない。

634 :デフォルトの名無しさん:04/12/24 01:51:30
Strutsの仕組み的には、Actionでビジネスロジックを呼び出す方がすっきりしています。

635 :デフォルトの名無しさん:04/12/24 01:57:16
>>633
ActionFormに処理を記述して関わるActionを減らすより、ActionFormをシンプルにして関わるActionを増やす、ってことですね?

636 :デフォルトの名無しさん:04/12/24 02:13:32
ていうか、jspに遷移したければかならずActionを経由させるようにする。
その修正用画面に遷移するときも当然Actionを通る。
何ら問題はない。

637 :デフォルトの名無しさん:04/12/24 03:11:23
選択項目の準備とか、多対多関連があって項目数が増減するフォームの準備は?

638 :デフォルトの名無しさん:04/12/24 09:00:45
Action通そうが通すまいが変わらない問題だろうがそれは

639 :デフォルトの名無しさん:04/12/24 09:41:53
>>638
ということは、Action以外の場所で準備するの?

640 :639:04/12/24 09:47:14
×場所
○タイミング

641 :639:04/12/24 12:00:27
入力エラー時を考えると、この場合は、ActionFormのreset以外に書くタイミングがなさそうだ。
そうすると、ActionFormではDB処理をやらない、っていうのはresetに関しては適用できないってことかな。

642 :デフォルトの名無しさん:04/12/24 12:25:55
>>641
バカじゃねえの?

643 :デフォルトの名無しさん:04/12/24 18:48:34
>>642
そう言うなら、多対多関連があって項目数がDB上のデータによって変わるフォームの項目の設定を、どこでやればいいか教えてください。

644 :デフォルトの名無しさん:04/12/24 20:55:49
>>643
Model(ビジネスロジック)

あーあー日本語の通じないアホの相手は大変だな

645 :デフォルトの名無しさん:04/12/24 20:59:38
>>643

public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) {

  // ここでBL呼び出して処理すりゃいいだけだろ
  // あとお前はStrutsの前に山ほど勉強すべき事があるようだ
  // 話が全然噛み合わねえんだよ

  return mapping.findForward(FORWARD_failure);

}

646 :デフォルトの名無しさん:04/12/24 23:15:16
珍しくこのスレでも答えが返ってくるくらいレベルの低いのが来たなw

647 :デフォルトの名無しさん:04/12/24 23:53:33
Strutsってのは、馬鹿でも作れるフレームワークじゃなくて
わかっている人が楽をしたり、チームで開発手法を統一したりするための
フレームワークなのに、そのことをわかってない馬鹿が多すぎ。
流行っているから手を出そうとするか、フレームワークって言葉に飛びついてるのか知らんけど
もっと基礎を勉強して欲しいと思う。

648 :デフォルトの名無しさん:04/12/24 23:57:57
>>647
俺なら馬鹿にも作らせられるが・・・。

649 :デフォルトの名無しさん:04/12/25 04:21:41
Modelがビジネスロジックだと言ってしまうのは、どうかと思うが。

>>645
呼び出し順としては、
 ActionForm#reset
    ↓
 ActionFormへ入力値のパック
    ↓
 Action#execute
なので、executeでActionForm中のArrayListの項目を用意しても、手遅れなんですよ。
 ActionForm#resetでDBから項目を読み込んでArrayListを準備
    ↓
 ActionFormへ対応する入力値のパック

650 :デフォルトの名無しさん:04/12/25 04:25:46
Strutsの話でModelといえばActionFormだし、Strutsの外ではMVCである必要がないから、Modelと単に言われても前提条件を欠いてると。
Modelをビジネスロジックとか言ってるし、MVC妄想をひきずってるとしか思えん。

651 :デフォルトの名無しさん:04/12/25 04:39:12
>>645で充分OKなんじゃないかと思うのだが。
まあ>>649が情報出してくれないんでこれ以上答えようがないな。

>>650
>Strutsの話でModelといえばActionFormだし、Strutsの外ではMVCである必要がないから
意味がワカンネ。

652 :デフォルトの名無しさん:04/12/25 04:50:12
たとえば(最近は使う人がいなくなったけど)DynaFormを使うとしたらどうしろってんだ?
つまりStrutsはもともと645のような、そういう使い方を想定して作られているということ。
まあ、それをどう使い倒そうがそれは当然使う方の自由だけど、
大抵のことはこのやり方で十分可能。

>>649
漠然と「多対多関連があって項目数がDB上のデータによって変わるフォームの項目の設定」と
言われても実際どういうのを指しているのかがよく和下欄のだけど、
ListとかMapあたり使えば大抵のデータはどうにでもなるはずだ。
あとたぶん設計が糞。

ていうか、「ActionForm#resetじゃないと実現できません!」って言い張るなら
なぜこんなとこで質問したのかが和下欄
人の意見なんか聞くつもりないなら最初からそうやっとけよ。

653 :デフォルトの名無しさん:04/12/25 04:56:41
>>649
Actionを通してjspにフォワードするんなら、
executeでActionForm中のArrayListの項目を用意すれば
jspではsetしたその値が使えるはずだぞ。

どういうやり方してるのか、謎すぎる。

654 :デフォルトの名無しさん:04/12/25 05:00:14
>>651
ActionForm以外の部分を指してModelといわれても、MVCモデルでアプリケーションを作ってないなら該当する部分がないし、MVCモデルでアプリケーションを作る必要があるわけでもない。
むしろ、アプリケーション全体をMVCモデルにするのは、流行ってない。

655 :デフォルトの名無しさん:04/12/25 05:05:10
多対多関連がある項目で、入力項目数がDBで決まるとき

class SampleForm extends ActionForm{
 List sub = new ArrayList();アクセッサ略
}
とあるときに、subの項目数がDBに依存するとき

class SampleAction extends Action{
 ActionForward excute(略){
  int count = db.getCount();//データベースから項目数を取得
  if(form != null){
   for(int i = form.size(); i < count; ++i){
    form.sub.add("");
   }
  }
 }
}

としてJSP中で
<c:forEach items="${sampleForm.sub}" var="item" varStatus="i">
 <html:text property="sub[${i}]"/><br>
</c:forEach>

としても、入力後、Action#executeに渡る前にActionFormに入力値が格納されるから、手遅れと。

656 :デフォルトの名無しさん:04/12/25 05:07:21
form.size() → form.sub.size()

657 :デフォルトの名無しさん:04/12/25 05:14:36
class SampleForm extends ActionForm{
 List sub = new ArrayList();アクセッサ略
 void reset(略){
  int count = db.getCount();//データベースから項目数を取得
  for(int i = sub.size(); i < count; ++i){
   sub.add("");
  }
 }
}
としておくと、とりあえず丸くおさまる。

658 :デフォルトの名無しさん:04/12/25 05:57:08
reset()ってチェックボックスのパラメータを初期化するために出来たメソッドでしょ?
そこでDB接続ってなんか間違ってないか?

659 :デフォルトの名無しさん:04/12/25 06:29:25
間違ってるというのなら、どこに書けばいいか教えて欲しいという話。

660 :659:04/12/25 06:37:30
あ、コンストラクタでよさそうだ。

661 :659:04/12/25 06:51:17
だけど、コンストラクタにはrequest情報が来ないから、DB接続をどこから引っぱってくるかが問題になるな。
ThreadLocal使うしかない。
requestから情報もってこようとすると、resetしかないということになりそう。

662 :デフォルトの名無しさん:04/12/25 07:37:21
入力画面を呼び出すときに、ActionクラスでDBから情報を取得。
ActionFormをnewして情報をセットして、遷移先JSPのFORMのスコープに格納する
KEYはstruts-configで定義したformの名前。
これでJSP画面が出たときには、既にActionFormに情報がセットされた状態になっている

ModuleUtils、Struts1.1ならRequestUtilsを使えば、actionのpath情報からform名やClassTypeを取得することも可能

663 :デフォルトの名無しさん:04/12/25 07:42:12
>>662
それだと、入力エラー時にActionFormを構築するタイミングが取れないので、問題ないですか?

664 :デフォルトの名無しさん:04/12/25 07:43:40
submit時の入力値のパッキングに間に合わない気が。

665 :デフォルトの名無しさん:04/12/25 07:48:09
>>663
スコープがリクエストってこと?
なんか条件が限定的すぎない?

666 :デフォルトの名無しさん:04/12/25 07:52:21
>>665
違います。
項目数がDBで決まるの入力項目があって、String[]でもってもListでもっても、その領域確保のタイミングがreset以外に取れないという話。
ActionServletからAction#executeが呼び出される前に、その配列/リストに入力値が格納されるから、executeで領域確保しても手遅れで。

で、それは考え方としておかしいということなので、考え方としておかしくない実現方法を教えてほしいわけです。

667 :デフォルトの名無しさん:04/12/25 07:54:00
あ、scopeをセッションにすれば解決するってこと?

668 :デフォルトの名無しさん:04/12/25 07:58:14
>>667
アクセスするたびに項目数が変わるとかでなければsessionスコープで対応すればいいと思った

669 :668:04/12/25 08:00:13
あ、別に変わっても関係ないか
入力項目など画面構成に関わる情報は、その前のActionで取得するのが普通だと思うけど

670 :デフォルトの名無しさん:04/12/25 08:06:22
scopeをsessionにすればいいってわけか。
それはそれで気持ち悪いけど。

671 :デフォルトの名無しさん:04/12/25 08:09:05
>>668
そしたら、sessionスコープが使えるときはAction#executeに書いて、複数画面同時に使うとか、ゆっくり使うからタイムアウトしても問題ないように、とかsessionスコープが使えないときはActionForm#resetメソッドということかな。

672 :デフォルトの名無しさん:04/12/25 08:21:49
うーん、しかしこういう場合にsessionスコープ使うと、複数画面で同時に入力してしまうと、ユーザーが意図しないデータが入ってしまいそうで怖いなぁ。
TransactionTokenは必須だな。

673 :デフォルトの名無しさん:04/12/25 08:24:01
そこまで気を使うくらいならresetメソッドの方がいい気がする。
resetにDB接続処理書いても、開発者が気持ち悪いだけで、ユーザーには弊害ないから。

674 :デフォルトの名無しさん:04/12/25 09:39:39
MVCイラネ

675 :デフォルトの名無しさん:04/12/25 10:26:55
プレゼンテーション層では、MVCがいいと思うよ。
MVCのModelのことを業務ロジックと言ってしまう人が現れるから、問題あるけど。

676 :デフォルトの名無しさん:04/12/25 11:21:28
ModelViewController
「ユーザーインターフェースでの」やり取りを3つの役割に分割する
ttp://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?ModelViewController

677 :デフォルトの名無しさん:04/12/25 11:55:37
>>675
いやでも、2種類のMVCがあるのは事実だし。
MVCのModel=ビジネスロジックってのも間違いじゃない。
(・・・ってのはわかってるんだよな?)
なんか、変な風にかみ合ってないように見えたので念のため。

ttp://www.atmarkit.co.jp/fjava/javafaq/j2ee/j2e07.html


678 :デフォルトの名無しさん:04/12/25 12:00:44
subのsetterを作って、
Action#execute()でDBからサイズを取得→List構築→ListをActionFormへセット→forward→JSP表示
じゃダメなの?

679 :デフォルトの名無しさん:04/12/25 12:03:56
つかさ。

>>655
>としても、入力後、Action#executeに渡る前にActionFormに入力値が格納されるから、手遅れと。
これが意味わかんねーんだよな。
なんか全然とんちんかんなこと言っているように聞こえるんだけど、
思うところがあるんかね?

680 :デフォルトの名無しさん:04/12/25 12:13:25
>>678
そこからSubmitされたときに、Action#executeでListが構築される前に、構築されてないListに値を放り込まれてException。

681 :デフォルトの名無しさん:04/12/25 12:14:43
なんか、初期表示時にActionかませてないだけにも思えるけどなー・・・。


682 :デフォルトの名無しさん:04/12/25 12:36:46
ああ、やっとわかった。
俺もsessionスコープでやるか、requestスコープの時はresetでList構築してる。

683 :デフォルトの名無しさん:04/12/25 13:00:26
>>681
問題は初期表示のときじゃなくて、Submit時なんだって。

684 :デフォルトの名無しさん:04/12/25 13:09:58
>>677
4年前は確かにMVCのMでビジネスロジックをまかなうっていう考えが流行っていたけど。
いまさらWebアプリケーション全体をMVCで考えるなんてバカげたことしないし、少なくともMVCで考えてない人が普通にいるのに、プレゼンテーション層以外の部分をModelと指されても、困るわけさ。

685 :682:04/12/25 13:14:23
>>683
ただし、reset()の中でDBアクセスはしない。
初期表示前ActionでDBからList情報を取得、List構築をしたときに
要素数だけsessionスコープなどに入れておき、resetの中で
sessionスコープから要素数を取り出してList構築すればよい。
resetでDBから持ってきてしまうと、タイミングによっては
画面に表示されている項目数と送信時の項目数が変わってしまう可能性があるのでは?

686 :デフォルトの名無しさん:04/12/25 13:23:29
>>685
そうするなら、sessionスコープでやってしまえば?
リスクは一緒なんだし。

マスタが変更されたときに、そのタイミングで項目数が変わるリスクよりも、複数画面開いて同時進行したときに項目数が変わるリスクの方がいやだな。
マスタが変更されたときの動作の矛盾は、いたるところであるわけだしねぇ。
それより、ユーザーの操作を制限してしまう方がいやだ。

687 :デフォルトの名無しさん:04/12/25 13:47:14
>>686
そうすると入力値までsessionスコープで保持してしまうから
適切なタイミングでクリアしなければならない要求があった場合に
対応がめんどくね?

688 :デフォルトの名無しさん:04/12/25 13:48:08
>>684
別にModelったって、最近のは、
データを格納しているModelにメソッドとして直接ビジネスロジックを記述しているものだけを指しているわけでないよ。
業務ロジックを隠蔽した、Delegateなり、Facadeなりで呼ばれる単独クラスなんかも含めて、
慣例的にModelと呼ぶんだよ。

689 :デフォルトの名無しさん:04/12/25 13:57:02
>>687
そんときはそんときじゃない?
頻繁にある要求じゃないし。

690 :デフォルトの名無しさん:04/12/25 14:00:35
>>688
それはそれで、慣例的に呼んでる、実際にどういう構造を示してるかわかりにくいものを、いきなり出されても困るという話になるのだが。
今の共通認識としては、ファウラーのMVCが有力候補なわけだし。

691 :デフォルトの名無しさん:04/12/25 14:18:14
まあ、resetメソッド中でDBアクセスするのはいただけないな・・・
例外が起こった時の対処はcatchして握りつぶすしかなくなってしまうし。
DBアクセスが必要な処理はexecuteから呼び出されるべきだと思うよ。

692 :デフォルトの名無しさん:04/12/25 14:38:51
ただ、そのためにユーザー操作を制限していいのかどうか。
どうせそんなデータ取得時に例外発生したときには「メンテナンス中です」と出すしかないわけだし。

「万一複数画面で同時に入力を進めたときには、誤ったデータが入ることがあります。
開発者のポリシーを全うするためなので大目にみてください」

っていうのはどうかと。
resetメソッドでDB処理呼び出せば発生しない問題を抱えてまで、こだわることじゃないと思うなぁ。

693 :デフォルトの名無しさん:04/12/25 14:45:58
ここはWebプログラミングのごとき低レベルなスレですね。

>>679
それをずーっと上の方で書いているんだけど、理解してくれないぽ。

694 :デフォルトの名無しさん:04/12/25 14:48:17
>>693
どれのこと?

695 :デフォルトの名無しさん:04/12/25 15:12:54
StrutsってFormに自動設定するときに必ずアクセサ経由するんだろ?
そんときにListサイズを、配送されてきたリクエスト値の名称のサイズに広げる、とかできないの?
<input type="text" name="text01" value=""><br>
<input type="text" name="text02" value=""><br>
見たいのが送られたら、ArrayListがnullだったら、newして、addよぶ。
sub = new ArrayList();
sub.add(str);
nullじゃなかったら、そのままaddする、
sub.add(str);
みたいな。
仕組み的になくても、setterでごりごり書いたりもできそうじゃん。

と外野が口を挟んでみたり。

696 :デフォルトの名無しさん:04/12/25 15:21:56
>>695
結局、ActionFormからDB処理を呼び出すことになるんじゃない?
それだとrequestが得られないし。
それで処理がちょっと複雑になるならresetメソッドに書いたほうがよさげ。

697 :デフォルトの名無しさん:04/12/25 15:27:23
>>692
>>685の方法を使えば、resetでDBアクセスする必要は無いしFormの複数画面共有の問題も発生しない
FormでDB接続の是非よりも、submitする度にForm初期化だけの為にDBアクセスすることの性能問題の方が重要な気もするけど

>>695
たしかListのときはproperty名[0]みたいなアクセスするんで、addは使えないと思う
・・・っていうか、SortedMap使えばいいような気がしてきた

698 :デフォルトの名無しさん:04/12/25 15:38:04
>>697
話を単純にするために要素数だけにしてるけど、実際にはそれぞれの要素の値をひっぱってきて保持することが多いよ。
どうせsubmitの度にそのデータを表示するわけで、使わないわけじゃないからムダにはならないし。
性能問題は、組みやすく組んでおいて、プロファイリングで問題があったところをチューニングすればいい話で。

699 :デフォルトの名無しさん:04/12/25 15:51:31
http://www.res-system.com/weblog/item/242/
これどうよ。
これでいんじゃないの?

public ListType getData(int iIndex)
{
   while (this.data.size() <= iIndex)
   {
      this.data.add(new ListType());
   }
   return (ListType)this.data.get(iIndex);
}

700 :デフォルトの名無しさん:04/12/25 16:21:17
>>699
あぁ、それでいけるねぇ。
ありがとう。

701 :デフォルトの名無しさん:04/12/25 16:37:41
ちょっとクセのあるコーディングしないといけないけど、resetに処理記述することに比べれば、問題ないね。
すっきりした。

702 :デフォルトの名無しさん:04/12/25 18:48:05
レスが増えてるから何事かと思ったら、
int引数のgetterも知らんアレが大暴れですか・・・。

703 :デフォルトの名無しさん:04/12/25 18:57:02
代表的なのは、時代遅れのMVCを振りかざす>>644と、問題を理解せず全然解決になってない解答だして得意になってる>>645か。
どちらもJava厨の典型だな。

704 :デフォルトの名無しさん:04/12/25 21:29:43
MVCイラネ

705 :デフォルトの名無しさん:04/12/25 21:39:49
いや、ユーザーインターフェイス周りでは必要でしょ。

706 :デフォルトの名無しさん:04/12/25 22:03:07
MVCイラネ人はActionクラスに処理書きまくったりしてください
むしろStrutsなんか使わずに全部JSPだけで作っちゃうのもいいかもね

がんばってね@ITの山田さん

707 :デフォルトの名無しさん:04/12/25 22:04:45
つうか、Actionクラスって、Struts使ってる時点でMVCでしょ。

708 :デフォルトの名無しさん:04/12/25 22:05:43
>>707
本来StrutsはMVCでなくて C だけどな。

709 :デフォルトの名無しさん:04/12/25 22:09:31
MVCのMはActionForm
MVCのVはJSP
MVCのCはAction

そこから先はMVCじゃないモデル。問題ない。

710 :デフォルトの名無しさん:04/12/25 22:11:57
>>709
>MVCのMはActionForm
これは後付けだけどね。
もともとそう思って作られてはいなかった。
ちゃんとStrutsはコントローラを提供しますよって書いてある。
ま、設計者がどう作ろうと使う方が好きに使えばいいだけなのでどうでもいいけどね。
Strutsを使えば楽になるのはわかってるんだし。

711 :デフォルトの名無しさん:04/12/25 22:17:01
そのモデルって、上にリンクがあった、JSPがVで、EJBがMのモデル?
Strutsはコントロールしきれないことがわかったし、EJBは重すぎだし処理とデータを混ぜたところであまりいいことなかったし、崩壊したね。

712 :デフォルトの名無しさん:04/12/25 22:18:54
EJBはよほどデカいシステムじゃないと使えないし
デカいシステムだからって盲目的に使えばいいってもんでもないしな。
次に期待だろ。

713 :デフォルトの名無しさん:04/12/25 22:24:51
だから次はMVCモデルじゃないしね。

714 :デフォルトの名無しさん:04/12/25 22:26:02
次はJSPモデルです。
PHPの敷居の低さを徹底的に追求しました。

715 :デフォルトの名無しさん:04/12/25 22:27:48
Strutsスレはずっと何も実を結ばない与太話だけでスレが進行してるな
今見たら前スレもそうだった
もう次スレはいらねえな

716 :デフォルトの名無しさん:04/12/25 22:37:03
MVCとか概念的なもんは主観に基づく部分だから人によって解釈かわる。
それに縛られてメンテしにくいコード角なんて本末転倒。
MVCやるためにMVCやる。
OOPやるためにOOPやる。
そんならMVCもOOPもイラネ。

717 :デフォルトの名無しさん:04/12/25 22:38:31
マジレスすれば、ValueObject+DataAccessObjectとか、DataTransferObject+TransactionScriptとか、まあ言ってることは同じだけど、そんな感じのモデルが流行ってるわけだね。

718 :デフォルトの名無しさん:04/12/25 22:40:22
OOPも要らないよ。
そんなもんが必要な複雑なシステム、ほとんど作らないでしょ。

719 :デフォルトの名無しさん:04/12/25 22:40:28
ActionFormがMってネタか?
そもそもModelはStrutsには存在しないし依存しない

720 :デフォルトの名無しさん:04/12/25 23:06:11
>>717
そんなもん流行ることがおかしい。
ほとんど同じプロパティを持つクラスが増えたら
メンテナンス性が悪くなる。
仕様の変更でプロパティが増減したとき、いちいち各クラスに適応しないといかん。
どーせBeanUtil.copyProperties()使ってるだろうから、
よりプロパティの足し忘れに気づかずあぼーん。
死ね。

721 :デフォルトの名無しさん:04/12/25 23:16:54
>>719
なんか、自分が信じているものが消えてしまうのをみとめたくないみたいで、必死だね。
普通にActionFormはMVCのMで、MVCはStrutsの範囲にしか存在しないってことになってるみたいだけど。

722 :デフォルトの名無しさん:04/12/25 23:19:19
>>720
VOで増えてActionFormに増えてないということは、そこで入力する必要がない項目ということだから問題なし。
ActionFormに増えてVOに増えてないということは、そこで格納する必要がない項目ということだから問題なし。

723 :デフォルトの名無しさん:04/12/25 23:27:01
>>720
> そんなもん流行ることがおかしい

なんか、時代に取り残されているのを認めたくなくてわめいてるオヤジみたいだね。

724 :デフォルトの名無しさん:04/12/26 01:36:43
>>721
>普通にActionFormはMVCのMで、MVCはStrutsの範囲にしか存在しないってことになってるみたいだけど。
いったいどこでそうなってるのかソース希望。

725 :デフォルトの名無しさん:04/12/26 01:58:46
とりあえずは、ここか。
ttp://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?ModelViewController

「MVCはUIフレームワークの旗手となっている」
つまり、ユーザーインターフェイス層であるStrutsで完結する話。

726 :デフォルトの名無しさん:04/12/26 02:07:52
詳しくは、本をみてくれ。

727 :デフォルトの名無しさん:04/12/26 02:47:52
>>725
その絵のModelがどうしてActionFormになるの?
Strutsで言うなら、ViewとControllerの間にある矢印がActionFormじゃないかと思うんだけど。
あと、ViewからModelに対して伸びてる矢印は、Modelからデータを取得するという意味だと思うけど
JSPはActionFormから何の情報を取得するの?
あと、ViewとContorollerからModelには矢印が伸びてるけど、Modelからは矢印が伸びてないというのは
ViewとContorollerはModelを知ってるけど、ModelはViewやContorollerのことを知らない(依存しない)
という意味だと思うけど、ActionFormはそれには当てはまらないね。ViewのFORMパラメータに依存してるし

728 :デフォルトの名無しさん:04/12/26 03:37:40
ポカーン
こんな理解力の人に説明するのは無理だわ。

729 :デフォルトの名無しさん:04/12/26 04:07:30
> JSPはActionFormから何の情報を取得するの?

入力エラー時、JSPはすでに入力されている情報をどこから取得しますか?

> ViewとContorollerはModelを知ってるけど、ModelはViewやContorollerのことを知らない(依存しない)
という意味だと思うけど、ActionFormはそれには当てはまらないね。

Controller(Action)はstruts-configでどのActionFormの値を受け取るか設定する。
Controller(Action)はActionFormを知っている
ひとつのController(Action)でいろいろなActionFormを使いまわすことはできない。
Controller(Action)はActionFormに依存する

View(JSP)はhtml:formのaction属性に指定したActionが依存するActionFormから入力値の情報を得る
View(JSP)はActionFormを知っている
View(JSP)のひとつのhtm:formでひろいろなActionを使いまわすことはできない。
View(JSP)はActionに依存し、間接的にActionFormに依存する。

ActionFormには、JSPが特定できるフィールドも持たなければ、JSPを渡してくるメソッドも持たない。
ActionFormはView(JSP)を知らない。
ActionFormには、Actionが特定できるフィールドも持たなければ、Actionを渡してくるメソッドも持たない。
ActionFormはActionを知らない。
ひとつのActionFormは、いろいろなActionやいろいろなJSPで使いまわされる。
ActionFormはController(Action)やView(JSP)に依存しない。

図のまんまだと思うが。

> ViewのFORMパラメータに依存してるし

それは、ViewがActionFormに依存するってことだろ・・・

730 :デフォルトの名無しさん:04/12/26 09:20:15
>>729

> 入力エラー時、JSPはすでに入力されている情報をどこから取得しますか?

逆に言えば、入力エラー時の情報(ようするに入力したパラメータ情報)以外の情報は取得できないってことにならない?
入力エラー以外の情報(本来表示させたい情報)はどこから取得するの?
Actionで取得した値をActionFormにセットして遷移先のJSPで参照するのであればいいけど
Strutsはそういう使い方を前提とした設計になってない
遷移先のformで定義されてるaction-mappingパスに紐づけられてるActionFormを呼び出して
そこに情報をセットするのであれば、そのActionFormは処理結果の保持を行うModelだと言えないこともないけど
(そうするとStrutsのnestedタグから参照出来るから便利だし)


> ひとつのActionFormは、いろいろなActionやいろいろなJSPで使いまわされる。

その視点から見れば確かに依存してないね。
あるActionFormとValidatorパターンが存在して、そのフィールド定義を利用してJSPの画面を
構築すれば、ActionFormを使いまわして新しくViewを作れるって話か。

2つの質問の回答内容を合わせると、ようするに入力チェックという処理に対するモデルがActionFormだということかな?
「UIに関するMVCはStrutsで完結している」という話は、つまりそういうことが言いたかったの?
元々言われてたMVCはもっと広くて単純な意味で使われてたと思うので、そこにギャップがあるのかな?

731 :724:04/12/26 11:59:42
>>725
thx.
これはStrutsで構成されるWeb層をGUIとみなした場合の話だよね?

>>730
のいう通り、
'Model2' MVC (http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html)
というと、視点がちがってくるのでは。

この場合はVがJSP、CはStruts全般、でMは、Facadeがありーの、Business Delegateがありーの、Domain Logic層がありーので、
                               s
Domain LogicはDomain Modelパターンでいくの、Transaction Scriptパターンでいくの、
Domain ModelとEIS層とのマッピングはEJB/CMPなの、ORMがいいのという
従来どおりの話になると思うんだけど。

最近はModel2 MVCという言葉自体あまり流行らなくなっているということなの?

732 :デフォルトの名無しさん:04/12/26 21:26:52
>>730
> 元々言われてたMVCはもっと広くて単純な意味で使われてたと思うので、そこにギャップがあるのかな?

そう。いまはその広い意味のMVCで業務アプリケーション構築してもうまくいかないことが、経験からわかってる。
それと、StrutsのMVC機構がうまく働くのは入力処理だけで、単純な一覧表示なんかは特にStrutsに依存したMVCにする必要がないので、そのときにActionFormがMになる必要はない。

>>731
だって、この場合のMはEJBで、そのEJB自体のいまの扱われ方を見れば、MVC2が使い物になるモデルだったかどうかがわかる。

結局、ユーザーインターフェイスをVCとして残りをすべてMに押し付けるというのは、あまりにも乱暴で、Mが重すぎたという話。
EJBが重かったのは、ユーザーインターフェイス以外を全て押し付けられた結果だといえる。

最近流行っているというか、とりあえずシステムが組みやすいのは、プレゼンテーション層・業務ドメイン層・データベース層に分けるモデル。
で、そのプレゼンテーション層は、MVCでやるのがいまのところは一番うまくいっている。
データベース層は、ORマッピングでもいいし、ただDBUtil使うでもいいし、データベース層をもたなくてもいい。
業務ドメイン層は、オブジェクト指向にこだわらずひとつのメソッドで処理を流すトランザクションスクリプトと、オブジェクトモデルを構築するドメインモデルがある。
だけど、よっぽど複雑な業務じゃないかぎりは、ドメインモデルを組み立てる手間がバカにならないので、トランザクションスクリプトの方がいいみたい。
ttp://www.ric.co.jp/sol/contents/sol_0407/sol_architect.html

ファウラーが言ってることがすべてだとは思わないけど、今のところはこれでうまくやれそうだし、他に使えそうなモデルの話を聞かない。

733 :デフォルトの名無しさん:04/12/26 22:51:02
補足しておくと、層の数は、規模やら用途に応じて、サービス層が入ったり、いろいろ変わる。
規模が小さければ、プレゼンテーション層ですべてまかなっても問題ないし。
ただ、プレゼンテーション層のMVCで、MやVはCより向こう側のことに興味をもたないようにする。

734 :デフォルトの名無しさん:04/12/27 17:49:30
同じアクションに遷移する二つのpathがあるとして、

<action path="/hogeA" type="HogeAction" name="hogeForm" scope="session">
<forward name="hoge" path="/hogeA.jsp" />
</action>
<action path="/hogeB" type="HogeAction" name="hogeForm" scope="session">
<forward name="hoge" path="/hogeB.jsp" />
</action>

HogeActionの中で/hogeAから来たのか/hogeBから来たのかを
判別したいのですが、どうしたらよいでしょうか?

よろしくお願いいたします。

735 :デフォルトの名無しさん:04/12/27 18:29:44
>>734
ActionMapping の getPath()
APIドキュメントぐらい見ろよ。
それともexecute()の引数に入ってくるオブジェクトが何なのか考えたこともないとか?


736 :デフォルトの名無しさん:04/12/27 20:30:31
>>734的には、「まず、一人。」ってところなんだろうか・・・?

737 :デフォルトの名無しさん:04/12/28 05:33:48
乗り遅れたが>>699の処理ってlazyList使うべきだよな。
もはやどうでもいいけど。

738 :デフォルトの名無しさん:04/12/28 10:35:49
>>737
・・・解決にならなそうな希ガス

739 :デフォルトの名無しさん:04/12/30 00:53:04
まあ、引き合いにでてるのがGETTERじゃあ無理もない間違いだが……。

740 :デフォルトの名無しさん:05/01/06 22:00:22
SpringやSeasarのStruts連携機能を使ってるところってどれくらいあるんだろう?
どちらもActionクラスのインスタンスをリクエスト毎に作成してフィールドにDI出来るのを
売りにしてるようだけど、リクエストの度にActionのインスタンスを作るってところが
どうも引っかかる。パフォーマンス的には問題ないんだろうか?

741 :デフォルトの名無しさん:05/01/07 00:08:17
>>740
Actionのインスタンス生成と、Listのインスタンス生成と、どれほど差があるか考えてみ。
で、どんだけexecuteからの処理でインスタンス生成しているか。
そしたら、Actionのインスタンス生成って誤差くらいにしかならんよ。
ここが問題になるくらいパフォーマンスが厳しいんなら、別のこと考えたほうがいいだろうし。

ってか、気になるなら、singleton="true"にすればいいだけの話。

742 :デフォルトの名無しさん:05/01/07 01:53:43
>>741
漏れは740じゃないけど。

Actionのコンストラクタで、
そのActionで用いるビジネスロジックの初期化、
そのビジネスロジックのコンストラクタで、、、

をいくつかやってると、ちょっと気になるけどな。

まぁシングルトンで。

743 :デフォルトの名無しさん:05/01/07 02:46:03
>>741
今までServletの延長のように使ってきたActionの生成方法を変えるわけだから、本当に大丈夫なのかちょっと気になってしまったので。
実際に誤差ぐらいにしかならなかった? それなら何の問題も無いし、DIコンテナとStrutsが連携する最大の利点にもなるんだけど
ActionクラスをBean的に使えるようになるから、フィールド使い放題になるしね
そもそも、StrutsのActionクラスの設計方針がおかしかったってことにもなってしまうが

>ってか、気になるなら、singleton="true"にすればいいだけの話。
いや、それじゃActionのフィールドが使えなくなるから、DIコンテナの恩恵が受けられなくなるので連携する意味が無いのでは?

744 :デフォルトの名無しさん:05/01/07 07:29:19
Servletはなぜリクエスト毎にインスタンスを生成しないモデルなのか?
という理由を考えるとびみょー。

745 :デフォルトの名無しさん:05/01/07 09:58:39
それで、ここまでstrutsを使ってきたおまいら的に、
総合的に見てStrutsのメリットとデメリットをまとめていただけませんか?

746 :デフォルトの名無しさん:05/01/07 10:23:20
メリット
・普及している
・情報量が多い
・Strutsを使えるエンジニアが多い

デメリット
・カスタムタグが糞
・ActionでServlet APIを使うからテストしづらい
・ファイル数がやたら多くなる(ある程度仕方ないと割り切りが必要ではある)
・フレームワークを隠蔽できてないので中で何をやっているかを理解しないと
 使いこなせない

747 :デフォルトの名無しさん:05/01/07 10:36:13
>>743
> いや、それじゃActionのフィールドが使えなくなるから、DIコンテナの恩恵が受けられなくなるので連携する意味が無いのでは?

どうせDIするのはシングルトンなクラスのオブジェクトだから問題ない罠。

748 :デフォルトの名無しさん:05/01/07 10:37:45
>>745
デメリット
・みんながフレームワークといってるからフレームワークだと思ってしまって、アプリケーション全体をStrutsに依存した設計にしてしまうヤツがいる。

749 :デフォルトの名無しさん:05/01/07 10:45:08
>748
これについてもうちょっと詳しく説明してもらえないでしょうか?
どこをどうしたらアプリケーション全体がStruts依存になるんですか?

750 :デフォルトの名無しさん:05/01/07 10:48:07
フレームワークはアプリケーションのアーキテクチャを決定づけるから
アプリケーションがフレームワークに依存した設計になるのは当然だと思ってたよ。

751 :デフォルトの名無しさん:05/01/07 11:10:03
Strutsの場合、アプリケーション全体のアーキテクチャを決定づけるようなフレームワークじゃないからね。
プレゼンテーション層のフレームワークでしかない。
っていうか、ライブラリっていうには大きいからフレームワークって呼んでるだけなのにね。

752 :デフォルトの名無しさん:05/01/07 11:31:15
> っていうか、ライブラリっていうには大きいからフレームワークって呼んでるだけなのにね。

あなたがここで言う「フレームワーク」の定義を教えてください。

753 :デフォルトの名無しさん:05/01/07 11:50:49
>>752
ttp://www.atmarkit.co.jp/fdotnet/t-interview/unisys_af/unisys_af01.html
Strutsのことを呼ぶときのフレームワークは、ここでの「狭義のフレームワーク」
アプリケーション全体のアーキテクチャを決定付けるようなフレームワークは、ここでの「広義のフレームワーク」

まあ、ここでの定義がすべてだとは思わないが、Strutsは「ユーザーコードを呼び出すクラスライブラリ」という意味で「フレームワーク」と呼ばれているだけだと思う。

754 :デフォルトの名無しさん:05/01/07 12:07:08
>>746
ActionのテストはStrutsTestCase使えば簡単だよ。Mock版使えばコンテナすら不要。
ttp://strutstestcase.sourceforge.net/

755 :デフォルトの名無しさん:05/01/07 12:23:25
>>753
.NET レベル以上でサポートしてないとフレームワークとは呼びたくないわけだね。
ただ、「ライブラリ」と「フレームワーク」は違うものだと思うから
「○○なライブラリをフレームワークと呼ぶ」という表現には抵抗がある。

>>754
俺的にはStrutsTestCaseすらめんどい。
JUnitだけで済ませたい・・・って横着かな?


756 :デフォルトの名無しさん:05/01/07 13:03:55
>>747
S2Strutsのドキュメントにも書いてあるけど
ActionのフィールドにDI出来るのはprototypeを前提としている
singletonなActionでセッターインジェクションするのは
Servletでフィールド使うようなものじゃない?


757 :デフォルトの名無しさん:05/01/07 13:09:47
>>755
> 「○○なライブラリをフレームワークと呼ぶ」という表現には抵抗がある。

でも、Strutsの説明でのフレームワークはだいたい「Don't call us, we'll call you」な仕組みとかしか書いてない。

758 :デフォルトの名無しさん:05/01/07 13:12:09
>>756
DIでActionに対して組み立てるクラスは、結局Servletでフィールドに使っても問題ないようなものになると思う。

759 :デフォルトの名無しさん:05/01/07 14:17:39
>>757
ライブラリはまさにその逆。
こっちが作るプログラムから呼び出すものでしょ?

760 :デフォルトの名無しさん:05/01/07 14:54:22
>>759
あぁ、つまり
「ユーザーコードを呼び出すクラス集合のことをフレームワークと呼ぶ」
みたいな感じならOKってことかな?

761 :デフォルトの名無しさん:05/01/07 15:18:40
>>760
まあ、だいたい。

ライブラリは機能単位で切り出して再利用可能にしたもの。
どこでどう使おうがこっちの勝手。

フレームワークはどこにどうやって何を実装するのかも決まっていて
その通りに実装してあげると呼び出してくれるもの。

ってなかんじかなぁ・・・

762 :デフォルトの名無しさん:05/01/07 15:39:40
>>761
その意味とは別に、アプリケーション全体のアーキテクチャを決定づけるようなツールや部品群のことを呼ぶフレームワークがあって、Strutsが後者のフレームワークだと誤解されることがあるのが問題ってのはOK?

763 :デフォルトの名無しさん:05/01/07 15:47:09
>>762
OK。

.NET や、さらには SAP R/3 などの業務アプリフレームワークみたいな
とらえ方をされると問題だね。

764 :デフォルトの名無しさん:05/01/08 01:20:38
>>761
> その通りに実装してあげると呼び出してくれるもの。

それはただのテンプレートパターンじゃねーの?
テンプレートパターンだけのフレームワークなんか見たこと無い。
テンプレート + ライブラリ = フレームワーク

ライブラリは整理されていれば多くてもいいが、
テンプレートメソッドが多いのは糞フレームワーク。
テンプレートパターンはフレームワーク作成者は分かりやすいと思ってるか
知らんが、使うほうとしては勝手に呼ばれるのは直感的ではない。
例えば HttpServlet はテンプレートメソッドが大杉の悪い例。

「あなたは私を呼ぶ必要はない。私が必要な時にあなたを呼ぶから。」
あなた=ユーザコード ではなく、あなた=フレームワーク でもいいが、
要はバランスか。

765 :デフォルトの名無しさん:05/01/08 01:34:28
>>764
> それはただのテンプレートパターンじゃねーの?

違うと思うが・・・

766 :デフォルトの名無しさん:05/01/08 08:33:30
>>758
スレッドセーフなクラスしかDIできないのなら、既存のStrutsシステムに
DIコンテナのStruts連携機能を導入するメリットはほとんど無いということになるね。
現実的には、SpringのFactoryBean的な機能を委譲させたオリジナルクラスを
FactoryMethodパターンで生成し、それをexecuteメソッドの中で利用するという形になるのか。
そうすればAction生成は既存のまま、DIコンテナにあまり依存せずにビジネスロジックとの疎結合を実現することは可能っぽい

>>764
JavaWorldに載ってたけど、StrutsのActionクラス設計はCommandパターン、
RequestProcessorによる呼び出し方法はTemplate Methodパターンを使ってる
そもそもStrutsはServletを基本にコントローラ機能を実装した仕組みだから、呼び出し方法自体はこれでもいいと思うけど
実装するクラスが継承でガチガチに固められているので、結局似たようなクラスを大量に作る羽目になるのが嫌なところだと思う

767 :766:05/01/08 09:36:11
> 現実的には、SpringのFactoryBean的な機能を委譲させたオリジナルクラスを
間違えた、BeanFactory的な機能だった

768 :デフォルトの名無しさん:05/01/12 17:33:09
1.2って1.1と下位互換ある?

769 :デフォルトの名無しさん:05/01/12 17:51:39
>>768
ある。ActionErrorsなど非推奨になったクラスのコンパイル時に警告はでるが。
ただし、1.1で既に非推奨だったものは1.2で切られたからだめ。

770 :デフォルトの名無しさん:05/01/12 17:55:42
>>769
ありがとう!
これで心おきなく1.2に移る準備を始められるよ。

771 :デフォルトの名無しさん:05/01/12 22:39:36
1.1の設定ファイルそのまま使ったらvalidationせず素通りした覚えがある
フォーマットに違いがあるかも

772 :デフォルトの名無しさん:05/01/13 22:23:17
>>771
推測だけで書くけど、
設定ファイルにミスがあって1.1ではスルーされてたけど
1.2ではそれが顕在化しただけじゃない?

漏れはTomcat4と5で、そういうの体験した。

773 :デフォルトの名無しさん:05/01/16 01:09:22
すいません。
最近strutsを始めたのですが、strutsのタグってその多くが
jstlのタグと機能が重複してるように思います。
それなら新しく覚えるよりも、慣れてるjstlのタグの方を使いたいです。
でも、strutsを使う以上はstrutsのタグを使う方が一般的なので
しょうか? 教えてください。


774 :デフォルトの名無しさん:05/01/16 02:32:27
strtusタグはJSTLが存在しないときに設計された。
使いやすいほうを使え。
以上。

775 :デフォルトの名無しさん:05/01/16 14:21:49
JSTL1.0が出た頃、このスレとかで質問したんだけど、
StrutsスレなのにStrutsタグ使わないような質問するやつだということでえらい罵倒されまくったな。
懐かしい。時代も変わったな。

Strutsタグ使わないやつは邪道扱いされたもんだが、俺を罵倒した他人のケツ追いか
けるしか脳のないアホども、元気か?


776 :デフォルトの名無しさん:05/01/16 14:31:41
strutsタグは、jstlと比べてデザインが悪い。使いずらい。覚えずらい。
同じ機能タグでも設計者によって、あそこまでの違いが出るいい見本だ。

777 :デフォルトの名無しさん:05/01/16 18:43:05
1.1から1.2にあげてこれが大変だった、ってのある?

778 :デフォルトの名無しさん:05/01/16 19:26:21
>>777
Validator

779 :デフォルトの名無しさん:05/01/16 20:30:58
>>775
Strutsタグ使えハゲ。

780 :デフォルトの名無しさん:05/01/16 20:59:20
>>773
JSTLを既に知ってるのであれば、htmlタグ以外の機能が重複するStrutsタグを覚える必要は無い
ちなみにStruts2.0でJSTLとJSFに正式対応する予定

781 :デフォルトの名無しさん:05/01/16 21:08:39
>>777
別にない。
ActionErrorとかそこらへん書き換えるのが面倒だったぐらい。
1.1の時に非推奨使わないようにしてたし。


782 :デフォルトの名無しさん:05/01/16 21:09:42
>>779
標準使え。ボケ。

783 :デフォルトの名無しさん:05/01/16 21:16:46
>>780
でも当分先だよねえ。
今Struts1.2.xの開発中でしょ。その後1.3, 1.4 とかも予定されてるし。

JSFに対応ってどうするんだろ。
大きく変わりそうだなあ。
Struts-facesも止まっているような感じだし、のんびりしてると
デファクトスタンダードが変わっちゃうんじゃないのかな。



784 :デフォルトの名無しさん:05/01/16 21:48:07
JSFに対応ってか、統合じゃね?

785 :デフォルトの名無しさん:05/01/16 22:04:52
>>784
それはない。
StrutsがJCPのJSRプロポーザルになって標準化するとでも?

StrutsカスタムタグもJSTLもJSFのUIコンポーネントも
どれも標準で使えるようになるってのが現実路線でしょ。


786 :デフォルトの名無しさん:05/01/16 22:54:59
>>783
デファクトは変わるだろう。そもそもStrutsの作者がJSFのスペック・リードの一人なんだし。
2.0の提供が遅れるようであれば、Webアプリケーション開発に無条件にStrutsを採用するような時代はそんなに長く続かないかもね

787 :デフォルトの名無しさん:05/01/16 23:45:36
>>786
XDocletのような、オープンソースの開発支援ツールが出てこないと
JSFの普及は難しいんじゃないかな。
今のところ、事実上JSFは商用IDEでの開発が前提とも言える状況。
これじゃ、JSF APIの使い方よりも、IDEの操作方法を覚えろって感じ。

788 :デフォルトの名無しさん:05/01/17 00:37:08
>>782
じゃ Struts 使うなハゲ。
J2EE 標準だけで組め。カス。

789 :デフォルトの名無しさん:05/01/17 01:36:27
>>788
隙の多いツッコミだな。

790 :デフォルトの名無しさん:05/01/17 01:40:03
>>787
> IDEでの開発が前提

そのためのJSFでしょ。

791 :デフォルトの名無しさん:05/01/17 05:11:07
今度途中参加するプロジェクト、Struts使ってるんだけど、html系(formとか)のタグとか使ってないらしい。
Struts使う意味あるんかな?

792 :デフォルトの名無しさん:05/01/17 05:24:14
Strutsの一番の役割は、リクエストパラメータをActionFormにパックすることだから、他は好みで。

793 :デフォルトの名無しさん:05/01/17 08:49:18
Form以外はJSTLのでいいんじゃないかな

794 :デフォルトの名無しさん:05/01/17 09:26:20
>>790
だから、高機能なEclipseプラグインとか出てこないとなかなか普及しにくそう。
各社操作方法も機能もまちまちな商用IDE前提ではStrutsのシェアをひっくり返して
デファクトスタンダードになるのは難しいのではないかと

795 :デフォルトの名無しさん:05/01/17 10:07:22
>>791
option以外、大して使う意味ないからね。htmlタグ。
<html:form>で囲った部分が自動的にFormBeanになったりするのなら
まだ意味があったのだが。
後で機能付けるつもりで途中でやめてしまったのかも。
まあ、付けようもないし。


796 :デフォルトの名無しさん:05/01/17 10:36:36
1.2って式言語サポートしてます?

797 :デフォルトの名無しさん:05/01/17 10:48:17
>>796
してない

798 :デフォルトの名無しさん:05/01/17 11:26:18
contribのstruts-el使えばいいのかな

799 :デフォルトの名無しさん:05/01/17 11:55:32
Tomcat5使うのがいい。

800 :デフォルトの名無しさん:05/01/17 21:43:02
strutsタグ使えば自前でxss対策しなくてよい。


801 :デフォルトの名無しさん:05/01/17 23:46:59
>>778>>781
validatorとかActionErrorとかって、めっちゃ数多いし大変そう
バージョン変えるタイミングってどうやって決めてる?
Strutsに限らずタイミング難しくて古いモンばっか使ってる

802 :デフォルトの名無しさん:05/01/17 23:59:12
>>801
作ったもののバージョンは変えない。
いまから作るものは最新バージョン。
作ってるものは、進捗具合で考える。

803 :デフォルトの名無しさん:05/01/18 00:31:08
>>802
俺もそれが妥当だと思う。
既に1.1で動いているもののバージョンをわざわざ上げるメリットは
あまり無いと思う。

804 :デフォルトの名無しさん:05/01/18 00:59:18
まったくないと思う

805 :デフォルトの名無しさん:05/01/19 23:30:05
<foo:select property="bar" />
みたいなカスタムタグ単発で、

<html:select property="bar">
<html:options ... >...
</html:select>

のような Struts 用のフォームタグを吐き出す(かつ JSP に更に解釈させる)ことってできるでしょうか?
ストレートにやったら <select> タグじゃなくて <html:select property="bar">... のまま出てしまい、
どうすれば JSP 側に Struts 用のタグとして解釈させられるのかわからず困ってます。

806 :デフォルトの名無しさん:05/01/19 23:35:20
>>805
taglibは一回しか変換を行なわないんじゃないの?

カスタムタグもStrutsのタグもtaglibではないかと。


807 :デフォルトの名無しさん:05/01/19 23:41:41
>>802-804
バージョンアップを続けていくシステムの場合は?
新規に作る分はそれでいいと思うけど

808 :デフォルトの名無しさん:05/01/20 00:09:45
>>805
806の通りだと思う。

strutsのhtmlタグって、ほとんど何もしてないんだから(値の出し入れ程度でしょう)
自前でhtmlを出力すれば良いんじゃないかな。


あと、思いつきで書くけど、
strutsのtaglibクラスを直接叩いて、結果を出させるとか、出来ないかな?

809 :デフォルトの名無しさん:05/01/20 01:04:32
>>807
マイナーバージョンアップでは変えない。
メジャーバージョンアップでは可能な限り最新。
ライブラリのバージョンアップでの機能追加は、今まで作った動いているものを変更するリスクをわざわざ負うほどのものじゃないことがほとんど。

810 :デフォルトの名無しさん:05/01/20 01:41:02
>>806
>>808
ありがとうございます。
やっぱり変換は初回限定なんですね... ( ´・ω・`)
ひとまず自前出力でやってみます。

かさばるタグの部品をマクロっぽくまとめられたらというつもりだったんですが、
あんまりそんなこと考える人いないのかな...

811 :デフォルトの名無しさん:05/01/20 02:31:36
>>805
・・・そのタグ書いたタグファイル作ればいいだけかと。

812 :805:05/01/20 03:17:51
>>811
う、それって JSP 2.0 のやつですよね。
Weblogic8.1 なんですがタグファイル試したら No URI for taglib みたいなエラーが出てしまいました。
ttp://forums.bea.com/bea/message.jspa?messageID=202427729
ここ見たら Weblogic8.1 では JSP 2.0 のタグファイル(tagdir指定)は使えないっぽい...orz

813 :デフォルトの名無しさん:05/01/20 03:26:51
>>810
ん、であればJSPをincludeしたら良いのでは?

814 :デフォルトの名無しさん:05/01/20 23:28:14
>>810
そんなときこそ、Velocityと組み合わせるのだw

815 :デフォルトの名無しさん:05/01/21 00:43:52
正直なところ、使いやすいものではないよな
どうせみんな、Actionにはほとんど何も記述してないんだろ?
BeanUtilsでプロパティコピーして投げて、返球を格納するだけだろ?
ActionFormは痒いところに手が届かないし
struts-configがでかくなったらform-beanは見つからないし
sessionのことをすっかり忘れて開発してるし
HttpRequestは手放せないからいらん!

setUp()でValidateと値を格納
perform()がコントローラ
tearDown()で格納
って、ああ、分岐したらどうしよう
分岐の数だけメソッドを準備してServletに呼び出させるか
ServletでもちろんHttpRequestを隠蔽して単体テストを簡単にして
うわらばがふ…わしには設計できねえ
でも、ActionとActionFormは分ける必要ねーーー

816 :デフォルトの名無しさん:05/01/21 01:01:46
>>815
つまり、XDocletすら使わず文句いってると。

817 :デフォルトの名無しさん:05/01/21 01:21:01
>>815
なんつぅか、世に出てる本が悪いと思う。
俺もそう思ってたが、使いこなせるようになると、まぁ楽に開発できる。
あと、アクションマッピングのnameとinputはネーミングミスとはいえ
いくらなんでもひどすぎる。あれがより難解なイメージを抱かせる。


818 :デフォルトの名無しさん:05/01/21 01:24:58
>>817
楽には開発できるよ
そのとおりさ
でも…散々食べ散らかして汚くなったソースの改修がつらいんです
自分ひとりで作るならいいんだよ…

819 :デフォルトの名無しさん:05/01/21 07:36:51
Strutsは無駄に複雑なんだよね。
あの使いづらいタグもしかり。

JSF見るとよけいにそう思える

820 :デフォルトの名無しさん:05/01/22 00:55:16
>>817
nameとinputはひどいな・・・。

struts-config.xmlのガイドってないんかなあ。

821 :デフォルトの名無しさん:05/01/22 01:11:16
>>820
DTD見るのが早い。ちゃんとコメント書いてあるし。

822 :810:05/01/22 01:21:43
>>813
include ならいけますね。属性は残念ながら渡せないけど。
でも request の attribute 経由で値とか渡せるからこれでいいかもです。

>>814
やはり taglib より先に展開されるテンプレートでないといけないわけですね。

823 :デフォルトの名無しさん:05/01/22 04:25:19
Strutsで一番きらいなもの挙げれ。


ActionForm

824 :デフォルトの名無しさん:05/01/22 07:50:25
struts-config.xml

825 :デフォルトの名無しさん:05/01/22 11:14:31
むぅ、VelocityからBean参照するとき、Bean名にピリオド入ってるとだめだね。
せっかくBean名全部パッケージ名つけるようにしたのに・・・

826 :デフォルトの名無しさん:05/01/22 11:53:29
>>821
なるほど・・・。

>>825
Bean名の両側に{と}をつけてみたら?

827 :デフォルトの名無しさん:05/01/22 11:54:54
む・・・わかりにくいか。
${bean.name}みたく、"{"と"}"をつけるという意味です。

828 :デフォルトの名無しさん:05/01/22 14:27:14
もうハイフンにおきかえちゃったけど、確かだめぽだった。
http://www.jajakarta.org/velocity/velocity-1.2/docs-ja/user-guide.html#Variables
Velocityのマニュアルにもピリオドは書いてないから使えないみたい。

829 :デフォルトの名無しさん:05/01/23 01:29:31
>>828
Σ(゚д゚lll)ガーン
本当だ。

ちなみに、翻訳の最新版はこっちね
ttp://www.jajakarta.org/velocity/velocity-1.3.1/docs-ja/user-guide.html#Variables


830 :デフォルトの名無しさん:05/01/23 12:41:52
actionForm.setData(data, org.apache.struts.SESSION)
キボン

831 :791:05/01/23 16:39:33
この間確認してみたら、ActionFormも使ってないらしい。もちろんValidatorも。
Actionディスパッチにしか使ってない。ホント、なんでStruts使ってるんだろう?

832 :デフォルトの名無しさん:05/01/23 19:53:23
>>831
Actionのサブクラスのexecuteメソッド内でHTMLを吐いていない限りは
Strutsを使う価値はあると思うが。


833 :デフォルトの名無しさん:05/01/23 22:24:40
>>832
RequestDispatcherの記述が省略できる程度にしかならなそうなんだけど・・・
コスト対価値の比率が著しく悪そう。

834 :デフォルトの名無しさん:05/01/23 22:27:23
うん、最近無理にActionForm使うんじゃなくて、
業界標準のコントローラフレームワークだと割り切ったほうが
いいような気がしてきた。

835 :デフォルトの名無しさん:05/01/25 12:27:29
Strutsの質問はここでよかったでしょうか?
FAQじゃないかと思うんですが、ぐぐって見つけられなかったので。

ActionFormのvalidationやAction内部でエラーが発生したとき、
いったんエラーメッセージ専用の画面を表示して、その「戻る」ボタンを
クリックすることで、そのエラーの原因になった入力画面に戻る、という
画面遷移にしたいんですが、こういう場合、標準的な方法ってあるのでしょうか。

今考えているのは、RequestProcessorのサブクラスを作り、その中で、
mapping.getInput()でinputページのパスを取得してセッションにでも投げ込んで、
グローバルフォワードで飛ばしたエラー画面のアクションでそのページに戻す、
という方法なんですが、こんな画面遷移はありがちなだけに、絶対標準的な
方法があるだろう、と思うわけです。

836 :デフォルトの名無しさん:05/01/25 12:32:58
input にその専用エラーページ書けばいいんでは?

837 :835:05/01/25 22:32:55
>>836
それで「専用エラーページ」に戻ることはできるけど、その専用エラーページ上にある
「戻る」ボタンで、元のページ(そのエラーの原因になった入力画面)に
戻ることはできないですよね?

> mapping.getInput()でinputページのパスを取得してセッションにでも投げ込んで、

よく考えると、この方法も、アクションで検出したエラーでは使えても、
ActionFormで検出したエラーには使えそうにないですね。

838 :デフォルトの名無しさん:05/01/26 06:06:40
validatorプラグインで、
class ChildForm extends ValidatorForm {
String name;
/* Getter / Setter省略 */
}
class ParentForm extends ValidatorForm {
ChildForm[] childForms;
/* Getter / Setter省略 */
}
みたいなパターンのChildFormの検証ってできますか?
parentFormのvalidateをオーバーライドして、super.validate後に各childFormの
validateメソッドを起動するようにしてみたんですが、NullPointerExceptionが
起こってしまいました。
ソースを見るとgetServletで例外はいてたので、childFormのvalidate呼び出し前に
childForm.setServlet( this.getServlet() )
とやってみたら、例外は吐かなくなりましたがChildFormの検証にもvalidation.xmlでの
ParentFormと同じルールを使ってるらしく、うまく動作しませんでした。

なにかヒントだけでもいいので、ご教示いただけないでしょうか?(Struts 1.1です)

839 :デフォルトの名無しさん:05/01/26 11:10:03
>>838
Struts1.2.xならできるけどね。

840 :デフォルトの名無しさん:05/01/27 02:44:58
>>838
たしかstruts-config.xml でactionとformが対に定義されるから
デフォルトだと無理だったような気が。ソース読めば
自力で任意のactionで任意のフォームをvlaidateするコードの
書き方がわかると思います。結構簡単なはず。
で、>>839
そのやり方をもう少し詳しく。

841 :デフォルトの名無しさん:05/01/30 00:23:14
XP上でStruts使った開発・動作確認やっててブルー画面頻発。
原因不明だったが、Linux上で動作させたら一発で原因判明・
即解決。貴重な経験でした♪

842 :デフォルトの名無しさん:05/01/30 00:31:33
どうやったらそんな不可解な現象が発生するんだ?

843 :デフォルトの名無しさん:05/01/30 01:10:17
>>841 で、判明した原因はなんだったの?

844 :デフォルトの名無しさん:05/01/30 14:52:28
まー、>841 の環境が腐ってるだけだろ。

845 :デフォルトの名無しさん:05/01/30 15:11:23
Strutsが原因でブルー画面なんてあり得ない。
てかXPでブルー画面見たことない。

846 :デフォルトの名無しさん:05/01/30 20:33:04
>>845
俺ある。
もちろんeclipseとは何の関係もないけど。

847 :デフォルトの名無しさん:05/01/30 20:34:39
>>846
Strutsだ。はずかしい。

848 :デフォルトの名無しさん:05/01/31 00:48:15
同じフォームBeanで、アクションによってバリデーションの中身を変える、
とかってできないの?
validateメソッドの中でActionMappingとかリクエストの中身みて
コセコセ分岐させるしかないんでしょーか。

バリデーションに使うメソッド名をstruts-configの中で指定できればいいのに....


849 :デフォルトの名無しさん:05/01/31 01:00:35
>>848
ValidatorFormじゃなくてValidatoActionFormを使う。

850 :デフォルトの名無しさん:05/01/31 01:53:07
バグってたの直ったのかな> ValidatorActionForm


851 :デフォルトの名無しさん:05/01/31 02:00:55
class ParamForm extends ActionForm {
フォームのプロパティ定義
}
class FormForAction1 extends ParamForm {
action1用のvalidateのみ記述
}
class FormForAction2 extends ParamForm {
action2用のvalidateのみ記述
}

action-mappingではaction1にFormForAction1、action2にFormForAction2を指定
こんなので大丈夫なのかな。


852 :デフォルトの名無しさん:05/01/31 02:56:59
うろ覚えなんだけど、validation.xmlだけで完結しないんだっけ? >>851


853 :デフォルトの名無しさん:05/01/31 03:58:05
>>850
1.2.4では直ってる

854 :デフォルトの名無しさん:05/01/31 08:18:55
formは共通で書いてよくて、validator.xmlのみで制御できたと思いまつ

855 :デフォルトの名無しさん:05/01/31 08:35:04
>>854
validator.xmlというファイル名はあまり使わんな。

validation.xmlで<field page="n"を使ったらどう?

856 :デフォルトの名無しさん:05/01/31 20:55:03
>>855
そのpageというものがなぞの存在だと思っていたが、
素敵な代物でつか?

857 :デフォルトの名無しさん:05/01/31 21:30:24
>>856
実は、ValidatorFormクラスには、int page;というプロパティとsetter/getterが存在する。
で、ページ上にhiddenでも何でもいいからpageというリクエストパラメータ(整数)を送ってあげるのね。
そんで、<field page="n"とパラメータで送られた値が一致した場合にのみ、この設定が
適用されるってわけ。
長大なアンケートページとかで、複数ページにまたがって入力項目があり、それを
ひとつのsessionスコープのActionFormで使うような場合で、各ページでValidationの
ルールが違う場合などが想定されているらしい。

858 :856:05/02/02 01:32:58
>>857
先生!スゲー勉強になりました!
thx!


859 :デフォルトの名無しさん:05/02/02 17:00:40
このスレで訊いて良いのかちょっと迷ったが、初心者スレの内容でもないからとりあえず・・
ユーザー認証・アクセス権限関連のフレームワークみたいなものってあります?
DB/XMLなどから権限の設定などを読み取り、
ログイン時やページ毎の権限チェックなどをしてくれる感じ。
自分で作ったが今ひとつ満足できず、
何か参考になるものがあると良いなと思って。

860 :デフォルトの名無しさん:05/02/02 20:22:47
validator.xml って使えば使うほど面倒なんだけど
validate メソッドに書くのと比べてそんなにいいか?

861 :デフォルトの名無しさん:05/02/02 20:43:28
>>857
その説明を信じると、page使うときって、悪意を持ったユーザがパラメータを送信しないようにしたら
validatioすり抜けてしまいますよね。
サーバーサイトで強制的にNpageのvalidationを行うってことは
可能でしょうか。
1page -> 2page -> 3page -> 最終ページで全validationを走らせる、とか。

862 :デフォルトの名無しさん:05/02/02 20:43:34
サーブレットコンテナが持ってる認証機構を使う


863 :デフォルトの名無しさん:05/02/02 20:50:51
>>860
XDoclet使うから使えば使うほどってほどじゃない。

864 :デフォルトの名無しさん:05/02/02 20:51:42
>>860
validator.xmlってまったく使わないな。
validation.xmlならよく使うけどw

・・ってか、XDoclet使え。手書きなんかするものじゃない。

865 :デフォルトの名無しさん:05/02/02 23:54:40
>>864
XDocletは手書きじゃないのか。

866 :デフォルトの名無しさん:05/02/03 00:35:07
Tomcat起動直後、httpsでアクション開いて、
次にhttpのアクションにフォワードすると、
別セッションになってしまいます。
逆にhttp -> httpsの順にフォワードしたら
セッションは引き継がれました。
https->httpでセッションのアトリビュートに乗せた情報を
なんとか引き継ぎたいんですがよい方法ないですかね?

867 :デフォルトの名無しさん:05/02/03 01:12:45
>>866
Struts SSL Extension
http://sslext.sourceforge.net/

868 :デフォルトの名無しさん:05/02/03 01:24:08
<html:link>の使い方に関して教えてくだされ。

例えば、複数OrderとItemがあって、1つのOrderの中にItemが複数入ってる
Listがあるとして・・・

出来上がりのイメージとして、以下のようなリンクを作成したいのですよ。
<a href="/itemDetail.jsp?orderNo=0001&itemNo=1">
<a href="/itemDetail.jsp?orderNo=0001&itemNo=2">
<a href="/itemDetail.jsp?orderNo=0002&itemNo=1">
・・・
で、JSPで普通に書くと、↓のような感じかと思うのですが
loopの始まり
<a href="/itemDetail.jsp?orderNo=<%=order[i].getNo()%>&itemNo=<%=order[i].getItem(j).getNo()%>">
loopの終わり

と、いうことを<html:link>を使ってやりたいんですが、?以降の指定の方法がわからないんです。
どうやるんでしょうか?
あ、strutsは1.2.4です。



869 :デフォルトの名無しさん:05/02/03 04:21:00
struts-configは、いまの主流は自動生成ですか?
やるとしたらどのツールで?

870 :デフォルトの名無しさん:05/02/03 07:43:12
XDocletつかえ。

871 :866:05/02/03 08:49:24
>>867
なるほど、存在は知ってたけど、ssl対応ってことは
たぶんセッションの同期もうまくいくんだろうね。
でもApacheとjk2で連携させてるとうまくいかないとかいうカキコもあった・・・
http<->https間のフォワードは自力で解決してしまったので、
単にセッションの同期だけとれればよいのだけど。

872 :デフォルトの名無しさん:05/02/03 11:03:11
>>871
セッションの同期ができないのは、ブラウザ依存になる部分もあるから
切り分けが必要。ブラウザ側で別々にCookie管理をしちゃう。
Struts SSL Extension は、そんなブラウザのために
強制的にURL RewritingをしてセッションIDをURLパラメータに付加するオプションあり。

873 :デフォルトの名無しさん:05/02/03 14:16:26
XDocletでDynaActionFormを扱おうとすると、
ダミーのBeanを作る必要があるよね。
これって逆にDynaActionFormの利点を損なうことになってない?

それとも俺が使い方間違ってるのかな?

874 :デフォルトの名無しさん:05/02/03 14:31:59
Xdoclet使うならDynaActionFormは捨ての方向で。

875 :デフォルトの名無しさん:05/02/03 14:48:53
DynaActionFormってメリットがほとんど感じられない。
setter/getter作らなくていいってだけ。IDE使うとsetter・getterは
自動生成できるからもはやデメリットしか無い。


876 :デフォルトの名無しさん:05/02/03 15:01:03
>>874 & >>875 ご両人のご意見から、
XDocletでDynaなにがしFormを使うのはやめときます。thx!

877 :デフォルトの名無しさん:05/02/03 16:06:12
xdoclet使うとJBuilderのアクションデザイナが使えないから、と却下された。
どこが使いやすいんじゃあんなの。 > アクションデザイナ
xdocletのほうが断然いいっての

878 :デフォルトの名無しさん:05/02/03 17:18:42
ビジュアル系のツールはマウス握らないといけないから面倒だよね。


879 :デフォルトの名無しさん:05/02/03 19:57:36
XDocletで同じActionFormを複数インスタンスで使いまわす書き方ってできますか?

880 :デフォルトの名無しさん:05/02/03 20:18:03
>>879
いっこだけXDocletに記述して、あとはaction-servlets.xmlにコピペして編集

881 :デフォルトの名無しさん:05/02/03 20:46:36
やっぱりそうか。
ActionForm用にstruts-config.xmlを分割すれば修正忘れも防げるけど、いまいち。

882 :デフォルトの名無しさん:05/02/04 00:41:57
つーかさぁ、遷移情報その他もろもろを一つの場所で管理できて、ソースいじんなくても
云々っていう理由でStruts-configってあるんでしょ?
Xdoclet使ってたら言ってること間逆だよね。EJB3もそうだけどさ
時代が変わったのかと思いきやJSFにもfaces-configって在るぐらいだからそーでもないっぽいし、
好みと開発規模で使い分けろって事か?

883 :デフォルトの名無しさん:05/02/04 00:58:45
>ソースいじんなくても 云々っていう理由でStruts-configってあるんでしょ
それこそ神話。
Xdoclet使う時点で、strutsの理想に反するのはわかってるが、
今作りやすいことの方が何よりも大事。

884 :デフォルトの名無しさん:05/02/04 01:01:13
今はDTDやスキーマでXML文書入力補助してくれるエディターもあるし
XML書くのは昔ほど苦にはならなくなってきた。GUIな設定ツールなんかよりよっぽど早く書けるし
そうなると逆にXDocletとかEJB3のアノテーションとか蛇足のように思えてくるのだが

885 :882:05/02/04 02:02:55
まぁあれか、早い話連動すればいい訳だな、
一方を修正すれば他方も自動的に修正されるような
そーすれば可読性や保守性と開発効率が相反しない訳だ。
今後はツールと連動してそういう様な仕組みが一般化するのかもね。
xdocletじゃなくてもこれからは「Java標準」のアノテーションも在る訳だし
と勝手に一人で納得してみるテスト

886 :デフォルトの名無しさん:05/02/04 02:36:34
XDoclet2はアノテーション前提でいくのかな?
早くStruts1.2正式対応して欲しい

887 :デフォルトの名無しさん:05/02/04 10:48:31
Strutsのタグで<html:radio>って、iterateの中で回して表示すると
全部 checked="checked"ってついちゃうんですけど、
なぜ?

<logic:iterate id="hoge" ・・・>
<html:radio name="hoge" property="hoge1" value="<%=hoge.getValue()%>">
</logic:iterate>

このコードにすると、でてくるradioにすべてチェックが入るんですよ。

<input type="radio" name="hoge" value="0001" checked="checked">
<input type="radio" name="hoge" value="0002" checked="checked">

これって制御できないですか?

888 :デフォルトの名無しさん:05/02/04 11:09:30
>>887
なんでstrutsタグ使ってるのに、わざわざ<%%>で値入れてるんだ?

889 :デフォルトの名無しさん:05/02/04 13:18:06
EL&JSTLという方針で・・・

890 :デフォルトの名無しさん:05/02/04 13:27:54
>>887
idName属性使えよ

891 :デフォルトの名無しさん:05/02/04 21:05:52
>>882
> 遷移情報その他もろもろを一つの場所で管理できて

ファイル名にフォワード名つけて、その名前をソースに書くのと、ソースに直接書くのと、結局いっしょ。
しかも、ファイル名が隠蔽されるだけで、遷移情報ほとんど管理できないし。
struts-configにまとめてファイル名書いておいて嬉しい思いしたことがない。
ってか、「まとめて書いててよかったぁ」って思ったことあるやついるのかな?
ActionやらActionFormが100近くなってくると、該当する場所探すだけでも面倒だし。

892 :デフォルトの名無しさん:05/02/05 14:05:44
>>887
カスタムタグのソース見たほうが早い。valueが何をしてるか嫁。
Strutsのソースは読みやすいから大丈夫。

893 :デフォルトの名無しさん:05/02/05 17:05:05
>>889
おまいのとこではただのスクリプトレットを EL って呼ぶのか。

894 :デフォルトの名無しさん:05/02/06 20:49:24
オレはvalidtor.xmlが面倒だな。

895 :デフォルトの名無しさん:05/02/06 21:12:17
validator.xmlという名前のファイルは使ったことがない

896 :デフォルトの名無しさん:05/02/07 22:58:04
>>892
わかった。がんがる。

897 :デフォルトの名無しさん:05/02/09 01:03:42
>>895
お舞いも粘着だが

>>894
お舞いもよく間違えるな

898 :デフォルトの名無しさん:05/02/09 21:25:58
>>893
>>894
>>895


899 :デフォルトの名無しさん:05/02/10 00:40:24
894 = O型
895 = A型


900 :デフォルトの名無しさん:05/02/10 20:37:09
tomcat5.5.4 + Struts1.2.4でファイルアップローダを作成しています。
そのアップローダページのJSPで2つのフィールドを設けています。
1つはファイルを指定する<html:file>のフィールド、もう1つは普通の<html:text>フィールドです。
<html:form>で、enctype="multipart/form-data"を指定しているのですが、
こうすると、2つ目のフィールドに日本語を使用すると文字化けしてしまいます。
struts1.2ではこの問題が解決されているとあるサイトで見たのですが、
Struts1.2.を使っているはずの私の環境では化けてしまいます。
何かわかるかたいらっしゃいましたらご教授願います。


901 :デフォルトの名無しさん:05/02/10 21:22:09
>>900
一番簡単な方法は、その文字化けしてるStringを
String title = new String(((String) daForm.get("title")).getBytes("ISO-8859-1"),
"Shift_JIS")
とする事です。


902 :900:05/02/10 21:50:27
>901さん
やはりそれが一番簡単でしょうか。
Struts1.2以上で解決されていると言う情報があったのでもしかしたらと思って質問させていただきました。
どうもありがとうございました。

903 :デフォルトの名無しさん:05/02/11 00:17:53
それはHTMLの仕様だからしょうがない。
enctype="multipart/form-data"を指定してるから、
textフィールドも同様でurlencodedで送られることはない。

ttp://homepage1.nifty.com/algafield/core1.html
でも、ここ見るといけるような気もしてきた。

904 :デフォルトの名無しさん:05/02/11 00:21:45
解決されてるのだろうか?
MultipartRequestHandlerにもそれらしきメソッドがないし、encodingが
付いたメソッドもない。
しかし、Javaは国際化とか言ってる割には、SunやJakartaの開発者達は
本当に文字エンコーディングと文字化け問題に対する認識がないね。
プロジェクトを増産する前に、そーいう所をしっかりやって欲しいよ。


905 :デフォルトの名無しさん:05/02/11 00:31:13
>>903
HTMLの仕様は関係ない。
multipart/form-dataで送られるテキストは、リクエストヘッダに続くボディ内に
バイナリで格納されるだけだから、ストリームから読み込んだbyte[]を
new String(byte[] b, "Shift_JIS") とすればいいだけだ。
問題はその"Shift_JIS"を指定する方法がない事なんだな。
<controller>タグ内の<multipartClass>に続いて<multipart-encoding>
みたいなタグがあって、それで指定できればいいんだけどね。


906 :デフォルトの名無しさん:05/02/11 00:53:38
ちゃんとrequest.setCharacterEncoding()してるか?
Strutsのファイルアップロードでは、request.getCharacterEncoding()して
request.setCharacterEncoding()でセットされた文字エンコーディング名を
取り出し、それを使ってMultipart部分の文字エンコーディング名を指定している。
なので、一見関係ないようだがrequest.setCharacterEncoding()していないと。


907 :デフォルトの名無しさん:05/02/11 00:54:20
↑というのが、1.2から追加になった。


908 :デフォルトの名無しさん:05/02/11 08:45:05
<%@ include file="..." %>で日本語を含むJSPをインクルードしようとしてるのですが、
インクルードしてくると文字化けします。インクルードをやめて、中に直接記述すると文字化けしません。
これは何故ですか?インクルード元JSPとインクルードされる側JSPの文字コードは一緒です。
インクルードされる側JSPは以下のようなものです。(ログインしていたら表示するイメージ)
<logic:present name="UserName">
 <bean:write name="UserName"/>でログイン中です。
</logic:present>

909 :デフォルトの名無しさん:05/02/11 14:00:45
>>908
<jsp:include>つかえ

910 :デフォルトの名無しさん:05/02/11 21:05:10
テーブルにiterateとかnestedとか使ってると
ときたまインデントがえらいことになっちゃうお。

911 :デフォルトの名無しさん:05/02/11 21:19:28
つうか、カスタムタグでインデントするなら、出力されたコードでのインデントはあきらめろ。
むしろJSPでインデントはあきらめろ。

912 :デフォルトの名無しさん:05/02/11 21:56:25
>>910
JSTLつかえ

913 :デフォルトの名無しさん:05/02/11 22:11:13
またJSTL廚か。

914 :デフォルトの名無しさん:05/02/12 00:56:33
厨っていいたい年頃なんだね。

915 :デフォルトの名無しさん:05/02/12 01:56:01
>>914
廚じゃなくてほんとのバカか。
>910 の問いに >912 の回答が的確だと思ってるのか。
JSTL 大好きなんだね。

916 :デフォルトの名無しさん:05/02/12 02:03:48
>>915
>>910が問いに見えるのか?
日本語盲?

917 :デフォルトの名無しさん:05/02/12 02:22:38
>>916
あー、問いじゃないな。
だが、JSTL 大好きなのは間違いじゃないだろ。

918 :デフォルトの名無しさん:05/02/12 03:32:45
だが、厨というのは正しいとはいえないだろ。
JSTLが使える状況でJSTLが使えるならStrutsタグ使わない方がいいし。

919 :デフォルトの名無しさん:05/02/12 03:56:24
Struts制作の場合、JSTLタグとStrutsタグ、どっちを使うのが
正しいのでしょうか?
どちらも3年前に制作されてますが、どっちがスタンダードなのか
未だに判断できません。
自分としてはJSTLの方が使いやすいのですが・・・


920 :デフォルトの名無しさん:05/02/12 04:21:09
> どっちがスタンダードなのか未だに判断できません。

それは、情報収集能力に問題がありそうだ。
JSTLは「Java Standard Template Library」だぞ。スタンダードだぞ。

Strutsは、htmlタグ以外のカスタムタグは使う必要ほとんどなし。
ActionやActionForm系以外の仕組みは、あまり使う必要ないと思われ。

921 :デフォルトの名無しさん:05/02/12 13:28:31
JSTLよりstrutsタグがいいと思っているヤツの気がしれん。

922 :デフォルトの名無しさん:05/02/12 16:33:56
すいません。
validateエラー発生時の移動パスを可変にする事はできないのでしょうか?
通常<action>タグ内のinputで指定するパスを可変にしたいのです。
validateエラー発生時のinput移動パスを、フォーム入力の各ページによって
page.jsp?id=1111 とか page.jsp?id=2222 にしたいのです。
ValidatorFormのvalidateメソッドをオーバーライドして、そこで
ActionMapping#setInput()をしたら、ActionConfigは凍結されてるの
エラーが出てしまいました。(T_T)
フォームのvalidateエラー発生時のinput移動先を可変にする方法を
教えてくださいませ。


923 :デフォルトの名無しさん:05/02/12 17:23:37
なぜ可変にしたいかのほうに興味がある。

924 :デフォルトの名無しさん:05/02/12 17:26:54
>>922
何がしたいのかさっぱり意味不明すぎるけど、
そのActionFormでsetId/getIdメソッドを持てばいいだけじゃないの?


925 :デフォルトの名無しさん:05/02/12 17:35:16
そんな・・・・
例を出しますと、マルチスレッドの掲示板を作成してるのですが
thre.jspでスレッドを表示しています。で、そのリクエストは
thre.jsp?id=1111 の様にidのパラメータを付けています。
そのidで表示するスレッドを決めてる訳です。
で、そのthre.jspからの入力フォームが失敗したら、同じスレッドに
返したいのですが、<action input="thre.jsp">だとidパラメータの
指定ができず、元のスレッドに戻せないのです。
action inputのパスに可変パラメータを付ける方法を教えてください。
オーバーライドvalidate()内でrequestに属性を付加する方法も
考えたのですが、パラメータで指定したいのです。
誰かお願いします。


926 :デフォルトの名無しさん:05/02/12 18:52:11
>>918 >>921
以下 JSTL で置き換えるとどんなの?
よくある一覧で編集するような画面。
JSTL だとすばらしくよくなるか?

[[[ JSP ]]]
<TABLE>
<logic:iterate id="row" name="HogeForm" property="rows">
 <nested:root name="row">
  <TR>
   <TD><nested:write property="empId"/></TD>
   <TD><nested:text property="empName"/></TD>
   <TD><nested:checkbox property="empFlg"/></TD>
  </TR>
 </nested:root>
</logic:iterate>
</TABLE>}

927 :926の続き:05/02/12 18:52:43
[[[ Formクラス ]]]
public class HogeForm extends ActionForm {
 private List rows = new ArrayList();
 public Row getRows() {
  return rows;
 }
 public Row getRow(int index) {
  while (rows.size <= index) {
   rows.add(new Row());
  }
  return (Row) rows.get(index);
 }
 //一覧の1行をあらわすインナークラス
 public static class Row {
  private String empId;
  private String empName;
  private String empFlg;
  //アクセッサ(ry
 }
}

928 :926:05/02/12 18:54:50
indexed が抜けてた。

   <TD><nested:write property="empId" indexed="true"/></TD>
   <TD><nested:text property="empName" indexed="true"/></TD>
   <TD><nested:checkbox property="empFlg" indexed="true"/></TD>

929 :デフォルトの名無しさん:05/02/12 19:28:06
>>925
Action#execute()で
ActionForward af = mapping.getInputForward();
return new ActionForward(af.path + "?id=" + id);
みたいにするのはだめなの?
どのみちAction#execute()でidを動的につけないといけないよね?

930 :デフォルトの名無しさん:05/02/12 20:30:10
>>929
forwardのパスって、クエリ文字列OKだったっけ?

931 :デフォルトの名無しさん:05/02/12 21:21:47
>>930
たしかAction#name.equals()で比較して判定していたような
いなかったような。

932 :デフォルトの名無しさん:05/02/12 21:27:28
>>926
Strutsのしくみを使うためならStrutsのタグの方がいい。

933 :デフォルトの名無しさん:05/02/12 22:00:22
>>932
logoc:iterateはStrutsのしくみなんか使ってないだろ

934 :デフォルトの名無しさん:05/02/12 22:00:58
間違えた。logoc → logic

935 :デフォルトの名無しさん:05/02/12 22:28:59
>>926
すばらしく良くはならないけど、JSTLでも同じ文字量で実現できる。
覚える事は少ないほうがよく、使うタグは共通してた方がいい。

936 :デフォルトの名無しさん:05/02/12 22:37:03
>>925
Struts使っているのにthre.jsp?id=1111なんてするんじゃないよ。

クライアントからread.do?id=1111が来る。
Actionで1111のデータを読み込んで(thre.jspを使って)クライアントにデータを返す。
クライアントからwrite.doが来る。
OKならデータを書き込んで(thre.jspを使って)クライアントにデータを返す。
NGならinput="thre.jsp"で再表示。

ActionForm の中に、idを持つ。setId()/getId()

937 :デフォルトの名無しさん:05/02/12 23:23:33
いや、Struts使っているからといって、リクエストパラメータ使ってはいけないわけじゃない。
って、JSPを直接呼び出すなってことか。
それなら同意。

938 :デフォルトの名無しさん:05/02/12 23:24:15
>>933
nested:*のほうだよ。

939 :926:05/02/12 23:53:32
>>932
Struts の仕組みを使うために Struts タグを使ってるわけじゃない。
こういうような、よくある一覧画面などで Struts の機能を一部放棄してまで
標準である JSTL 使ったほうが良いと思ってるのかを意見を聞きたい。

つーか、JSTL 薦める香具師は nested:iterate とか int 引数の getter とか
熟知してんの?あるいは薦めてんのは c:if とかそんなんだけ?
JSP2.0 の EL 直書きは便利そうだけど。ってか JSP の機能になるから
絶対使うけど。

940 :デフォルトの名無しさん:05/02/13 00:04:09
>>939
別にstrutsタグを全否定してる訳じゃない。htmlタグの幾つかは使う事になる。
beanとlogicは使う必要がないな。nestedはhtmlに関連する時だけ使う。
それだけだよ。
ちなみに>>926は、JSTLでもほぼ同じ文字量でできる。

941 :デフォルトの名無しさん:05/02/13 00:18:12
nestedなんて本当に使ってる奴いるんだ・・・・

942 :デフォルトの名無しさん:05/02/13 00:19:19
>>939
なにを必死になってるのかわからないが、JSTLでできるならJSTLを使えと。
どこから「Strutsの機能を一部放棄してまで」という言葉がでてくるんだか。
すでにJSP2.0はリリースされてるし実装も安定してるから、ELは当然直書きできる前提。
古い環境使う前提があるなら、それは示してくれないと。

943 :デフォルトの名無しさん:05/02/13 00:19:50
>>941
項目数が可変のときは、とりあえず使う。

944 :デフォルトの名無しさん:05/02/13 00:33:16
>>940
なんとなく納得した。
で、>>926>>928) が同じ文字量でできるって、
出来る出来ないではなく、おまいの理想形で書いてみてくれ。
それか nested 使ってるから、理想系はあのままか?

945 :デフォルトの名無しさん:05/02/13 00:34:58
>>941
nested 知らなかったんだな。

946 :デフォルトの名無しさん:05/02/13 00:41:34
>>942
それは正直すまんかった。既に JSP2.0 バンバン使ってるのか・・・
WebSphere の PJ を 2 つ掛け持ちしてるが、使ってない。

947 :デフォルトの名無しさん:05/02/13 01:57:12
JSP2.0はいいでよ。
ちょっと使えば、中途半端なELの仕様が嫌になってくるけど。

948 :デフォルトの名無しさん:05/02/13 02:23:02
JSTLはいいが、core、fmt、sql、xml 以外のサポートタグまで多用する
ようになると、何の意味もなくなるからな。。。
それなら、素直にスクリプレット直書きした方がいいかもしれん。

949 :デフォルトの名無しさん:05/02/13 02:37:16
coreとfmt以外はつかわんなぁ。
sqlとかは使うべきじゃないよね。
ColdFusionモドキがやりたかっただけかと。
xmlって使えるの?

950 :デフォルトの名無しさん:05/02/13 03:23:43
struts VS. JSTL
の前に
JSPタグ VS. EL式。

<foo atter="<%=obj%>" />
というのが
<foo "$obj" />
になるってのだけでも使う価値あると思うのだが
プロジェクトというかweblogicがJSTLを許さないのが悲しい。
="<= obj %>" って最高に汚らしい。

951 :デフォルトの名無しさん:05/02/13 04:13:43
<jsp:expression>ニダー</jsp:expression>

952 :デフォルトの名無しさん:05/02/13 13:05:44
foo.hoo.haaって書きゃいいんだから、nested使うメリットが思い浮かばん。
冗長になるだけじゃん。

953 :デフォルトの名無しさん:05/02/13 13:48:07
nested:rootは使うべきじゃないな

954 :デフォルトの名無しさん:05/02/13 13:48:41
つーか>>950・・・

955 :デフォルトの名無しさん:05/02/13 15:55:43
>>952
nested の機能のほんの一部しか分かってないだろ?
以下、同じ処理だがどっちが冗長だ?

<logic:iterate id="rows" name="HogeForm" property="rows">
 <bean:write name="rows" property="id" indexed="true"/>
 <html:text name="rows" property="name" indexed="true"/>
 <html:checkbox name="rows" property="flg" indexed="true"/>
</logic:iterate>

<nested:iterate property="rows">
 <nested:write property="id"/>
 <nested:text property="name"/>
 <nested:checkbox property="flg"/>
</logic:iterate>

956 :デフォルトの名無しさん:05/02/13 16:35:48
・あまり利用されておらず、タグそのもののバグの発見や修正が遅れがち
・使わなくても著しく不便な点もない
などの理由で、非推奨にしようという議論がDev-MLで持ち上がっていたことがあったね。

957 :デフォルトの名無しさん:05/02/13 16:56:33
議論が持ち上がって、そうなってないってことだろ。
議論だけ探すなら、いろんなところでいろんなものが非推奨にされかけてるよ。

958 :デフォルトの名無しさん:05/02/13 17:12:05
んな事はない。
誰かが提言しても賛同を得られなきゃスルーされて議論にもならない。
strutsタグはhtmlだけだな。外は非推奨でいい。

俺はstruts自体を非推奨にしたい。俺が開発したフレームワーク
「YamamotoFM」を代わりに標準にしろと提言したい。

959 :デフォルトの名無しさん:05/02/13 17:44:02
>>958
FMって何の略?FWの間違いじゃないよね?

960 :デフォルトの名無しさん:05/02/13 19:57:35
>>959
フレームワークを何の略だと思ってたの?
FlayMwork
http://maigner.bei.t-online.de/mwork/mwdoc.htm
恥ずかしいよ

961 :デフォルトの名無しさん:05/02/13 20:05:45
>>959-960
ここまで英語感の無い香具師がいるとは・・・
FMは、FoundationModel の略に決まってるだろ。
こっちの方が自然な表現なんだよ。
プログラムするからには、最低限の英語感くらい身に付けた方がいい。
和製英語的ネーミングばかりしてるだろ。

962 :デフォルトの名無しさん:05/02/13 20:06:59
>>958
非推奨への賛同が却下されるだけの、説得力のある必要性があったということだな。

> 俺が開発したフレームワーク
> 「YamamotoFM」を代わりに標準にしろと提言したい。

標準にするには、ちょっと名前がかわいくない。せめて萌えるイメージキャラクタが必要。
余力があれば、使える機能を実装してほしい。

963 :960:05/02/13 21:02:11
>>961
ごめん、英語フランス語ロシア語は会話では不自由しない
和製英語はまずないけど、
理系にはわかりにくい古代フランス語風の名前は付けることが多い。


964 :デフォルトの名無しさん:05/02/13 21:26:55
>>963
会話と技術用語は違うってことがいいたいのかな?

965 :デフォルトの名無しさん:05/02/13 21:28:27
古代フランス語か・・・
つまり、フランス語が古代からあったと。
つまり、しったかかと。

966 :デフォルトの名無しさん:05/02/13 21:48:14
なんかネタが多いぞ。もそっと真面目に語ろうぜ。

967 :デフォルトの名無しさん:05/02/13 21:57:10
まあ、知らん人にはどうでもいいけど
今からだいたい1000年前の言葉
結構今の言葉と似ているからイメージとしてつかみやすい
ギリシャ語はわけわからん、ラテン語は終わってる

968 :デフォルトの名無しさん:05/02/13 23:27:14
>>967
つまり、1000年程度前を古代といったわけか。
つうことは、源氏物語は古代日本語で書かれてるわけだな。

969 :デフォルトの名無しさん:05/02/13 23:34:32
で、それは Struts の良さとどう関連があるんだ?

970 :デフォルトの名無しさん:05/02/13 23:46:15
なんか967が必死で泣けるが
Old Frenchって言葉知らんの?
辞書とか見ることない人間か?

971 :デフォルトの名無しさん:05/02/14 00:53:16
しらない。Old Frenchって書いてある辞書を見ることはない人間。
それにしても、古フランス語とか、古期フランス語ならわかるけど、古代っていうのはねぇ。
まるで古代に使われてるかのようだ。
理系なので、違う定義の言葉が混ざらないように気を使うけど、文系の人は気を使わないんだね。
勉強になったよ。
これで、いいStrutsアプリケーションが組めるってもんだ。

972 :デフォルトの名無しさん:05/02/14 02:32:18
> 理系なので、違う定義の言葉が混ざらないように気を使うけど、文系の人は気を使わないんだね。
「古代」にも「古典」にも「古記」にも「old」を使う英語圏の人はみんな文系?


973 :デフォルトの名無しさん:05/02/14 03:43:21
>>972
ん?
「古代」という日本語には「近世」の前の時代という定義もあるから、「近世」の後の時代を表すのに「古代」を使うとまぎらわしいという話をしたかっただけだが。
へんな理屈こねて必死になることなの?

974 :デフォルトの名無しさん:05/02/14 03:47:45
古代 ・・・ ancient times
古典 ・・・ classic

まあ、Old Frenchは知ってても、ancientやclassicは知らなかったってことか。

975 :デフォルトの名無しさん:05/02/14 04:05:03
どうでもいいが、とりあえず「オレってメソッド名に古代フランス語風な名前つけちゃうんだぜ」って得意になってるやつがいるということはわかった。
Strutsでアプリ組むときには、そういうのにも注意しろってことだな。

976 :デフォルトの名無しさん:05/02/14 11:31:14
>>954
って
>>950
のどこがおかしいん?
runtime expr がEL式でないとウザいってことでそ。

977 :デフォルトの名無しさん:05/02/14 11:31:50
>>976
attr=
ってのが消えているのか。

978 :デフォルトの名無しさん:05/02/14 13:44:27
激しく外出かもしれませんが、
<bean:message>タグはJSTLでどう置き換えれば良いでしょうか?

979 :デフォルトの名無しさん:05/02/14 21:18:39
<fmt:message>かな。よく知らん。

980 :デフォルトの名無しさん:05/02/15 10:04:32
JSP使えないなら素直にVelocityに行っちゃってください。
半日あれば大抵の事はできるようになる。マジで。

ここはJSP教室じゃない。


981 :デフォルトの名無しさん:05/02/15 10:33:59
>980
誰に言ってんだ?
ここは精神病院じゃないぞ。

982 :デフォルトの名無しさん:05/02/15 10:50:30
独り言言ってるからって精神病院送りするなよ

983 :デフォルトの名無しさん:05/02/15 11:26:10
認証について質問があります。

一つのWEBアプリケーションに、ユーザ認証していないと表示できないページと、
誰でもアクセス・表示できるページがある場合、どのように認証処理を行えば良いのでしょうか?
RequestProcessorを継承したクラスを作って、その中で処理を行おうとした場合、
誰でもアクセス・表示できるページでも認証処理が入ってしまいます。

984 :デフォルトの名無しさん:05/02/15 11:52:46
>>983
<action rolres="a, b, c" />

> RequestProcessorを継承したクラスを作って、その中で処理を行おうとした場合、
> 誰でもアクセス・表示できるページでも認証処理が入ってしまいます。

それはおまえの実装が悪いだけ。

985 :デフォルトの名無しさん:05/02/15 13:21:17
>>983
URLでアクセスの区別ができるなら、
Servletのフィルタを使うのが簡単。

986 :983:05/02/15 13:51:25
>>984さん、>>985さん
どうもありがとうございます。
どちらも大変参考になりました。状況に応じて使い分けたいと思います。

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)