△△もっとStrutsの良さを教えてくださいSession5

△△もっとStrutsの良さを教えてくださいSession5 at TECH

1:デフォルトの名無しさん
06/12/30 18:05:08
Apache Strutsフレームワークについて語るスレ

前スレ
△△まだまだStrutsの良さを教えてくださいSession4
ｽﾚﾘﾝｸ(tech板)

2:デフォルトの名無しさん
06/12/30 18:05:53
過去スレ
△△さらにStrutsの良さを教えて下さいSession3
ｽﾚﾘﾝｸ(tech板)
△△もまいら漏れにStrutsの良さを教えてください
ｽﾚﾘﾝｸ(tech板)
△△つづいて漏れにStrutsの良さを教えてくだっさい
ｽﾚﾘﾝｸ(tech板)

エクリプス＋Struts開発
ｽﾚﾘﾝｸ(tech板)l50

The Apache Struts Web Application Framework
URLﾘﾝｸ(struts.apache.org)

Strutsファンページ
URLﾘﾝｸ(homepage2.nifty.com)

Strutsメモ
URLﾘﾝｸ(muimi.com)

3:デフォルトの名無しさん
06/12/30 18:40:49
まだstrutsとか使ってるやついるの？

4:デフォルトの名無しさん
06/12/30 20:52:29
めっさいる

5:デフォルトの名無しさん
06/12/31 00:08:31
かわいそす

6:デフォルトの名無しさん
06/12/31 02:12:43
>>3
開発者の人に、Strutsの次に来るフレームワークで事例ありますかと聞いても
「次はリッチクライアントの時代だから純粋WebのフレームワークはもうStrutsで十分」
と言う。じゃあリッチクライアントで目星をつけてる技術/製品はと聞いたら
「今はまだ乱立状態だから絞れない」と言う。
結局長い目で保守を考えないといけない現場だと当分Strutsで行くしかないべ

7:デフォルトの名無しさん
06/12/31 09:31:54
>>6
っていうか、その開発者は自分でフレームワークの評価や、生産性について
考えられないだけ
Strutsマンセーっていってても別の流れが来たらそっちに乗っかるんだから

8:デフォルトの名無しさん
06/12/31 10:37:23
教育コストや学習コストを考えると
世の流れに乗るのもまた選択の理由になり得る。

9:デフォルトの名無しさん
06/12/31 10:45:09
世の中の流れに乗る＝教育コスト、学習コストの削減には一概にはならん
そういう短絡的発想が遺憾といっているｗ

10:デフォルトの名無しさん
06/12/31 14:53:56
>>9
使っている人が多いと情報を入手しやすくなるから
教育コスト、学習コストの削減にはなるんじゃない？

11:デフォルトの名無しさん
06/12/31 15:11:39
基礎学習においての学習コストが、新しいフレームワークで低くなっても
ワークアラウンドが必要な場面の情報収集で割を食うから普及度は大切な指標だよ

12:デフォルトの名無しさん
06/12/31 16:37:48
そもそも、開発者全員がフレームワークについて情報を得られなきゃいけないって発想が間違っている。
Ｓｔｒｕｔｓを使うにしても、Ｓｔｒｕｔｓの情報が溢れていなければ使えないような使い方をしている時点で
学習コストがかかりすぎている使い方をしているってこと。
大体、Ｓｔｒｕｔｓにしたってこんだけ情報があったってマトモに使えるやついねーじゃんｗ

13:デフォルトの名無しさん
06/12/31 16:47:37
>>12で逝ってるフレームワークとは、Ｓｔｒｕｔｓのような汎用フレームワークの事

14:デフォルトの名無しさん
06/12/31 18:15:54
フレームワークなんてデザパタと同じだ
乱立してるより型落ちでも同じ使い方の奴のが保守コストが低い
Struts以外のフレームワークをよしとする風潮がないのは当たり前

15:デフォルトの名無しさん
06/12/31 18:22:26
右へ習え的な考えしかしない香具師がろくでもないシステムを作る現実

16:デフォルトの名無しさん
06/12/31 18:24:03
いかにも社会に出てない奴の発想だな・・・

17:デフォルトの名無しさん
06/12/31 18:26:41
いかにも残業したり休日出勤したりするのがこの世界の常識って考えのヤツの発想だなｗ

18:デフォルトの名無しさん
06/12/31 18:29:06
真逆すぎて呆れるばかり

19:デフォルトの名無しさん
06/12/31 18:33:27
現存のStrutsプロジェクトをみてあきれるばかりｗ

20:デフォルトの名無しさん
06/12/31 18:34:51
>>19Strutsを使ったプロジェクトねｗ

21:デフォルトの名無しさん
06/12/31 18:35:42
オウム返しにしても寒すぎる、派遣の妄想ってとこか。くだらん

22:デフォルトの名無しさん
06/12/31 18:40:04
まぁ、次のフレームワークが広まるまでStruts使ってなさいｗ
では良いお年を

23:デフォルトの名無しさん
06/12/31 20:54:14
みなさんが、Strutsプロジェクトに携わったのは何件ですか？
私は、前に１回だけ．．．
正直な話、初めて見た時、何故これで動くのか訳がわからなかった
（この当時、本でもネット上でもあまり詳しい説明されてるやつがなかったし、っていうか見つからなかったし）
「なんで普通にServletにしねぇんだよ」と心のなかで思っていた。

この仕事でよい年を迎えることができると思っている人はあまりいないような気がしますが
「健康である年を」

24:デフォルトの名無しさん
06/12/31 21:06:02
なんで？StrutsってただのMVC2フレームワークじゃん

25:デフォルトの名無しさん
06/12/31 21:54:28
>>23
Bateから1.0になったばかりの頃に、Struts+EJBベースのフレームワークを作りました。
いまも別件でStruts＋Spring+Hibernateベースのフレームワークを作ってる。
Strutsに限らず、汎用フレームワークはそのプロジェクトでどのように使うかって言う方針を立てて、
業務を実装するプログラマ達には必要最低限の使い方で実装できるように準備しないと、開発者
全員が汎用フレームワークの広い知識を備えなければならなくなる。
つまり、個々の開発者が（例えば）Strutsを直接触りまくるような現場では、>>23のような状況に陥ってしまう。
そういう現場では、開発者は終始深い森の中を地図もコンパスも無く彷徨い歩くような状況にあるので、
結果的に大変なだけでいい仕事は出来ないよﾈ

26:デフォルトの名無しさん
07/01/01 07:01:58
なあstrutsって前提条件として覚えることが多すぎない？
例えばvalidatorつかってエラーメッセージ表示するには
「エラーメッセージを読込むリソースファイルはキー org.apache.struts.action.MESSAGE で指定されたファイル (デフォルトのメッセージリソース)でなければなりません。」
だったり、validateエラーで飛ばす先のmappingの記述が「input=""」だったり。
taglibも学習・デバッグコストの割に新しいことができるようになるわけじゃ
ないし。見た目はscriptletよりはマシかもしれないけど、大してよくならないし。

>>25
前に別件でシンプレクスってところのStruts＋Spring+Hibernateベースのフレームワークを
いじったけど、あれはひどかった。携わってる人一人一人の能力が高いのに、
ろくに設計をしないでつくると酷くなる典型例だった。ドキュメントも無いし。
あと速度遅すぎ。

27:デフォルトの名無しさん
07/01/01 09:48:26
多いねぇ

それにStrutsに限らずWebページベースのサーバサイドシステムだと、大前提としてコアJavaだけでなく、
HTMLやCSS、Java拡張技術として、Servlet、JSP、Tablib、等の技術をまんべんなく知ってないといけない。
更にその上にStruts等の知識が必要になる。
Strutsを採用している時点で物凄い教育コストがかかるってこと。
実装工程で、最低Javaは書けるって言う人間がスグに投入できないのは非常にまずい。
短期間作業に関わる技術者のスキルを当てにはできないし、仮にスキルがあったとして、その人がいなくなったら
保守できないようなつくり方たされたらかなわんし。
それに、Javaは書けるってレベルの技術者なら単価も安いしね。

28:デフォルトの名無しさん
07/01/03 02:32:33
>>26
scriptletからtaglibではえらい進歩じゃないか？
いや、目標が低すぎるか。
とりあえずscriptletなんて一切使うことを許容するべきじゃないね。
俺が入った時点でゴリゴリ書きまくっていて後始末が大変だった。

>>27
こういうのを把握しているのはFWとかアーキテクチャを
抑えている人間だけでえーんちゃう？

業務実装者は手順どおりに業務ロジックだけを
こりこり書けばいいようにすればいいというか、
あいつらにそんなもの意識させちゃ駄目だ。

29:デフォルトの名無しさん
07/01/03 02:55:54
>>28
＞こういうのを把握して・・・・
「・・・抑えている人間」って言うと、フレームワークを実装するプログラマとか
も入るから、ホントウに意識しなきゃいけない人間はアーキテクトだろうな。

30:デフォルトの名無しさん
07/01/03 15:01:05
>>26
scriptletなんて使う状況になるのは設計が破綻している証拠だな。
アホな連中に好き放題使われて地獄を見たことがないのかい？
まぁこれは上でコントロールする人間がいないのが悪いんだけど。

画面は渡されたbeanを展開するとか
条件（画面で判断した方が良いレベル）で
表示をちょっと切り替えるとかその程度だけにするべき。

それでまかなえないようなアプリなら
それはもうStrutsでやるべきじゃない。
もうリッチクライアントを考えるべき、
と言いたいところだがなんか良い選択肢無いのかね・・・

31:デフォルトの名無しさん
07/01/03 15:13:28
Java Applet+Webサービスがいい気がするがフレームワークとかあったりするの？
じつはJava質問。相談スレにも投下してしまってるんだが

32:デフォルトの名無しさん
07/01/03 23:21:24
MVCが徹底できていればscriptletもそんなに汚くならない。
でもscriptletを許可するとスキルの低いPGがjspにロジックを埋めちゃう。
taglibで全部やらせるには教育コストがかかる。
100画面程度のシステムならコードレビューで面倒見れるけど、
サブシステムごとにサブリーダーを置くようになると途中で破綻しちゃう。
どうしたもんかなあ

33:デフォルトの名無しさん
07/01/04 00:31:19
画面の部品化

34:res
07/01/04 11:32:44
Strutsって便利？？
ASPのほうがわかりやすくて好き

35:デフォルトの名無しさん
07/01/04 12:52:36
ASP知らないが、strutsは便利ではないｗ。
学習コストに見合わない生産性の低さに泣ける。
eclipse用のstruts plugin等を使えば、多少は、ましになるけれど。
今から新規の案件で使うのは、おすすめしない。

36:デフォルトの名無しさん
07/01/04 21:44:07
ASP.NETが最強だな

37:デフォルトの名無しさん
07/01/04 21:48:02
ASPはJSPとくれべるモンなんじゃね？

38:デフォルトの名無しさん
07/01/04 21:52:45
>>35
ではﾅﾆがお勧めですか？

39:デフォルトの名無しさん
07/01/04 22:07:35
ポストstrutsは何か？
ってのを言われて久しいけど、未だに決定的なのがないから
現場レベルでは、strutsしか使えない。

40:デフォルトの名無しさん
07/01/04 22:17:42
多分Javaが廃れるまではStrutsを使い続けると思う
Railsあたりの次世代FWが実績つけてきたところで乗り換える予定

41:デフォルトの名無しさん
07/01/04 22:41:27
あわれ・・・・

42:デフォルトの名無しさん
07/01/04 23:12:53
ASP.NETに比べるとStrutsってめちゃめちゃ難しい気がするんだけど、今時のWEBシステムってこんなもんなの？
PHP5とかってのも難しい？

43:デフォルトの名無しさん
07/01/04 23:25:47
ASP.NETとStrutsって比べる対象になるのかってのが問題なんだが・・・

44:デフォルトの名無しさん
07/01/04 23:28:03
でも一度ASP.NETの開発を経験しちゃったら
もうJavaには戻りたくなくなってしまうし。

45:デフォルトの名無しさん
07/01/04 23:30:07
ふーん

46:デフォルトの名無しさん
07/01/05 00:39:27
ASP.NETの真似をしようとしたJSFが失敗してしまったからな
でもWin統一環境でないとASP.NETは採用し難いというのもあって、結局現在はJavaの開発がまだ多い
今年は減りそうな気がするけど

47:デフォルトの名無しさん
07/01/05 00:45:01
Javaが減ってどの言語が増えるの？

48:デフォルトの名無しさん
07/01/05 00:51:51
普通にRubyじゃね？
自分の周りでも少しずつ開発事例を見かけるようになってきたし、
最近は本屋に行っても、どこもコンピュータコーナーはRuby本ばかりだし
個人的には、別に言語に拘りはないからどうでもいいけど

49:デフォルトの名無しさん
07/01/05 01:51:35
Rubyちらっと触っただけなんでよく知らないんですが、
性能面とかで大規模な案件に耐えられる代物なんですか？
どうしてもしょせんスクリプト言語ってイメージが取れません・・・
偏見ですかね？？？

個人的にはOOで設計した方がいいぐらいの大きさのプログラムなら
もう慣れているJavaで書いた方が手っ取り早いし、
本当にささっと作るだけならPerlやるかなーって感じです。

50:デフォルトの名無しさん
07/01/05 01:52:10
Javaが出てきた時はC++プログラマはﾐﾝﾅそういってたな・・・・

51:デフォルトの名無しさん
07/01/05 02:11:53
サーバーサイドのフレームワークじゃなくて、そろそろWebブラウザの側が
もう少しリッチに進化してほしい。DBのデータを扱うことを想定したTABLEタグとか
DIとかTDDとかで生産性向上するよりそっちの方が効果があるんじゃなかろーうか

52:デフォルトの名無しさん
07/01/05 07:36:28
>>51
ブラウザはWEBアプリ専用のソフトウェアじゃねえんだよ！！

53:デフォルトの名無しさん
07/01/05 08:06:32
>>49
今のところRubyの方が遅いのは事実だが、
いいハードを買うかクラスタを増やすかすれば必要な性能は達成できる。
Rubyは生産性が高い（例のRailsの「Javaの10倍」ね）ので、開発コストを減らした分の金で
元は十分以上に取れる。というかハードなんて人件費に比べれば安いし。

ってのがRuby屋の言い分だと聞いた。
立場は逆だが、>>50の言うような「Java登場時にJavaプログラマが言ってたこと」に似てるな。

54:デフォルトの名無しさん
07/01/05 10:15:01
>>51
つAjax
DBから取得したデータをJSON変換して、後はJavaScriptに扱わせる。
SwingのTableModelみたいなことは、今でもやろうと思えばできる。
Swingと同じで、Ajax主体でGUIを扱うFWがまだ無いけど

55:デフォルトの名無しさん
07/01/05 12:15:04
>>53
Javaちらっと触っただけなんでよく知らないんですが、
性能面とかで大規模な案件に耐えられる代物なんですか？
どうしてもしょせんインタープリタ言語ってイメージが取れません・・・
偏見ですかね？？？

個人的にはOOで設計した方がいいぐらいの大きさのプログラムなら
もう慣れているC++で書いた方が手っ取り早いし、
本当にささっと作るだけならVBやるかなーって感じです。

今のところJavaの方が遅いのは事実だが、
いいハードを買うかクラスタを増やすかすれば必要な性能は達成できる。
Javaは生産性が高いので、開発コストを減らした分の金で
元は十分以上に取れる。というかハードなんて人件費に比べれば安いし。

・・・なるほど、たしかに似てるなｗ

56:デフォルトの名無しさん
07/01/05 21:51:33
>>55
Amazon.comってWeblogicだそ？

57:デフォルトの名無しさん
07/01/05 21:52:49
あ、なんでもない忘れてくれｗ

58:デフォルトの名無しさん
07/01/05 21:55:01
>>56
そうなのか?
perlって記事もあるけど。

URLﾘﾝｸ(neta.ywcafe.net)

59:デフォルトの名無しさん
07/01/05 21:58:56
相当前に聞いた話だからもうperlなのかも？

60:デフォルトの名無しさん
07/01/05 22:56:58
>>54
Ajaxってどうなん？
所詮JavaScriptじゃろ？
ていうかなんでJavaAppletがほったらかしなんだか判らんｗ

61:デフォルトの名無しさん
07/01/05 23:20:28
さっさとJSFに乗り換えた方が幸せになれると思うんだが。
再利用性などというマヤカシに捕らわれてるのが移りが遅いな。
実際に再利用できるものは汎用Util化されてるだろうしFWはなんでもいいはずなのに。

62:デフォルトの名無しさん
07/01/05 23:28:41
strutsで再利用と言えば、
Actionを連鎖させて途中のアクションをフィルタ的に使ったりすることもあるけど
実際は、1画面1アクションで作られてることが多いみたいだね。
明確にM-V-CとするよりもM-VCのほうが、効率いい場合もあるし。

63:デフォルトの名無しさん
07/01/05 23:31:16
>>62
＞1画面1アクション
そういう使いかたした事ない

64:デフォルトの名無しさん
07/01/05 23:36:42
>>62
多いっていうか、そういう風にしか使い道が思いつかないんだろ

65:デフォルトの名無しさん
07/01/05 23:36:58
うちのプロジェクトも原則は1画面1アクションだよ
Action連鎖すると修正時の影響範囲がわかりにくくね？
しょせん、Actionなんてコントローラだし対して再利用性を求めてもしょうがないような

66:デフォルトの名無しさん
07/01/05 23:42:27
Actionでやるべき事と、業務ロジックを分離した時、Actionでやることはほとんど共通化できるんだけどね

67:デフォルトの名無しさん
07/01/05 23:47:03
っていうか、業務ロジックを呼び出すActionの振る舞いなんてﾐﾝﾅ同じじゃん

68:デフォルトの名無しさん
07/01/05 23:51:43
普段はどちらかというと、1画面につき2Actionかな？
ただ、入力→確認→完了とか、複数ページにわたる入力みたいな
いわゆる「画面フロー」の間は画面間で1Actionだな。

JSFだと、「1Action」が「1アクションメソッド」に変わる感じ？

69:デフォルトの名無しさん
07/01/05 23:54:46
1画面1Actionにすると表示前準備とリクエスト処理が混在してわかりにくい。
あちこちの画面から呼ばれるような処理だと、さらにゴチャゴチャ。

70:デフォルトの名無しさん
07/01/06 00:15:25
ActionってCommandパターンだからと思って、最近は１URL１Actionにしている
以前は１画面毎にDispatchAction使ってたが、あまり意味ないし使いにくいのでやめた
ロジックはサービス層のクラスにまとめて共通化してるので、
Action自体はパラメータの受け渡しぐらいしかやらないし
画面単位ではまとめないけど、初期化処理とか検索処理とか編集処理とか
似たような処理をするActionを継承でグループ化したりはしている

71:デフォルトの名無しさん
07/01/06 18:10:10
Action連鎖させるなんて絶対にやめるべき。
値の持ち回りはSessionにぶち込んででしょ？
大量にバグが出るし、修正が発生した時地獄を見るよ。
コミットするような処理した後
一覧か業務フローのトップの画面を表示するActionにリダイクレトする、
とかならやるけど、これはもう処理の流れが切れているから。

OO中途半端にやってる人（俺含めて）を見ていつも思うんだけど
再利用って言葉の一人歩きがひどすぎないか？

72:デフォルトの名無しさん
07/01/06 18:20:35
sessionじゃなくてrequestにぶち込むだろ普通。
sessionの使用禁止のプロジェクトもあるし。

どうでもいいけど、sessionの使用禁止ってのは無しにしてほしい。
ロードバランサ入れたときに別サーバに振り分けられるからって言うけど
ロードバランサにsession維持機能あるんだから有効にすりゃいいだけじゃん。

73:デフォルトの名無しさん
07/01/06 18:23:42
NECダイレクトのサイトは、コンテナに頼らず自前でセッション管理してるっぽい？
URLに入ってるセッションIDらしき文字列がちょっと見慣れないんだが。
そういう方法もありかね。

74:デフォルトの名無しさん
07/01/06 18:25:24
対話の質によるけどな。
フルGCの発生原因は中途半端な寿命のオブジェクトが在ることだし。

75:デフォルトの名無しさん
07/01/06 18:27:27
>>73
URLリライティングだろ、Tomcatでも使えたはず

76:デフォルトの名無しさん
07/01/06 18:46:34
Action連鎖はわけわからなくなるな。。
validationとか絡んだら無限ループなる。

77:デフォルトの名無しさん
07/01/06 20:24:05
>>76
atamawaruikaradayo(pu

78:デフォルトの名無しさん
07/01/08 07:59:12
>Action連鎖
大昔から否定されてきたのをいまだ言ってるやつがいるのか・・
少しはググってみたら、どうだ？

79:デフォルトの名無しさん
07/01/10 08:48:22
>>78

URLﾘﾝｸ(civic.xrea.jp)

この人なんかは推奨してるみたいだけど、否定する理由っていうのはなに？

80:デフォルトの名無しさん
07/01/10 20:17:35
Strutsインアクションでは
Actionを連鎖したくなるのは、Actionにビジネスロジックを書いているからだ！！
ビジネスロジックをサービス層に移せばActionの連鎖なんか必要ないはずだ！！
って書いてました

81:デフォルトの名無しさん
07/01/10 20:23:21
>>80
そういう問題ではないな

82:80
07/01/10 20:30:46
>>81

そやな。。俺も自分でおもた

83:デフォルトの名無しさん
07/01/10 20:51:58
forwardによる画面遷移、かつ同一ActionFormを利用する場面では
Actionの連鎖を避けるべきだが、
リダイレクトによる画面遷移がOKな場面で、
かつ両Actionクラスで同一のActionFormを使わないような場所で、
画面表示前にビジネスロジックの実行が必要な場合は
Actionの連鎖を使っても良いと思うよ。

人が否定したからと言って鵜呑みにする奴もアレだし。
Actionの連鎖がどういう動きをするのかをちゃんと理解して
使い分ければいいんじゃないかな。

84:デフォルトの名無しさん
07/01/10 21:48:24
独りよがりでやる分にはいいけど、
他人との合同開発や仕事でそんなもの出すなよ？

85:デフォルトの名無しさん
07/01/10 21:57:23
厨乙。

86:デフォルトの名無しさん
07/01/11 00:54:45
俺は、登録してから、初回の表示と同じようなことする場合に、
初回表示用のアクションに連鎖させてる。

登録アクションには登録する処理しか書いておらず、
登録後に表示されるページの情報を作る処理は、連鎖先のアクションで作っている。

87:デフォルトの名無しさん
07/01/11 01:04:20
>>86
アリだと思うよ。

88:デフォルトの名無しさん
07/01/11 01:15:19
何でもそうだけど、頭使って適切に使いこなすより、一律に同じ方法で統一しちゃう方が簡単だもんなぁ。

89:デフォルトの名無しさん
07/01/12 00:08:26
馬鹿の水準に合わせて開発すると、時間と体力ばかりくっていいこと無い

90:デフォルトの名無しさん
07/01/13 12:26:10
すいません初心者で恐縮ですが
Strutsの初心者向けの学習本で良いのありますか？

91:デフォルトの名無しさん
07/01/13 16:10:56
なんか最近、自作の俺様専用フレームワークが最強のような気がしてきた。

92:デフォルトの名無しさん
07/01/13 16:33:44
>>91
気のせい。もしくは、限定された環境でのみ最強。例えば開発者があなただけとか。

93:デフォルトの名無しさん
07/01/13 16:34:12
>>91
それは皆が通ってきた道だな

94:デフォルトの名無しさん
07/01/14 00:15:52
バリデータとコンバータが全てのFWで共通化されたら俺は平気で移る。

95:デフォルトの名無しさん
07/01/14 00:17:56
commons-validatorの事じゃなくて？

96:デフォルトの名無しさん
07/01/14 00:20:40
strutsのバリデータって他フレームワークに簡単に持って行けないもん？
リクエストパラメタをBeanUtilsとかでBeanにセットしてvalidateってできないのかな。

97:デフォルトの名無しさん
07/01/14 00:27:37
commons-varidator
commons-beanutils

あとRequestUtilsクラスとかパクりゃいんじゃねーの？

98:デフォルトの名無しさん
07/01/14 00:36:32
Webフレームワークを使う理由はバインディングしかないからね。
テンプレート機能だとか画面遷移だとかはフレームワーク作者のオナニーに付き合ってるだけ

99:デフォルトの名無しさん
07/01/14 00:38:47
便利だけどね

100:デフォルトの名無しさん
07/01/14 00:54:24
JavaのWebフレームワークを一から作るくらいならStrutsつかっときゃいーと思うがの
Strutsを使いやすいように拡張した方がな

101:デフォルトの名無しさん
07/01/14 01:45:43
オライリーのJakarta Strutsクックブックってどうですか？

102:デフォルトの名無しさん
07/01/14 01:49:45
Strusの本読んだ事ね

103:デフォルトの名無しさん
07/01/14 01:57:32
二日ほど他人のソースとテックスコアの記事読んで適当に実践に使ったから本は読んでない。

104:デフォルトの名無しさん
07/01/14 02:08:24
Ja-Jakarta Projectのページ
URLﾘﾝｸ(www.jajakarta.org)

105:デフォルトの名無しさん
07/01/14 10:00:49
>>101
あまり読んでないけど、JSTL関連の章は役に立った。
おかげでlogicタグとbeanタグからはおさらばして、Struts上でJSTLとELをフルに利用できるようになった

106:デフォルトの名無しさん
07/01/16 14:27:59
strutsって重くないですか？

107:デフォルトの名無しさん
07/01/16 14:42:45
>>105
レスありがとうございます。オライリーのサイトで目次を見ると、自分にはいろいろ
参考になることがありそうなので、買って読んでみます。

108:デフォルトの名無しさん
07/01/16 21:41:15
>>106

使わないよりは重いな

109:デフォルトの名無しさん
07/02/22 20:15:47
今回初めて使ったけどこれひどいね
Strutsタグのエラーとかstruts-config.xmlの記述間違いの際のエラーとか
のメッセージが不親切すぎてデバッグできやしない

110:デフォルトの名無しさん
07/02/22 23:03:37
ﾌﾟ

111:デフォルトの名無しさん
07/02/22 23:24:07
>>109
WTPのJSP・XMLエディター使うといいよ

112:デフォルトの名無しさん
07/03/05 00:12:36
>>109
まぁ確かに不親切だとは思うけどね。
IDEのサポートちゃんと受けてる？

転職したら秀丸でソース編集とかしている俺から見れば・・・

113:デフォルトの名無しさん
07/03/05 00:55:45
ＥＸＣＥＬファイルで定義してstruts-config.xml、validation.xml、フォームBeanを自動生成してます。

114:デフォルトの名無しさん
07/03/08 23:59:17
>>113
画面の仕様書から
バリデーションとフォームの生成まではやった。
ただしバリデーション定義はS2Strutsのアノテーションによる方式。
あれ結構自動生成と相性がいいと思う。

struts-configのExcelからの生成ってどうですかね？
いまいちもとのExcelシートのイメージができないです。

115:デフォルトの名無しさん
07/03/09 01:02:39
1ワークブック＝1モジュール
1シート＝1Form
　　　　＝1Action
　　　　＝1リソースファイル（忘れてた）
フォームの定義はValidation定義も併用
フォームBeanも自動生成
ネスとしたBeanのValidationも対応
global-exception等は別に1シート

116:デフォルトの名無しさん
07/03/09 01:03:51
要するに1ワークブック＝１struts-config.xml

117:デフォルトの名無しさん
07/03/13 01:15:23
>>116
そのExcelファイルくれ。

118:デフォルトの名無しさん
07/03/13 02:50:48
>>117
残念ながら、Excelだけではだめなのだ
自動生成ツールが必要なのだ

119:デフォルトの名無しさん
07/03/14 19:20:37
struts 2.x が正式リリースになっているな。(2/27)

だけどこのスレではぜんぜん話題になってないな。

120:デフォルトの名無しさん
07/03/14 19:29:22
>>119
Strutsって名前だけで、中身はStrutsともApacheとも何の関係もないからな。

121:デフォルトの名無しさん
07/03/14 19:58:47
たしかに　2.x は WebWork と統合、
Shale もあるし、
ひさしぶりにやる側としては、もうわけわかめです。

122:デフォルトの名無しさん
07/03/18 12:38:45
この間終ったプロジェクトじゃまだstruts1.1だったしなぁ。
またstrutsやるとしても1.x系だろうしな。2.xは手がだせんかも。

123:デフォルトの名無しさん
07/03/18 12:50:54
2.xを使ってる話なんて聞いたことがない。
2.xは元々Strutsではないから、
バージョンアップというよりまったく別フレームワークへの乗り換えになる。

1.xを使っているのなら、1.3.5はなかなか有用。
モックオブジェクトが用意されたテストケースがあったり
RequestProcessorのカスタマイズが柔軟だったり。

124:デフォルトの名無しさん
07/03/18 13:02:09
じゃあなんでsturtsなんて名前つけたんだ？

ぶっちゃけ、2.xがまったく別物ってんなら余計混乱して
そのまま「strutsｵﾜﾀ」ってなりそうな気配がﾌﾟﾝﾌﾟﾝしてるんだが…

というか、struts projectの人間は2.xが本来やりたい事だったんだ！
って言ってる様にも見えなくもないな…どのみち衰退の道か

125:デフォルトの名無しさん
07/03/18 15:08:48
strutsどころかapacheでさえないプロジェクトから移管されたものだからなぁ。2は。

126:デフォルトの名無しさん
07/03/18 16:08:32
結局フレームワーク使うとこういうことになるんだよ。
それで終わったフレームワークで作られたシステムを
新人にメンテさせる鬼先輩になるんだ、おまえらは。

127:デフォルトの名無しさん
07/03/18 16:37:37
>>126はバカだなぁ

128:デフォルトの名無しさん
07/03/18 20:05:34
>>126
独自仕様てんこ盛りの自社製FWのメンテよりはいいだろう？

129:デフォルトの名無しさん
07/03/18 21:39:10
>>128
>>126は自社製FWとかではなく、常に１から作るンだろ？
そういうほうがわかりやすいと思うヤツが多い事は事実

130:デフォルトの名無しさん
07/03/18 22:10:40
>>129
そういうのはフレームワークが古くなるどころか、
作った奴がいなくなるだけで混乱に陥る。
古かろうが、Strutsのように普及したフレームワークを使う方が
ノウハウを持った奴がどこかにいるだけまだマシ。

131:デフォルトの名無しさん
07/03/18 23:39:40
Struts1.X系でお茶を濁しつつ、JavaEE5サーバが出回ったら
JSF1.2にメインの開発は移行すればいいと思う。
GlassFishもJBossもGeronimoもベータ版が出たし、そろそろ動かせるよ

132:デフォルトの名無しさん
07/03/19 00:01:21
Glassfishは正式リリースじゃないかｗ
JBossはもうReleaseCandidate。

Tomcat6はStableリリースだから、もうJSF1.2の環境はOKだ。
でも実際はEclipseWTPやNetBeansがTomcat6対応しないと使いにくいな。

133:デフォルトの名無しさん
07/03/19 00:06:55
>>129
それわかりやすいかぁ？
作った人間いなくなったら恐ろしいことになるよ。
どうせドキュメントも残さないで消えていくんだろうし。

134:デフォルトの名無しさん
07/03/19 00:19:40
>>132
GlassFishは現在V2がリリース間近
V1はJavaEE5SDKとして出すためのものだったが、
今回はフルスペックのアプリサーバとして出す
NetBeans5.5.1でGlassFishV2に対応してる。
EclipseWTP用のPluginもGlassFish側で用意してるけど、WTPがまだJavaEE5対応してないな

135:デフォルトの名無しさん
07/03/20 01:18:21
JavaEE５なんていらねーよ

136:デフォルトの名無しさん
07/03/29 20:08:06
struts-confg.xmlの内容をエクセルに記録して
XML出力とかいうツールどっかにおちてない？
エクセルは設計書にできたらなおOK。

137:デフォルトの名無しさん
07/03/29 22:42:01
>>136
せんせーすとらつこんふぃぐがえっくすえむえるなんですがー

138:デフォルトの名無しさん
07/03/29 23:27:01
>>137
Excelで画面遷移とか定義して、そっからstruts-config.xml出力してくれるマクロとかツールが欲しいって意味なんじゃないの？

139:デフォルトの名無しさん
07/03/30 00:25:45
子ノードも無限に作れるし、属性もいくつあるかわからんし
XMLをExcelで表現するのは無理があるだろ

140:デフォルトの名無しさん
07/03/30 13:50:46
すみませんが、初歩的質問です。

Strutsの良さの一つとして、Actionクラスの存在がよく挙げられています。
Actionクラスはサーブレットよりずっと軽量なので、１つのActionServlet（の
派生クラス）と多数のActionクラス（の派生クラス）に構築されたコントロー
ラは、従来のサーブレットに比べてパフォーマンスが良い、というのです。

しかし疑問なのですが、そのActionクラスの遷移先はJSPで、そして結局JSP一
つがサーブレット一つになるのですよね？こちらのパフォーマンスは問題にな
らないのでしょうか？

なんとなくですが、JSPを使い続けているのに、コントローラだけActionクラス
を主体にしても、パフォーマンスはあんまり変わらない気がするのですが、ど
うなのでしょう？

ということで、

・従来のサーブレットのパフォーマンス
・ActionサーブレットとActionクラス
・JSP
・（JSPの代わりに）Velocityテンプレート

それぞれの実行性能をご存知の方、お教えいただけないでしょうか？

141:デフォルトの名無しさん
07/03/30 14:46:53
>>140
ActionとActionServletのおかげでパフォーマンスが向上するなんて、
聞いたこともない。出典は？
Actionクラスの目的は、Commandパターンの導入とstruts-config.xmlによる
画面遷移の宣言的制御にあるじゃなかったっけ
（それが成功しているかは別の話だが）。
この辺でも読んでみて。
URLﾘﾝｸ(wiki.apache.org)

しかし今頃になってStruts初心者か。今でも人気あるんだね。

142:140
07/03/30 15:45:56
>>141
> ActionとActionServletのおかげでパフォーマンスが向上するなんて、
> 聞いたこともない。出典は？

すみませんが、出典は分かりません。
以前にStrutsを使ったことがあって、そのときに何かで読んだのですが、1回だ
けでなく、あちこちでその内容を聞いたように思うのです。

それにしても、聞いたこともありませんでしたか。ちょっとショックです。私
の勘違いだったのかなあ。

143:デフォルトの名無しさん
07/03/30 15:58:31
基本的にフレームワークは骨組みにいろんな仕事やらせるんだから
プレーンで作るより重いよ。体感的には変わらないけど。

144:デフォルトの名無しさん
07/03/31 00:42:23
Actionの存在が良さとは思わんが・・

俺が思うStrutsの良いところは・・
・HTTPパラメータがActionFormとして明確になる
・画面遷移とコントローラの依存が疎になる
ぐらいだと思う。

パフォーマンスが良くなるなんて聞いたこと無い。

145:デフォルトの名無しさん
07/03/31 03:29:56
>>142
完全な勘違いだよ。
ActionServletやらで色々な処理が間に入っているんだから
素でServletを書くより早くなるわけないじゃん。

といってもこの程度のオーバーヘッドでパフォーマンス云々語るのは
かなりアホなことしゃべってると思った方がいいよ。

146:デフォルトの名無しさん
07/03/31 03:52:13
>>142
あちこちで聞いたって職場でかい？
ちょっと身の振り方考えた方がいいんじゃないかね。

揶揄して言ってるんじゃなくて
そんな一笑に付されるような俗説がまかり通るってのは
全体のレベルが低い証拠だと思う。
自分の今後にとってもプラスにならないよ。

147:140
07/03/31 19:41:57
どうもお恥ずかしい話ですみません。私の勘違いだったようです。社の人から
聞いたのではなく、雑誌かWEBの記事だったと思うのですが、誤読したのでしょ
う。

しかし、実行速度は下がるにしても、他のメリットは無いのでしょうか？
サーブレットに比べてアクションクラスは

・インスタンス生成のコストが小さい
・メモリの占有量が少ない

という特徴があったりしないでしょうか？
もしあるとしたら、たぶんそういう記事を私が誤解したのだと思うのです。

まあ実質的にはメリットに上げるほどの差ではないのかもしれませんが。

148:デフォルトの名無しさん
07/04/01 00:53:58
>>147
あるとしても、鼻毛抜いてダイエットするくらいの効果しかない。
HttpServletの実装はコンテナ依存なので、ひょっとしたらActionとの差が大きくなる
コンテナがあるのかもしれないが…HttpServletの実装が重いコンテナなんてヤダ。
というか、仮に軽くなっても、struts-config.xmlやvalidator.xmlをメモリに展開する分、
別の分でメモリ食ってるはず。

ま、世の中には、無意味または時代遅れなバッドノウハウを語る低脳ライターが割といるので、
そういう連中の記事を読んだんじゃないかと思う。
「メソッドにfinal付けて高速化」とか、「同じローカル変数を使い回してメモリ使用量を削減」とか言う奴と一緒。
最近笑ったのはこれ。
URLﾘﾝｸ(www.atmarkit.co.jp)
ライターなんて、下はこの程度ですよ。

149:デフォルトの名無しさん
07/04/01 01:05:37
>>148
これはひどいｗ

150:デフォルトの名無しさん
07/04/01 01:09:12
>>148
こ、これは・・・

こんな糞記事で原稿代もらえるのか・・・
俺も何か書こうかな。。。

151:デフォルトの名無しさん
07/04/01 19:49:01
>>150
期待してるぜｗ

152:デフォルトの名無しさん
07/04/08 20:42:52
>>148
ちびった・・・ｗ

153:デフォルトの名無しさん
07/04/08 21:01:18
きょ，今日先輩から聞いたんだけど，
int型使うよりもbyte型使った方が速くなるらしいぜ．
DBのテーブルサイズ見積もりなんかはやったことあるけど，
変数のサイズ見積もりなんてやったことなかったけど，
これからはきちんと考えて設定しなきゃなぁ．．．

154:デフォルトの名無しさん
07/04/09 02:50:26
>>153
ネタだと言ってよ、バーニィ！

155:デフォルトの名無しさん
07/04/16 05:49:16
>>154
0080だっけか？

156:デフォルトの名無しさん
07/04/27 11:50:18
終わったな

157:デフォルトの名無しさん
07/06/05 23:23:21
クラスSuperClassを継承したクラスSubClassがあって、
SuperClassで定義したpublicなメソッドgetXxx()があります。
そのgetXxx()についてですが、
以下のようなJSPでアクセスできないのですが、何か勘違いしてますか？
<%-- subClassObjはSubClassのインスタンス --%>
<bean:write name="subClassObj" property="subClassObj.xxx"/>

SubClass内でgetXxx()をオーバーライドすれば正常に表示できることはできるのですが…

158:デフォルトの名無しさん
07/06/06 14:14:48
>>157
オーバーライドする以前に
サブクラスのインスタンスにスーパークラスのメソッドが
あるかどうかくらいリフレクション使って確認したかい？

ヒントはこれだ
Class clazz = Class.forName("java.lang.String");
Method[] method = clazz.getMethods();

後は分かるな？

159:デフォルトの名無しさん
07/06/07 07:32:30
>property="subClassObj.xxx"
xxxだけでいいんじゃないの？

160:デフォルトの名無しさん
07/06/14 22:52:32
国際化しない場合でもメッセージリソースつかってる？
メリットってなんかある？

161:デフォルトの名無しさん
07/06/15 00:17:37
>>160
JSP内のハードコードを防げる。

162:デフォルトの名無しさん
07/06/15 00:22:03
JSPの中のスクリプトレット撲滅運動中です．
代わりにVelocityでテンプレートをうわなにをするはなｓ

163:デフォルトの名無しさん
07/06/15 00:26:17
JSPの中のスクリプトレット排除にVelocityって、メリットなさすぎ。
#ifとか入るし。

164:デフォルトの名無しさん
07/06/15 01:03:18
まわりまわってスクリプトレット最強説。
StrutsタグもVelocityもJSTLも可読性を下げてるだけ。

165:デフォルトの名無しさん
07/06/15 02:28:31
デザイナなしで少人数で作るなら、それもありかもわからんね。

166:デフォルトの名無しさん
07/06/15 11:37:40
デザイナにとってはHTML以外の
変なタグや#が入ってる時点でわずらわしさは全部同じでしょ。
だったらスクリプトレットでいいよ

167:デフォルトの名無しさん
07/06/15 11:53:11
いや、faceletやmayaaみたいにspanとかdivでできれば、オーサリングツールで読み込んでも崩れないし表示確認もやりやすいから、同じではないよ。

168:デフォルトの名無しさん
07/06/16 13:29:48
Servlet の小規模開発案件があるのですが、フレームワークを使うとしたら Struts が最強ですか？

169:デフォルトの名無しさん
07/06/16 15:36:55
>>169
本当に小規模なら、
JSON-RPC-Java(Ajax) の方が楽かも

業務ロジック(画面切り替え)は、javascript で全部やる。
DBアクセスは、サーバ上のMiddlegenで作ったDAOを
ブラウザ上のjavascriptからキックしてやる感じ。

今自分がJ2EEで一定の規模の開発を任されたとしたら
やっぱり Struts1.3+Xdoclet かなぁ・・・
（要員スキルとか、治具(自動生成)とか、ノウハウとかの関係で）

170:168
07/06/16 16:00:59
>本当に小規模なら
２人月ぐらいの規模です。

171:デフォルトの名無しさん
07/06/16 17:00:04
>>168
Struts1オンリーでいいよ。
>>169なんてぜんぜん小規模だと思えない。
おまけにモバイル対応したら画面遷移のロジック全部書き直し。

172:デフォルトの名無しさん
07/06/16 17:22:44
業務アプリでモバイル対応もないなら、JSFの方が楽。
Strutsを使ったことがないなら、JSFにしたほうがいいと思われ。

173:デフォルトの名無しさん
07/06/16 17:24:58
NetBeans + Visual Web Packも検討に値すると思うよ。

174:デフォルトの名無しさん
07/06/16 20:28:17
サーブレットも知らない奴がWebアプリのサブシステム開発のリーダーってどういうこと？

175:デフォルトの名無しさん
07/06/16 21:58:04
じゃあお前やれよ

176:デフォルトの名無しさん
07/06/17 01:10:20
>>166
スクリプトレットなんて許したら死ぬほどコード書きまくられるぜ？
後で地獄見るだけだ。

テロリストは1歩譲ったら100歩踏み込んでくる。

177:デフォルトの名無しさん
07/06/20 12:34:28
sslext使ってて困ったことが起きたのだけれど、
sslext:link でリンクすると、リンク先がlocalhostになってしまう。
何が問題なのかわかる人いますか？

自分でやった変更は、server.xmlの
<engine defaultHost="mokuteki.host.jp" …>
<host name="mokuteki.host.jp" …>
ですが、これでもlocalhostのままでした。

178:デフォルトの名無しさん
07/06/25 10:46:10
Strutsなんて死んでるし、新規プロジェクトで選択するのはまず間違い

179:デフォルトの名無しさん
07/06/25 12:59:23
>>178
じゃあ、何を使うのがいい？

180:デフォルトの名無しさん
07/06/25 18:08:16
JSFかなあ

181:デフォルトの名無しさん
07/06/26 05:55:25
業務アプリならJSFだね。
新規でStrutsを、XML手書きでやらせるプロジェクトはダメプロジェクト。

182:デフォルトの名無しさん
07/06/26 10:09:51
結局変なタグ書かせるJSFもいらないだろ

183:デフォルトの名無しさん
07/06/26 11:23:42
ていうかwebアプリが糞

184:デフォルトの名無しさん
07/06/26 13:30:09
よくしらないんですが Jakarta Commons って、フレームワークではないの？

185:デフォルトの名無しさん
07/06/27 00:08:44
違います。

186:デフォルトの名無しさん
07/06/27 01:34:02
プログラムを呼ぶのがフレームワーク
プログラムから呼ばれるのはユーティリティ

187:デフォルトの名無しさん
07/06/27 02:54:54
というか、Commonsはプログラムですらない。共通ライブラリを集めたプロジェクトの名前

188:デフォルトの名無しさん
07/06/28 22:22:45
こういう場合みんなどうやってるか教えて。

１．編集画面を表示する。
　今登録されている情報はＤＢから取得してデフォルト表示されている。

２．編集しようとするとValidationエラーとなる。

この場合、１で取得した今登録されている情報をSessionに入れておかないと
Validationエラーで同じ画面に遷移したときにエラーとなります。
Sessionに入れるのが普通？

189:デフォルトの名無しさん
07/06/29 00:19:14
基本的にいま入力した情報しかいらないだろ。

190:デフォルトの名無しさん
07/06/29 00:30:38
hidden使ってデフォルト値を受け渡しすればいいんじゃないのか？

191:デフォルトの名無しさん
07/06/30 02:02:00
>>188
ActionFormでvalidateをやらない。
Action側で独自にvalidateをやり、エラーの場合、必要な値をDBから再度取得して編集画面に戻る。
…なんか破綻しているな。

192:デフォルトの名無しさん
07/06/30 09:43:12
>>190

それもいいですね。
ただ、ドロップダウンリストに表示するものは厳しいかも。。

>>191

それもありかもしれない。

193:デフォルトの名無しさん
07/06/30 09:49:38
dynaactionformって普通は使わないものですか？

194:デフォルトの名無しさん
07/06/30 09:55:59
なにこの活況ぶり

195:デフォルトの名無しさん
07/06/30 11:52:54
JAVA+JSP+Struts+Tomcatスレがなくなったから？

196:デフォルトの名無しさん
07/06/30 15:14:48
>>193

俺は使わないルールにしてる。わかりにくいから。

197:デフォルトの名無しさん
07/06/30 15:23:06
使うメリットがあまりない

198:デフォルトの名無しさん
07/07/01 11:14:49
struts1.2はJavaでWEB構築した際のスタンダードとして
今後10年は使われると言ってみるテスト

199:デフォルトの名無しさん
07/07/01 13:39:30
否定できんな・・・
10年はともかく5年は・・・

200:デフォルトの名無しさん
07/07/01 13:44:24
すでに作ったもののフレームワークが変更されることはないだろうな。

201:デフォルトの名無しさん
07/07/01 13:57:13
新規の基幹システムですとらっつ＆ＥＪＢ２とはこれいかに？

202:デフォルトの名無しさん
07/07/01 15:52:31
にげて～～

203:デフォルトの名無しさん
07/07/01 20:26:27
今から作るならStruts２がいい？

204:デフォルトの名無しさん
07/07/01 21:55:42
Struts2全然情報ないな

205:デフォルトの名無しさん
07/07/01 22:06:44
>>201
どっかのstrutsベースの独自フレームワーク強制されるよりマシ

206:デフォルトの名無しさん
07/07/01 22:13:26
そのどっかのＳｔｒｕｔｓベースの独自フレームワークなんですが・・・・

207:デフォルトの名無しさん
07/07/01 22:52:53
>>206
まあ、それも仕事だ！
独自ルール覚えるのが面倒なんだよな。
（中途半端なGUIツールがあったりするとうざいんだこれが。）
早め理解して、気に入らない点があっても受け入れるしかあるまい。

どうしても使い勝手が気に食わなければ、
スクリプトやエディタのマクロなんかを使って、
いかに快適に糞フレームワークを使うかを考えたりすると、精神衛生上良かった。俺の場合はｌ。

208:デフォルトの名無しさん
07/07/02 00:21:38
>>201
Strutsはともかく
EJB2というあたりに腐臭を感じるな。

ステートレスSessionBean？
ならわかるかな。

209:デフォルトの名無しさん
07/07/02 00:37:40
CMPも使うと言っています・・・
IB○の（ry

210:デフォルトの名無しさん
07/07/02 01:17:11
>>209
お前、あのプロジェクトか！？

211:デフォルトの名無しさん
07/07/02 01:49:34
>> 203
今から作るなら、Webアプリじゃなくデスクトップでやるのがいいな。
Ajaxとか面倒で生産性のないことやるより楽だし顧客の要望にこたえやすい。

212:デフォルトの名無しさん
07/07/02 19:57:26
>>2111

ねーよｗ

213:デフォルトの名無しさん
07/07/02 20:41:12
デスクトップに比べてWebアプリのメリットはなに？
デスクトップならすぐできることを、Webアプリだと工数がかかる。
それを上回るWebアプリのメリットってあるのか？

214:デフォルトの名無しさん
07/07/02 21:07:14
東京でも大阪でも外国でもモバイルでも触れる。

215:デフォルトの名無しさん
07/07/02 22:46:43
>>213
配布不要。ブラウザひとつで動かせる点。
Java Web Start？あれアプリ起動するのに、
更新チェックとかするから、結構時間かかるんだよな。

216:デフォルトの名無しさん
07/07/02 22:57:50
＞デスクトップならすぐできることを、Webアプリだと工数がかかる。

ＪＳＦ辺りだと「Webならすぐできることをテスクトップだと工数がかかる」って
ノリだと思うが。

まあ、所詮はフレームワークなんでフレームワーク以上の事をやろうとすると
途端に辛くなるのはあるがな。

217:デフォルトの名無しさん
07/07/02 23:00:12
ビジネスアプリは
何でも出来りゃいいって言う
わけではない

218:デフォルトの名無しさん
07/07/18 11:05:44
Strutsで
URLﾘﾝｸ(hoge)
でアクセスした場合、下記のStruts-configで設定した場合
URLﾘﾝｸ(hoge)
といった具合にjsessionidが丸見えになってしまいます。
その後は消えてくれるのですが一発目が出てしまいます。
これを一回も出ないようにするにはどうしたらよいでしょうか？
クッキーが使えることが前程ですが。
よろしくお願いいたします。

<global-forwards>
<forward
name="login"
path="/login.do"/>
</global-forwards>

219:デフォルトの名無しさん
07/07/18 15:42:12
それはStrutsではなくて、サーブレットコンテナの仕業かと。

220:デフォルトの名無しさん
07/07/18 22:57:06
>>218
丸見えって誰に？

次ページ