△△もっとStrutsの良さを教えてくださいSession5at TECH
△△もっとStrutsの良さを教えてくださいSession5 - 暇つぶし2ch1:デフォルトの名無しさん
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
世の中の流れに乗る=教育コスト、学習コストの削減には一概にはならん
そういう短絡的発想が遺憾といっているw

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

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

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

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

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
いかにも残業したり休日出勤したりするのがこの世界の常識って考えのヤツの発想だなw

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

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

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

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

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

23:デフォルトの名無しさん
06/12/31 20:54:14
みなさんが、Strutsプロジェクトに携わったのは何件ですか?
私は、前に1回だけ...
正直な話、初めて見た時、何故これで動くのか訳がわからなかった
(この当時、本でもネット上でもあまり詳しい説明されてるやつがなかったし、っていうか見つからなかったし)
「なんで普通に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は便利ではないw。
学習コストに見合わない生産性の低さに泣ける。
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は生産性が高いので、開発コストを減らした分の金で
元は十分以上に取れる。というかハードなんて人件費に比べれば安いし。


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

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

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

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がほったらかしなんだか判らんw

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パターンだからと思って、最近は1URL1Actionにしている
以前は1画面毎に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
EXCELファイルで定義して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ワークブック=1struts-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とかではなく、常に1から作るンだろ?
そういうほうがわかりやすいと思うヤツが多い事は事実

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は正式リリースじゃないかw
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
JavaEE5なんていらねーよ

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クラスはサーブレットよりずっと軽量なので、1つの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
これはひどいw

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

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

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

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

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でテンプレートをうわなにをするはなs

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
>本当に小規模なら
2人月ぐらいの規模です。

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
こういう場合みんなどうやってるか教えて。

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

2.編集しようとするとValidationエラーとなる。

この場合、1で取得した今登録されている情報を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
新規の基幹システムですとらっつ&EJB2とはこれいかに?

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

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

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

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

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

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

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

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

ねーよw

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アプリだと工数がかかる。

JSF辺りだと「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
丸見えって誰に?

221:デフォルトの名無しさん
07/07/21 12:46:54
logic:iterateでトラブルにはまってしまい抜け出せません

<logic:iterate id="item" name="result" property="list" indexId="index">
<bean:write name="item" property="fee" />
</logic:iterate>

上記のようなJSPを書くと、
javax.servlet.ServletException: どのスコープにもBean item がありません
というエラーを返します。目の前で定義しているのに…

ちなみにiterateされるlistは全部で3つあって、
<bean:write name="item" property="fee" />

<bean:write name="index" />
に変更すると、きちんと0,1,2と表示されます。

このエラーが起こりうる心当たりがあるかた、解決の微かなヒントでもいいのでお願いします

222:デフォルトの名無しさん
07/07/21 17:30:51
>>221

result#getList() が無いとか・・・

223:デフォルトの名無しさん
07/07/22 12:17:48
>>222
色々調べてみましたが、情けないエラーでした。
具体的には、getList()が返すのはサイズ3の空配列で、
内容はなにもなかったのです。

そこはnull pointer exception出して欲しかった。
助言ありがとう

224:デフォルトの名無しさん
07/07/22 15:10:21
無設定struts使えば、Strutsもつかえる。

225:デフォルトの名無しさん
07/07/25 22:53:48
全く前知識なしで1から触ったが、jsp表示してDBアクセスjsp転送までに
丸1日かかったぞ。
struts-config.xml,web.xmlはともかく、
最初、最新版がいいとおもって2.xダウンロードしてしまって
tldがない、はてな???になってしまった。
1.29でなんとかなったが、問題多発だ。
ベリゲータ入れるつもりだけどまた大変なことになりそうだorz


226:デフォルトの名無しさん
07/07/25 22:56:40
なんか・・・バージョンによって変な不具合とかバグぽいのもあるし、
自分の触り方がおかしいのかstruts自体がおかしいのか。
バグの上にバグを築いてるようで精神が折れるorz

227:デフォルトの名無しさん
07/07/26 00:54:23
1系は安定してるだろ。バグっぽく見えるのは
フレームワーク全体にいえるんだけど初心者に扱いやすくできてないため。
よくみんなこんなの使うよな。

228:デフォルトの名無しさん
07/07/26 06:37:37
と言うかフレームワーク使う人はある程度servlet+JSPを理解してから
使うモノだと思うが。

たとえJSFでも、その壁が気持ち下がるくらいだし。

229:デフォルトの名無しさん
07/07/26 10:03:59
Tomcatで開発中のプロジェクトをWebLogic9.2に移動してみたのですが
styleIDのところで
「この属性は認識されません。」
というエラーが発生しています。
ただstyleId自体が固定文字列のところは問題ないようなので
下のように可変文字列を出力しているところが問題なようです。

<html:hidden name="hoge" property="type" indexed="true" styleId="<%= "hoge"+ index.toString() %>"/>

同様の問題を解決されたことのあるかたがいましたら
ご教示願えますでしょうか?
よろしくお願いいたします。

230:デフォルトの名無しさん
07/07/26 13:05:13
サーブレットメインでやってるときはstrutsの有り難みが今一だったが、
Struts使えばアップロードが簡単にできると知ってからそれが10倍化した。

231:デフォルトの名無しさん
07/07/26 18:45:17
Strutsはゴミ

232:デフォルトの名無しさん
07/07/26 23:54:54
>>229
カスタムタグの属性のとこにスクリプトレットだの
bean:writeだので値埋め込もうとしても駄目じゃないの?
↓こういう風に書いてもエラーになるよね。
<html:hidden property="honwaka" value="<bean:write name="hogehoge" property="value"/>" />

>ただstyleId自体が固定文字列のところは問題ないようなので
>下のように可変文字列を出力しているところが問題なようです。
なんかもう答えが出ているような気がするけど。

233:デフォルトの名無しさん
07/07/27 01:33:57
>>225
もう結構前からTLDはいらんだろ。

234:デフォルトの名無しさん
07/07/27 01:34:33
>>230
commons-upload使えばいいだけの話じゃね?

235:デフォルトの名無しさん
07/07/27 07:22:25
>>232
ありがとうございます。

Tomcatでは問題ないのでWebLogicの設定かもと調べていたら
WebLogic.xmlにJSPのコンパイル設定があるみたいなので
調べてみたいと思います。

キーワードはrtexprvalueみたいです。

236:デフォルトの名無しさん
07/07/27 08:24:30
>>235
え・・・Tomcatでは動くの???
というかJBossだろうがWebSphereだろうが絶対駄目と思うんだけど。。。
最近SwingばっかりでJSP全然触ってないから頭がぼけてるのかもしれないけど。

・・・とか思ったらできるのかな、これ。
俺ならスクリプトレットなんて真っ先に禁止するけど。
百害あって一利なしだよ、あんなの。
URLリンク(www.javaroad.jp)

そもそもStrutsのtld自体をいじるのはおすすめしないけどなぁ。

↓WebLogicでこんなのあったけど、
これってWebLogic固有設定っぽいし、
あんまり使わない方がいいんでないの?
URLリンク(edocs.beasys.co.jp)

237:デフォルトの名無しさん
07/07/27 08:29:35
>>236
自分も本当は嫌なんですけど
そうするとstyleIdに連番をふる方法が他にありますでしょうか?
もしあるなら使いたいです。

238:236
07/07/27 08:39:44
カスタムタグの中に別のタグがあるような書き方はできないはずなので
スクリプトレットも当然駄目かと思ったけど、
TLDの設定で変えられるんだね。動かしてないから知らんけど。

(1)スクリプトレットの式を評価して
(2)その値をタグハンドラクラスの指定のフィールドにセットする...

と考えるとできるっちゃできるか。

ただ、スクリプトレットをJSPにゴロゴロ書き出すと
真似する奴が出て大変なことになると思うよ。
コーディング規約とかで禁止されていない?
割り切って使うならいいかもしれないけど。

>>233
え・・・いらなくなったんですか???
それは初耳だな~Swingとかもう飽きた・・・
WEBアプリの方が楽でいいから戻りたいです。

239:236
07/07/27 08:42:02
>>237
Struts-elを使うか、
カスタムタグを自分で作る・・・
Strutsのタグクラスを継承してtldをちょいちょい書くだけなので
意外と簡単だよ。
自分は後者の方でやった。

他にいい方法って逆にありますかね。。。
というか株を見ながら書いていたらこんな時間なので仕事逝ってきます。

240:デフォルトの名無しさん
07/07/27 10:05:06
解決しました。

<html:hidden name="hoge" property="type" indexed="true" styleId='<%= "hoge"+ index.toString() %>'/>

としたらTomcatでもWebLogicでも動作しました。
なぜだかよくわかりませんが・・・

weblogic.xmlではうまくいきませんでした。

241:236
07/07/28 01:22:59
>>240
年のせいか触ってないとすぐに忘れる・・・
俺もかなり適当なこと書いてるっぽいけど
もうちょい自分が何やってるか理解しようとする意思を持った方がいいよ。

嫌な言い方するようだけど
JSPなりカスタムタグなりがどうやって動いているのか
全然理解してないし理解しようともしてないでしょ。
俺はこういうのは気になって放置できない。

242:デフォルトの名無しさん
07/07/28 12:30:24
Strutsタグは使わないことにしました。

243:名無しさん@そうだ選挙に行こう
07/07/29 16:19:01
ところで、
ActionFormのreset()って、ページ遷移時と
submitなどが押されたあとももう1回呼ばれるよね。
これって・・・
駄目では。

244:名無しさん@そうだ選挙に行こう
07/07/29 19:34:39
236氏いい加減なこと書きすぎ。
えらそうなこと書きたいならJSP仕様を勉強し直してからにして。
スクリプトレットと実行時式の違いとかカスタムタグ仕様とか。

245:名無しさん@そうだ選挙に行こう
07/07/29 19:35:37
>>243
kwsk

246:デフォルトの名無しさん
07/07/29 21:18:09
フォーム有りページに遷移→ActionFormのreset()でフォームが初期化される

フォームに値を入力してsubmitする→なぜかまた同じActionFormのreset()が呼ばれて初期化

247:デフォルトの名無しさん
07/07/29 22:59:05
それはそういう仕様。
resetメソッドのところの説明をよく読め。

248:デフォルトの名無しさん
07/07/31 19:34:33
仕事でstruts勉強する必要ができたんだけど
一番分かり易い説明と要点の書いてあるサイトを教えて下さい。

249:デフォルトの名無しさん
07/07/31 19:37:49
Strutsってなんであんな使い辛い仕様なんだろう
今時WEB案件でjavaとか馬鹿じゃねーのと思う


250:デフォルトの名無しさん
07/07/31 19:52:45
たしかに、もう何十人の派遣ばっかの烏合の衆でシコシコと大型サイト組むような次代じゃないのかもね
でも次候補にきそうなPHPもなんだかJavaと手間が変わらなくなってきてるしRubyはありえないし、、
模範的なWEB案件ってないもんか

251:デフォルトの名無しさん
07/07/31 20:10:23
Strutsがいいかどうかは別としてJavaが一番作りやすいよ
PHPとか中途半端にオブジェクト指向取り入れて死んでるよ

252:デフォルトの名無しさん
07/07/31 21:13:34
JavaはServletクラスの設計からしてクソだからな。
Strutsはクソの上に積み上げたクソに過ぎない。

253:デフォルトの名無しさん
07/07/31 21:16:05
じゃばじゃば言ってる奴はダサいよな

254:デフォルトの名無しさん
07/07/31 22:27:55
じゃあ、何が良いの?

255:デフォルトの名無しさん
07/07/31 22:59:52
まずロジックをHttpServletやHttpServletRequestから完全に切り離すことだろうな。
入力の検査・加工ルールと、出力の整形・加工ルールを外部ファイル化できていればさらにいい。

256:デフォルトの名無しさん
07/07/31 23:12:50
HTML出力に限ればVelocityが良さそうに見えたが、テンプレート側に文字列の加工を連続して書けないのが難点だったな…。
たとえば「小数点2桁で切り捨ててカンマで区切ってからエスケープ処理したい」みたいなときに
テンプレート側にスマートに書けないと、Java側のコードがどんどん膨れて困る。

257:デフォルトの名無しさん
07/07/31 23:14:11
いや、それじゃロジックとviewを分離する意味ないじゃん・・・

258:デフォルトの名無しさん
07/07/31 23:23:21
ん?
値をセットするのと、フォーマットして表示するのは別だろ?


259:デフォルトの名無しさん
07/07/31 23:37:38
本来、JavaがHTMLエスケープまで面倒見るのはおかしいんだよ。
出力がHTMLであることを定義するのはビューなんだから、ロジックとは無関係なフォーマットや
HTMLエスケープはビューがやらないと、それこそビューと分離できなくなるでしょ。

260:デフォルトの名無しさん
07/08/01 10:36:14
いまからやるならJSFでいいじゃない

261:デフォルトの名無しさん
07/08/01 10:37:23
HTMLでしか表示しないのに、設計的に美しいからと変な手間を増やすのがJava厨クオリティ

262:デフォルトの名無しさん
07/08/01 11:52:32
まだPHP4が出だした頃にjavaもやりはじめて、
jspのエラー画面でスタックトレースの階層具合を見た時は轢いたな。

いまとなってはどうでもいいけど。

263:デフォルトの名無しさん
07/08/01 21:18:12
ぶっちゃけJSPでいいじゃんって最近おもう。

264:デフォルトの名無しさん
07/08/01 21:37:56
さすがに、それはない。

265:デフォルトの名無しさん
07/08/01 21:48:47
いや普通にJSPでいいだろ。何がダメなのかわかんない

266:デフォルトの名無しさん
07/08/01 21:48:58
そもそもなんのためにjavaあるの?意味なくない

267:デフォルトの名無しさん
07/08/01 22:05:07
XHTMLってDreamWaverやHomepageBuilderで作れる?
作れるならPOHP系に落ち着いて欲しいな。言語を選ばなくなるし。

268:デフォルトの名無しさん
07/08/01 22:39:34
>>266
そもそも何のためにVBが(ry
そもそも何のためにRubyが(ry
そもそも何のためにC#が(ry

ということで、そんな意味のないことを書くな。

269:デフォルトの名無しさん
07/08/01 23:05:30
>>268
ここまで使うメリットのない言語も珍しいだろ
javaの利点ってなにさ

270:デフォルトの名無しさん
07/08/01 23:12:39
煽るためだけに聞いてるような頭の悪いレスにしか見えん。
ああ、夏休みか。

271:デフォルトの名無しさん
07/08/01 23:12:47
誰も喪前にjavaを使ってくれなんていわないワケだが。

272:デフォルトの名無しさん
07/08/02 05:11:10
>>269
ここまでマジレスするメリットのないレスもめずらしいな。

273:デフォルトの名無しさん
07/08/02 08:03:33
ストラッツで作ったwebアプリで
ブラウザの戻るボタンで 戻れないのは、
どうしてる?

注意書でブラウザの戻るボタンは押すなって
書いてあるとこもあるけど
それは避けたいんだよな。

274:デフォルトの名無しさん
07/08/02 21:11:04
JavaScriptで制御してるな



275:デフォルトの名無しさん
07/08/03 07:14:10
最初からメニューを消しておけば問題なし。
ついでに右クリックも禁止してしまえ。
ふはははは。

276:デフォルトの名無しさん
07/08/03 08:30:17
>>275
つBack Space

277:デフォルトの名無しさん
07/08/03 10:08:18
そもそも戻れないって作り方の問題じゃね?

278:デフォルトの名無しさん
07/08/03 10:30:48
戻られて困るようなサイト、Strutsを使うまでもないカスだ

279:デフォルトの名無しさん
07/08/03 10:53:00
画面遷移をすべてRedirectで行えばよい

280:デフォルトの名無しさん
07/08/03 12:35:47
Struts1.2と1.3、実際に現場ではどちらのほうがより使われている?
各種ツールの対応状況の都合で未だに1.2という話も聞くが実際にはどうだろう?

それから、Struts使う場合でもlogicタグを使うケースと
その部分だけはJSTLを使うケースはどちらが多い?

281:デフォルトの名無しさん
07/08/04 17:15:18
1.3に上げるメリットがよくわからないし、2.0もあるしな

taglibについては、以前のStruts開発ではJSTLを使った。
Strutsタグはhtmlタグ以外は使わなかった

282:デフォルトの名無しさん
07/08/04 17:42:47
分かりやすくstruts解説したサイト教えて

283:デフォルトの名無しさん
07/08/04 22:23:29
絶対JSTLの方が楽だと思うけど、
「今までlogicタグ使ってたから」という理由でlogic、beanタグを使うことが多い。

struts-html以外は、JSTLを使うのがベスト

284:デフォルトの名無しさん
07/08/04 22:44:26
2.0系は別物だからStruts以外のフレームワークも含めた別の観点からの議論が必要。

1.2.xで作ったモノを1.3.xへ上げる理由はないけど
新規開発ではどう?1.3があるけどそれでもなお1.2を使う?

理想論とか「あるべき」論ではlogicやbeanタグは使わずにJSTLがベターなのはわかりきっているが
実際の開発現場ではどうなの?

285:デフォルトの名無しさん
07/08/05 10:02:20
おまえらどこでstruts勉強したの?

286:デフォルトの名無しさん
07/08/05 11:45:26
>>284
1.3に上げてもものすごいメリットがないからなあ
保守を考えると全部1.2で同じ作りにしてあった方が楽なので、
うちは今のところずっと1.2
beanやlogicはJSTLに置き換えつつあるかな。でもlogicタグしか分からない外注さんも
多いから混ざってる
>>285
本家のstruts-examplesとUser Guideを見ながら。本は買ってない

287:デフォルトの名無しさん
07/08/05 12:21:16
カスタムタグは使わないほうがいい

288:デフォルトの名無しさん
07/08/05 14:48:26
>>287
なんで?

289:デフォルトの名無しさん
07/08/05 15:43:07
>>286
分かり辛いだろ、
分かり易く書いてあるサイトとかなかったの?


290:デフォルトの名無しさん
07/08/07 12:39:33
やる気の問題だな

291:デフォルトの名無しさん
07/08/08 22:55:00
やる気なんかないから
分かりやすいのが欲しいんじゃね

292:デフォルトの名無しさん
07/08/12 13:44:17
スクリプトレットにならないだけでもstruts使う価値あり
veligateとかtablib:logicとかtaglib:beanとか

と、非strutsのソースみて思いました。
JS関数の中にjavaコード埋め込んであったり、もう酷かった。


293:デフォルトの名無しさん
07/08/12 15:01:14
JSTLで十分かと。

294:デフォルトの名無しさん
07/08/12 16:30:00
最近GWT使うようになってStrutsいらなくなったと感じる

295:デフォルトの名無しさん
07/08/12 17:27:00
>>286
同意。

現在の技術者の多くや、情報源の大部分はStruts1.2ベースだから、
1.3や2.0によっぽどのメリットがない限り、保守性、生産性を考慮し、
1.2を採用すべきと考えてる。

それでも1.3や2.0を採用する価値があるか逆に聞きたい。
まぁ、1.3や2.0のこと全く知らないんだけど…


296:デフォルトの名無しさん
07/08/22 21:12:40
>>295
2.0は俺も知らんけど、1.3のメリットなら

処理の割り込みをカスタマイズするのが非常に楽。
たとえば、Actionのexecute()の呼び出し直前/直後に行いたい処理を割り込ませるとか。
アプローチはCommonsChainでAOPじゃないのがイマドキじゃないけど・・・
あとは、ユニットテスト用のモックが提供されているとか、
Validatorや例外処理のリソースバンドル分割に対応しているとか
URLバリデータが賢くなったりとか。


297:デフォルトの名無しさん
07/08/24 22:31:24
Actionがインスタンス化されるときのメソッドって何ですか?

298:デフォルトの名無しさん
07/08/25 01:06:47
1.3.8、なんで45MBもあるの?

299:デフォルトの名無しさん
07/08/28 23:34:30
Struts1.3で質問です。

JSPで表示が同じ複数のボタンを配置して、
サーブレットでどのボタンが押されたか判定したいんですが、
どうすればいいでしょうか?

別にStruts使わなくても構いません。

300:デフォルトの名無しさん
07/08/29 00:04:00
>>299
EventDispatchActionを使うと吉。

301:デフォルトの名無しさん
07/08/31 01:54:22
>>299
私はずっとLookupDispatchActionを使ってきました。
URLリンク(struts.apache.org)

#SpringFrameworkと連携させることが多いので実際はLookupDispatchActionSuportですが。
URLリンク(www.springframework.org)

302:299
07/09/01 21:37:01
>>300
>>301
遅くなってすいませんが、どうもありがとうございます。
ちょっと見てみます。

303:デフォルトの名無しさん
07/09/12 17:16:55
2004年ごろ閉鎖された「有限会社エヌアイティー技術情報部」というサイトが
ありました。そこでは、Strutsのドキュメントなどが精力的に翻訳されていま
した。
URLリンク(web.archive.org)
URLリンク(web.archive.org)

これだけ大量の翻訳を、どうやら管理人氏一人でやっていたようです。

きのう、ここの移転先を見つけました。
URLリンク(www.geocities.jp)
URLリンク(www.geocities.jp)

断言はできませんが、お亡くなりになっていたように見えます。お世話になり
ました。合掌。


304:デフォルトの名無しさん
07/09/21 23:02:37
なあ、今strutsの本読んだんだけどさ、
素のサーブレットと手間変わんなくない?

これじゃ使う意味ないよね。

305:デフォルトの名無しさん
07/09/21 23:20:16
>>304
もっといいもの作ってよ、期待してる

306:デフォルトの名無しさん
07/09/22 00:14:00
>>304
そう思うってことは、勉強が足りんよね。

307:デフォルトの名無しさん
07/09/22 04:28:22
>>304
素のサーブレット書くよりは数倍楽だと思うけど。

308:デフォルトの名無しさん
07/09/24 16:05:13
派遣とかの現場でもstrutsってもう終ったの?

309:デフォルトの名無しさん
07/09/24 16:56:31
むしろ、JSFほか別のフレームワークがはじまってないので、Struts一色

310:デフォルトの名無しさん
07/09/24 17:56:13
うちは4年前からturbine(velocity + torque)

311:デフォルトの名無しさん
07/09/24 19:10:42
URLリンク(d.hatena.ne.jp)

312:デフォルトの名無しさん
07/09/24 19:51:55
ひがたんも賢いスーツ側の人間だからなぁ。
しーさーがうまくいかなそうだったら逃げるのかい?

313:デフォルトの名無しさん
07/09/24 22:23:56
Struts はなんだかんだいって見通しがいいのと
実績があるのもあって総合力は高いよね。


314:デフォルトの名無しさん
07/09/25 17:30:31
うちは去年からWebObjects

315:デフォルトの名無しさん
07/09/25 17:55:23
何それ、聞いたこと無い

316:デフォルトの名無しさん
07/09/26 02:12:57
>>313
strutsはたいしたことはやってないので見通しがいいのと、
登場した時期が早かったのと、
開発メンバーが他のを覚えようとしないので、
うちでもめちゃくちゃポイントが高い。

317:デフォルトの名無しさん
07/09/26 03:23:52
>>311
ひがさんがくさす頭の固いおやじは流行にうといだけでしょう。
本物のおやじはそもそもJavaを使いません。

人月計算とExcelとスーツの世界より
URLリンク(anond.hatelabo.jp)

318:デフォルトの名無しさん
07/09/26 07:12:04
プレゼンテーションフレームワーク以外にも
覚えないといけないことはたくさんあるので
一度覚えた Struts を使ってくれていいです。
それよりはテスト技法とか、リファクタリングなんかを覚えて
コードの品質を上げてもらえればうれしいです。

319:デフォルトの名無しさん
07/09/26 12:10:10
>>315
WebObjectsはiTunes Storeに採用されたJavaのWebフレームワークです

320:デフォルトの名無しさん
07/09/26 13:39:06
ああ、アップルのか
俺的には、どんだけマイナーなんだよって感じだけど、他では大流行してたりするのかな

321:デフォルトの名無しさん
07/09/26 15:38:16
Macで開発してた人には人気が高いし、WebObjectsを模倣したフレームワークも多くある。
Cayenneなんかもそんな感じじゃなかったかな

322:デフォルトの名無しさん
07/09/26 16:54:10
Cayenneって永続化層のフレームワークじゃなかったっけ?

323:デフォルトの名無しさん
07/09/26 20:17:37
>>321
知ったかぶりもここまで度を過ぎましてはいけませんな
ご短慮でありましたな

324:デフォルトの名無しさん
07/09/26 20:40:21
URLリンク(www.google.co.jp)

325:デフォルトの名無しさん
07/09/26 23:38:33
>>324の検索にヒットした内の1つであるこの自動車情報サイトもWebObjectsで構築されてるようだ
「PORSCHE Cayenne S 標準価格860 万円」だって
URLリンク(www.vividcar.com)

326:デフォルトの名無しさん
07/09/27 09:18:41
なんにせよMacなんぞサーバに採用しないし、WebObjectsを使うことはねえな

327:デフォルトの名無しさん
07/09/27 10:26:37
WebObjectsはJavaだからSolarisでも動くって…

328:デフォルトの名無しさん
07/09/27 16:56:20
java厨化石化の傾向がこんなに早くみられるとは・・・

329:デフォルトの名無しさん
07/09/28 11:16:39
>>328Javaも今に衰退しますからあと10年見守ってて下さい

330:デフォルトの名無しさん
07/09/28 23:55:50
SSHってなんだと思ったら

Struts+Spring+Hibernate
のことか。

331:デフォルトの名無しさん
07/10/03 00:53:26
Strutsのよさって何だろう?

Action(画面遷移の定義)とリソースが落ちてるぐらいしか思いつかん。
Strutsタグは糞だし、デバッグもしにくい(わかり難い)
勉強するのにはいいかも試練が初心者のは難しい気がする。
ごちゃごちゃ機能があるくせホントに使えるのはあまりない
Application層を目的として作ったはずなのにDataSourceが定義できる時点で・・・

後継承を繁盛に使うせいでユニットテストが使えない。
ver2.xからがらりと変わってるらしいけど・・・・
変なところで固い癖にごちゃごちゃしすぎ

ところでDynaActionFormとか使ってる人がいたら使い方教えてください


332:デフォルトの名無しさん
07/10/03 01:20:25
DynaActionFormの利点がわからない

333:デフォルトの名無しさん
07/10/03 01:43:41
>>331
>Application層を目的として作ったはずなのにDataSourceが定義できる時点で・・・
Application層ってなんすか?
自分が知らないだけですかね。

Datasourceは定義できるだけで非推奨じゃなかったっけ?
まぁ使わなければいいだけだし、使わんでしょ普通。

>後継承を繁盛に使うせいでユニットテストが使えない。
よくわかんないなー
ActionクラスとかがサーブレットAPIに依存しているので
結局画面で動かさないとできないとかそういうこと?

MockのHttpSessionとかHttpServletRequestを用意すれば
簡単に単体テストできるというか俺はやったけど。

なんか変な共通処理とか環境に依存する部分を
Actionクラスに見せまくる作りだとやりにくいけどね。
ここはちゃんと設計すりゃ大丈夫でしょ。

334:デフォルトの名無しさん
07/10/03 03:10:54
「Strutsの良さ」なんて、土方が集めやすいぐらいでしょ。
Wicketは良いよ。土方集められないけど。

335:デフォルトの名無しさん
07/10/03 05:56:47
>>334
親方乙ですw

336:デフォルトの名無しさん
07/10/03 08:56:20
>>331
StrutsTestCase for JUnit使うといいよ。
URLリンク(strutstestcase.sourceforge.net)
Mockテストとオンコンテナのテストの両方ができる。

337:デフォルトの名無しさん
07/10/03 11:08:17
DataSourceの定義は、1.1の頃からドキュメントでは「推奨しない」と言っていたが、1.3からは完全になくなった。
1.3では定義すら出来ないよ。

1.3では標準でMockテストのためのTestCaseクラスが用意されている。
StrutsTestCaseなんて今時使う奴いるのか?
Strutsを使った開発をさらに難しくするだけじゃないか。

2系は今はStrutsプロジェクトで開発されているが、まったく別系統のフレームワーク。
「Strutsの新しいバージョン」と思っていると間違い。


338:デフォルトの名無しさん
07/10/03 20:57:00
>>337
使ってるが、悪いか、ヴォケが!

339:デフォルトの名無しさん
07/10/03 21:03:50
悪くはないが、ヴォケはお前だと思うよ

340:デフォルトの名無しさん
07/10/04 21:49:24
>>339は趣味でしかプログラミングをしないヴォケ。

341:デフォルトの名無しさん
07/10/04 22:00:40
仕事だったらもっとヤバいだろw
クソアーキテクトの下で働くのも大変だな。

342:デフォルトの名無しさん
07/10/05 00:33:29
マイコミにStruts2載ってた。

依存性が、かなり排除されててテストしやすそう。
内部は、リフレクションバリバリっぽいな。

URLリンク(journal.mycom.co.jp)

343:デフォルトの名無しさん
07/10/05 12:47:56
質問なんですが、
Actionを作った場合、ActionFormを使わない場合でも、
それに対応するActionFormクラスは、
絶対作らなければならないんでしょうか?

344:デフォルトの名無しさん
07/10/05 12:54:59
そんなことはない

345:デフォルトの名無しさん
07/10/07 01:15:04
Strutsの悪いところってなんですか?

346:デフォルトの名無しさん
07/10/07 01:40:13
>>345
一度、WicketやTeedaなどに触ってみるといいと思うよ。

347:デフォルトの名無しさん
07/10/07 03:13:34
teedaは触ってます
strutsより明らかに良いと思ってます
なのでstrutsを排除したいと考えています
部署で説得するためにネタください

348:デフォルトの名無しさん
07/10/07 04:49:45
>>347
悪い所出そうとしてる時点で説得スキル足りない
より良い物として出さないと

349:デフォルトの名無しさん
07/10/07 08:24:11
頭堅い奴は枯れてるとかいう理由で、いくら良いものがあってもなかなか既存技術捨てて新しいモノに移行しようとしない。


350:デフォルトの名無しさん
07/10/07 08:31:24
>>345
XML

351:デフォルトの名無しさん
07/10/07 11:53:19
>>347
どういう立場の人を説得したいの?
エンジニア?それともマネージャ?

352:デフォルトの名無しさん
07/10/07 13:30:37
マネージャーです

353:デフォルトの名無しさん
07/10/07 14:17:26
>>352
会社によって微妙に役柄変わるからあれだけどマネージャーレベルなら
適応によるプラスマイナス両方出して、大まかでも目に見える数値の話でないと食いつかないよ。
マイナス材料(Ex:初期教育コスト、リソース確保とか)がでて無いとちゃんと選定しているのか?と言う話になるし。

注意しないといけないのは「じゃあ次一つやってみて比較しよう」が出た場合、
実績あり(Struts)なし(Ex:Teeda)が初期教育コスト無視で比較される可能性がある。
プロジェクト完了後、技術者からちゃんと情報収集して判断してくれる人ならいいんだけどね・・・

あと技術者レベルでの根回しは必須だと思うよ。

354:デフォルトの名無しさん
07/10/07 15:05:02
マネージャレベルだと、有償サポートって売りにならない?


355:デフォルトの名無しさん
07/10/07 15:51:09
フレームワークの選定にマネージャーがでてくるの?
技術わかるマネージャー?

356:デフォルトの名無しさん
07/10/07 16:14:35
土方が探しやすいとか丸投げしやすいとかそういう要素が重要

357:352
07/10/07 16:15:26
古い組織だとマネージャー出てきます。
WEBと言えばstrutsしかなくてそれがあればWEBアプリができると信じています。


比較しようと思ったときにstrutsのマイナス面を考えたんだがなかなか決定的なのがなくて…



teedaって有償サポートあるんですか?

358:デフォルトの名無しさん
07/10/07 16:22:04
>>357
1個人のいうマイナスと実績どっち信じる?
その後どう言ったってそのレベルの否定から入ったら終わり

359:デフォルトの名無しさん
07/10/07 17:23:53
ISIDがサポートやってるよ。

JSPじゃなくって素のHTML使えるのも利点だね。
「HTMLだけが書ける安い人が使える」って言って。

あとは、東京三菱の実績ありってとこかなぁ。

技術的な話だと、Ajaxサポートとかは?

360:デフォルトの名無しさん
07/10/09 06:32:47
すみませんスレ違いなのは多々承知しているのですが
Eclipse3.31用のTomcatプラグイン(Sysdeo)がほしいのですが
サーバがずっと落ちてて見つけれません
URLリンク(www.sysdeo.com)
URLリンク(www.eclipsetotale.com)
どなたか3.31で使える他のTomcatプラグインもしくは
Sysdeoの3.31対応のプラグインのダウンロードページ知ってる方
教えていただけませんでしょうか?

361:デフォルトの名無しさん
07/10/09 08:48:48
WTPがまともになった今どき、Sysdeoなんて使ってる奴がいることに驚いた。


362:360
07/10/09 09:37:12
すみません
これからJavaはじめようと思って解説サイトの手順通りに従おうと思ったので・・・
入れてるのがwtp-all-in-one-sdkなので知らないうちに開発環境整ってたんですね
WTPについて調べてきます

363:デフォルトの名無しさん
07/10/09 20:22:53
WTPってまともになったんだ?
Tomcat Pluginと比べてどんなメリットがありますか?

364:デフォルトの名無しさん
07/10/09 20:38:28
比べるものですらない

365:デフォルトの名無しさん
07/10/09 23:25:31
eclipse純正という安心感
all in one
動的WEBプロジェクトのディレクトリが決まっててlibにjarいれたらひとまとまりになる
まん

366:デフォルトの名無しさん
07/10/10 00:24:30
NetBeansの機能の一部やん>WTP
struts-configの編集にはまた別のプラグイン入れなあかんかった

367:デフォルトの名無しさん
07/10/10 05:21:09
all-in-one入れたけどweb開発らしきプロジェクトが選択項目に出てきません
なんでだろう・・・
もしかしてtomcat入れないとだめ?

368:デフォルトの名無しさん
07/10/11 21:10:59
久し振りにstrutsの開発をすることになった。
今日設定をしてたんだけどうまく動かない。。

URLたたいてもActionServletが呼び出されていない感じで404になる。
コンパイルは通るし、デプロイは成功、
デプロイ時にActionServletは読み込まれているので(デバックした)
ここら辺は問題ないと思うんだが・・・何か原因わからない?

ちなみにearの中にjar,warを含めて、
application.xmlにコンテキストは指定してある。
同じverのstrutsサンプルは動いたので
完全に設定の問題なんだが。。。

369:デフォルトの名無しさん
07/10/11 21:22:45
>>368
>ここら辺は問題ないと思うんだが・・・何か原因わからない?
>完全に設定の問題なんだが。。。

370:デフォルトの名無しさん
07/10/11 22:02:39
フォームで、submitボタンやtextボックスのpropertyに、
日本語の伸ばし棒"ー"を使うと、

javax.servlet.ServletException: BeanUtils.populate
at org.apache.struts.util.RequestUtils.populate

という例外が発生してActionのexecuteまで行かないんですが、
これを回避する方法って無いでしょうか?

ちなみに伸ばし棒以外の日本語は大概大丈夫でした。

371:デフォルトの名無しさん
07/10/12 05:45:44
actionListener / onChange で「ー」が入ってたら「-」に変えてしまえ

372:デフォルトの名無しさん
07/10/20 21:29:43
スレ違いかもしれないのですが、どこで聞いたらいいのかわからないので、、、

Actionを継承したクラスに入力チェックやSQLを投げる処理が書いてあるのって普通なのでしょうか。
いろいろな面で(熟練度とか)仕方ないのかもしれないのですが、
SQLの種類が大量になったり、入力の仕様が変わったりするたびに修正漏れなどがおきてどうしようもなくなっています。
もちろん未熟者の私が口をはさめる事ではないのですが、他社での経験がないので知っておきたいのです。

373:デフォルトの名無しさん
07/10/20 22:10:20
>>372
そのレベルが集まって一番コスト低いのがその手法なら・・・それでもその手法は選択できないw
入力チェックは一概に言えんけど、DBアクセス周りはS2DaoとかiBATISとか触ってみるといいよ。

374:デフォルトの名無しさん
07/10/21 16:30:40
>>372
ActionクラスにSQLとか終わってると思うすけどね。
unitテストとかできんでしょ?
MockのHttpServletRequestとか用意して単体テストできるようにしたことあったけど、
それにしてもview周りの面倒な処理が入りやすいActionクラスからは
その手のは排除するようにすべき。

単項目でチェックできない入力チェックなら
Actionに入ってもいんじゃないかな。
でもその話からするとActionクラスで
全部をやろうとしている設計ぽく聞こえるなー
俺なら絶対に触りたくない。

375:デフォルトの名無しさん
07/10/21 18:04:18
Strutsが出て5年くらいになるか?

当時、俺はJavaを未経験で入って、研修という名のもとJava未経験のおっさんが
だしてくれた課題をせこせこ作ってて、現場デビュー。ちょっとしかかじったことな
JSP・サーブレットで悪戦苦闘。その後、StrutsやらEJBやらわけわからん用語が次々とでてきて
もうだめだと思い、リタイヤ。このまま新技術がどんどん出てきたんでわ、とてもじゃないがついていけないとおもった。

今、色々みてみたら、当時からそんなに変わってないじゃん。。なんのこっちゃか。。

376:デフォルトの名無しさん
07/10/21 22:30:42
ねえStruts2やってみてるんだけど、なんでもないページでもレスポンス遅くね?一拍置いてから表示される感じなんだよね
解決策あるんでしょうか?

377:デフォルトの名無しさん
07/10/21 22:48:52
>>375
昔のEJBは確かにアレだったような希ガス。
とは言え今ならJSFとかにシフトすればいいのでは?
それかJava捨ててRoRとか。

378:デフォルトの名無しさん
07/10/22 15:47:47
Tomcat6.0 + Struts1.3.8を使っているんですが、
FormFileを使ったファイルアップロード時にできる、
一時ファイルはどこに作成されるのでしょうか?

<controller>
<set-property property="tempDir" value="/TempDown/" />
</controller>

これで一時フォルダを指定して見てみると、
一時ファイルは処理後も消えずに溜まっていました。
一時フォルダを指定せずデフォルトでも動かしていたのですが、
そのときできた一時ファイルが残っているなら消したいです。

379:デフォルトの名無しさん
07/10/22 16:06:43
FormFile#destroy()

380:デフォルトの名無しさん
07/10/22 16:08:03
デフォルトの一時ディレクトリは、コンテナが割り当てるアプリケーションの一時作業ディレクトリ。
Tomcatなら%CATALINA_HOME%/work/Catalina/localhost/contextname以下。

381:378
07/10/22 19:08:04
どうもありがとうございます。

>>379
一時ファイル消せるんですね。
根本的に解決しました。

>>380
Tomcatのserver.xmlのContextのworkDirに設定されてました。

382:デフォルトの名無しさん
07/10/26 23:40:55
URLリンク(journal.mycom.co.jp)
今まで1.2系しか使ってなかったけど、これ読んだら
今度作るときはStruts2もいいかなと思ってきた。
1.x系よりけっこうシンプルそうじゃない?
2系使ってる人いる?

383:デフォルトの名無しさん
07/10/27 02:19:35
>>382
正直、TeedaとかWicketのほうが全然いいと思う。

384:デフォルトの名無しさん
07/10/30 10:18:55
DynaActionFormをプログラム内で生成して値を設定するには
どうすればいいでしょうか?

普通のActionFormなら作ったクラスのインスタンスを生成すればいいですが、
DynaActionFormはform-beanでform-propertyを設定しても、
クラス自体を作ったわけじゃないので、
ただのDynaActionFormでしかインスタンスを作れません。

385:デフォルトの名無しさん
07/10/30 16:24:40
JSP を標準のビューから追い出してテンプレート志向を強めたら
Struts は生き残れたかもしれないが。もうダメだろう。

386:デフォルトの名無しさん
07/10/30 17:12:41
最近上司に迫られてStrutsの勉強をしてみました。
それで簡単な社内システムを作ってみました。
せっかくなので、今どきっぽいやつをというわけでJSFも勉強してみようと思いました。
このスレでもJSFのスレでもJSFの評判はいまいちですね。
いまさらこんなことを聞かれてもとお思いでしょうが、結局今やるならどれ?

会社的にはわけのわからないツールを使っていて、
JSP/Servlet関係の仕事も去年数件やったくらいです。

387:デフォルトの名無しさん
07/10/30 18:02:06
個人的にはSpringとかどうかなと思っている

388:デフォルトの名無しさん
07/10/30 20:06:27
Springは層が違う

389:デフォルトの名無しさん
07/10/30 22:16:27
Teeda, Wicket, Tapestry
個人的にはWicket

390:デフォルトの名無しさん
07/10/30 23:35:57
>>384
protected DynaActionForm initNextDynaForm(ActionMapping mapping, String NEXTFORM) throws IllegalAccessException, InstantiationException {

FormBeanConfig config = mapping.getModuleConfig().findFormBeanConfig(NEXTFORM);
DynaActionFormClass dClass = DynaActionFormClass.createDynaActionFormClass(config);
DynaActionForm dform = (DynaActionForm)dClass.newInstance();
return dform;
}

391:デフォルトの名無しさん
07/10/30 23:44:41
>>385
俺はしぶといと思う。struts。
過去の資産があるし、ググれば大抵のことが解決しちゃうから。これは
ある程度の生産性が保障されるしな。廃れるときは、Ajaxで生産性が飛躍的
にあがるフレームワークが広まったときじゃないかな。

AjaxとWicketってどんな感じなの?

392:デフォルトの名無しさん
07/10/31 00:40:56
そうそう、素敵なものが流行るとは限らないのがこの業界の悲しいところでもある。

393:デフォルトの名無しさん
07/10/31 15:58:37
Ajaxなんて面倒なもんやらずにFlex+Strutsでいいや

394:384
07/10/31 16:48:36
>>390
どうもありがとうございます。

DynaActionFormClassのJavadocに、
「開発者はこのドキュメントを調べる必要ない」って書いてたんですが、
DynaActionFormを自分で作るのはあまりやらないことなんでしょうか。

395:デフォルトの名無しさん
07/10/31 17:16:20
ないな
使い勝手いいもんじゃないし

396:386
07/10/31 17:25:34
みなさんありがとうございます。

Strutsでっていっときます!

397:デフォルトの名無しさん
07/10/31 18:26:15
EventDispatchActionを使うと、
submitボタンのpropertyによってメソッドを振分けられますが、
リンクタグにpropertyのようなものをつけて、
submitボタンと同じようにメソッドを振り分けることはできないでしょうか?

こんな感じでやってみたんですが、これでは無理でした。
<html:link action="/paging" property="next">次へ</html:link>

度々の質問で申し訳ありませんが、よろしくお願いします。

398:デフォルトの名無しさん
07/10/31 22:41:58
>>397
やったことはないですが、html:linkにパラメータ渡せるんで、submitでわた
すような値をセットして見ては?
ex)
next=次へ

あと、html:linkへのパラメータの設定方法はぐぐれば出てくると思います。

399:デフォルトの名無しさん
07/10/31 22:45:30
>>393
flexはえらい高かった。2になって多少安くなったかもしれんけど。

400:デフォルトの名無しさん
07/11/01 09:52:59
>>398
昨日色々とググったんですが、なかなか上手くいかず…
パラメータ付けるだけならできるけど、
EventDispatchActionのメソッド振り分けができなかったり、
バージョンによってタグに使える属性が違ったり。

と思ったらできました。
Struts1.3.8でこんな感じです。
<html:link action="/paging" paramName="PagingForm" paramId="next">リンク</html:link>
これでpagingアクションのnextというメソッドに飛びます。

401:デフォルトの名無しさん
07/11/01 10:07:53
>>391
Wicket+Ajax普通に使ってるよ…受託案件じゃないけどw

402:デフォルトの名無しさん
07/11/01 14:31:37
>>399
Flexサーバ要らなくなって多少どころじゃないくらいに安くなった
URLリンク(www.atmarkit.co.jp)

403:デフォルトの名無しさん
07/11/01 22:52:20
>>402
Flexデータサービスとかがなくても、サーバ側とのデータのやり取りできる
の?

404:デフォルトの名無しさん
07/11/02 12:45:08
WebService 経由にしてしまえばどうとでもなる。

405:JAVA初心者
07/11/02 19:23:54
こんにちは。
いつも参考にさせていただいています。

STRUTS使用のJSPで、html:textを使用するときに
フォームのプロパティに値がsubmit後に入ってくると思いますが、
formの直下にプロパティがない場合、
たとえば
formの直下にaBeanというビーンがあります。
そして、そのビーンの下にbBeanがあり、
そのbBeanの下のプロパティにsubmit後に
ユーザの入力値を設定したい場合は
そのようなことは技術的に可能でしょうか?
また、可能であれば、どのようにJSPにかけばよろしいでしょうか?
よろしくご教授してください、、


406:デフォルトの名無しさん
07/11/02 19:33:40
スレ読まずにSTRUTSの良さ語らせて貰うが、STRUTSの良いところはお手軽に
アップロード出来ることかな?

407:デフォルトの名無しさん
07/11/02 19:43:33
>>405
<html:text property="aBean.bBean.プロパティ名" />

誘導されたのなら、「○○から誘導されました」と一言沿えるのが礼儀だぞ。
それをしないとマルチポスト認定されるぞ。


>>406
Strutsのメリットでも何でもない。
Commons FileUpload使えば同じぐらい簡単。


408:JAVA初心者
07/11/02 19:45:56
>407
あまりこちらの掲示板の使いこなせてなかったようで申し訳ありませんでした。
以降気をつけます。
また、ご教授してくださいましたやり方でやってみます。
ありがとうございました。


409:デフォルトの名無しさん
07/11/02 22:08:38
どうでもいいんだけど、struts のサイトにあるドキュメントのなかで、
タグがエスケープされてしまって、ドキュメントの中に <p><strong>Note: Some of ..... のようにタグが表示されてしまっていて見にくい。

例:
URLリンク(struts.apache.org)

なんでこんなことになっているんだ?


410:デフォルトの名無しさん
07/11/02 22:45:31
Struts1.2ってこれからの仕事では使われていないのかな?
springって今でも使われてる?流行で終わったのかな。

数年前のOSSのフレームワークブームの頃のPGが出世して、
世代が変わったかな。

411:デフォルトの名無しさん
07/11/02 23:17:01
>>410
うーん、JSFとかの方が1から作るなら生産性は高いんだろうけど
慣れたStrutsと慣れないJSFでどっちをとるか?というと今のところStrutsを選んでしまう

Springは…正直、Strutsで何十も画面を作ってからでないと、
Strutsの何が駄目なのか?なぜDIが登場したのか?DIだと何がうれしいのか?
があまり理解できないと思う。
そういう意味での流行は終わったのかもしれないが、使われてないことはないぜ

412:デフォルトの名無しさん
07/11/02 23:42:17
>>411が一番SpringもStrutsもわかってないなw

なぜStrutsとSpringが同じレイヤーで語られるんだよwww


413:デフォルトの名無しさん
07/11/03 07:45:44
一瞬最近のSpringってJSF相当の機能でも盛り込んだのか?と思ってしまったが・・・。

414:デフォルトの名無しさん
07/11/03 12:50:34
教えてください。

Struts-config.xmlに以下のようなアクションと、そのプロパティが設定されているとき、
<action path="test/test01" ~略~>
 <set-property ~略~>
</action>

test/test01.do でアクセスした時に、filterでアクションのプロパティを取得したいです。
※actionクラスの実行前に取得したいです。

actionクラスのActionMappingオブジェクトからは参照できるんですけど、
dofilterには該当クラスが引数にないので参照できません。


もう一つの質問ですが、
Struts-config.xmlのAction要素のpath一覧を取得する方法はありますか?
可能なら教えてください。


415:デフォルトの名無しさん
07/11/03 13:15:11
xsltでも使えば?

416:デフォルトの名無しさん
07/11/03 13:17:48
標準の方法でお願いします。
標準外のライブラリの追加は認められないので・・・

417:デフォルトの名無しさん
07/11/03 14:00:21
javax.xml.transform.*を標準外と申したか

418:デフォルトの名無しさん
07/11/03 17:10:34
稼働中のシステムでpathを取得する必要があるのか?
ツールの類にまで「標準外は駄目」とかあるのか?
jakartaのライブラリ類なんかも使えないのか?
そもそもstrutsが「標準外」じゃないか?

419:デフォルトの名無しさん
07/11/03 17:43:13
>>417
ごめんよく知らないからxsltをぐぐったら何か追加しなきゃだめだと解釈した

jdk1.5とstruts1.3.8に入っているもの意外原則駄目。
唯一の例外はojdbc14.jar


フィルタからactionのプロパティ取得は普通のやり方じゃ無理ってこと?

420:デフォルトの名無しさん
07/11/03 17:54:50
>jdk1.5とstruts1.3.8に入っているもの意外原則駄目。
>唯一の例外はojdbc14.jar

アフォじゃねーか、と思う環境だな。

421:デフォルトの名無しさん
07/11/03 18:45:37
>>420

なぜアフォなんだ?
ある程度縛りも必要と思うが。

422:デフォルトの名無しさん
07/11/03 19:03:12
>>421
どこが「ある程度」なの?

423:デフォルトの名無しさん
07/11/03 19:11:17
>>419
それ酷すぎないか?w
DBアクセス周りとかトランザクション管理とか全部自作?

424:デフォルトの名無しさん
07/11/03 19:45:05
ojdbc14.jarは使うんだって
トランザクションはsqlで吐いてする予定。
DBアクセスの自作ライブラリ作るのはそんな苦にはならないし
※リクエストをまたがってのトランザクション制御が出来るかはまだ未検証(出来ますか?)

>>420
業務のシステム開発にはいろいろしがらみがあるんだよ
趣味みたいに好き勝手自分だけの裁量では出来ない。
新しいライブラリを使うためには、
その根拠などの諸々を上や客に説明し説得する必要がある。
正直めんどくさいから、標準で出来ることだけで済ましたいんだよ。



次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch