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

1 名前：デフォルトの名無しさん [2006/12/30(土) 18:05:08 ] Apache Strutsフレームワークについて語るスレ 前スレ △△まだまだStrutsの良さを教えてくださいSession4 pc8.2ch.net/test/read.cgi/tech/1109465052/ 2 名前：デフォルトの名無しさん [2006/12/30(土) 18:05:53 ] 過去スレ △△さらにStrutsの良さを教えて下さいSession3 pc5.2ch.net/test/read.cgi/tech/1088870989/ △△もまいら漏れにStrutsの良さを教えてください pc5.2ch.net/test/read.cgi/tech/1048030962/ △△つづいて漏れにStrutsの良さを教えてくだっさい pc5.2ch.net/test/read.cgi/tech/1068207164/ エクリプス＋Struts開発 pc5.2ch.net/test/read.cgi/tech/1086356759/l50 The Apache Struts Web Application Framework struts.apache.org/ Strutsファンページ homepage2.nifty.com/ymagic/struts/ Strutsメモ muimi.com/j/jakarta/struts/ 3 名前：デフォルトの名無しさん mailto:sage [2006/12/30(土) 18:40:49 ] まだstrutsとか使ってるやついるの？ 4 名前：デフォルトの名無しさん mailto:sage [2006/12/30(土) 20:52:29 ] めっさいる 5 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 00:08:31 ] かわいそす 6 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 02:12:43 ] >>3 開発者の人に、Strutsの次に来るフレームワークで事例ありますかと聞いても 「次はリッチクライアントの時代だから純粋WebのフレームワークはもうStrutsで十分」 と言う。じゃあリッチクライアントで目星をつけてる技術/製品はと聞いたら 「今はまだ乱立状態だから絞れない」と言う。 結局長い目で保守を考えないといけない現場だと当分Strutsで行くしかないべ 7 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 09:31:54 ] >>6 っていうか、その開発者は自分でフレームワークの評価や、生産性について 考えられないだけ Strutsマンセーっていってても別の流れが来たらそっちに乗っかるんだから 8 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 10:37:23 ] 教育コストや学習コストを考えると 世の流れに乗るのもまた選択の理由になり得る。 9 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 10:45:09 ] 世の中の流れに乗る＝教育コスト、学習コストの削減には一概にはならん そういう短絡的発想が遺憾といっているｗ 10 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 14:53:56 ] >>9 使っている人が多いと情報を入手しやすくなるから 教育コスト、学習コストの削減にはなるんじゃない？ 11 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 15:11:39 ] 基礎学習においての学習コストが、新しいフレームワークで低くなっても ワークアラウンドが必要な場面の情報収集で割を食うから普及度は大切な指標だよ 12 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 16:37:48 ] そもそも、開発者全員がフレームワークについて情報を得られなきゃいけないって発想が間違っている。 Ｓｔｒｕｔｓを使うにしても、Ｓｔｒｕｔｓの情報が溢れていなければ使えないような使い方をしている時点で 学習コストがかかりすぎている使い方をしているってこと。 大体、Ｓｔｒｕｔｓにしたってこんだけ情報があったってマトモに使えるやついねーじゃんｗ 13 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 16:47:37 ] >>12で逝ってるフレームワークとは、Ｓｔｒｕｔｓのような汎用フレームワークの事 14 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 18:15:54 ] フレームワークなんてデザパタと同じだ 乱立してるより型落ちでも同じ使い方の奴のが保守コストが低い Struts以外のフレームワークをよしとする風潮がないのは当たり前 15 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 18:22:26 ] 右へ習え的な考えしかしない香具師がろくでもないシステムを作る現実 16 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 18:24:03 ] いかにも社会に出てない奴の発想だな・・・ 17 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 18:26:41 ] いかにも残業したり休日出勤したりするのがこの世界の常識って考えのヤツの発想だなｗ 18 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 18:29:06 ] 真逆すぎて呆れるばかり 19 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 18:33:27 ] 現存のStrutsプロジェクトをみてあきれるばかりｗ 20 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 18:34:51 ] >>19Strutsを使ったプロジェクトねｗ 21 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 18:35:42 ] オウム返しにしても寒すぎる、派遣の妄想ってとこか。くだらん 22 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 18:40:04 ] まぁ、次のフレームワークが広まるまでStruts使ってなさいｗ では良いお年を 23 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 20:54:14 ] みなさんが、Strutsプロジェクトに携わったのは何件ですか？ 私は、前に１回だけ．．． 正直な話、初めて見た時、何故これで動くのか訳がわからなかった （この当時、本でもネット上でもあまり詳しい説明されてるやつがなかったし、っていうか見つからなかったし） 「なんで普通にServletにしねぇんだよ」と心のなかで思っていた。 この仕事でよい年を迎えることができると思っている人はあまりいないような気がしますが 「健康である年を」 24 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 21:06:02 ] なんで？StrutsってただのMVC2フレームワークじゃん 25 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 21:54:28 ] >>23 Bateから1.0になったばかりの頃に、Struts+EJBベースのフレームワークを作りました。 いまも別件でStruts＋Spring+Hibernateベースのフレームワークを作ってる。 Strutsに限らず、汎用フレームワークはそのプロジェクトでどのように使うかって言う方針を立てて、 業務を実装するプログラマ達には必要最低限の使い方で実装できるように準備しないと、開発者 全員が汎用フレームワークの広い知識を備えなければならなくなる。 つまり、個々の開発者が（例えば）Strutsを直接触りまくるような現場では、>>23のような状況に陥ってしまう。 そういう現場では、開発者は終始深い森の中を地図もコンパスも無く彷徨い歩くような状況にあるので、 結果的に大変なだけでいい仕事は出来ないよﾈ 26 名前：デフォルトの名無しさん [2007/01/01(月) 07:01:58 ] なあstrutsって前提条件として覚えることが多すぎない？ 例えばvalidatorつかってエラーメッセージ表示するには 「エラーメッセージを読込むリソースファイルはキー org.apache.struts.action.MESSAGE で指定されたファイル (デフォルトのメッセージリソース)でなければなりません。」 だったり、validateエラーで飛ばす先のmappingの記述が「input=""」だったり。 taglibも学習・デバッグコストの割に新しいことができるようになるわけじゃ ないし。見た目はscriptletよりはマシかもしれないけど、大してよくならないし。 >>25 前に別件でシンプレクスってところのStruts＋Spring+Hibernateベースのフレームワークを いじったけど、あれはひどかった。携わってる人一人一人の能力が高いのに、 ろくに設計をしないでつくると酷くなる典型例だった。ドキュメントも無いし。 あと速度遅すぎ。 27 名前：デフォルトの名無しさん mailto:sage [2007/01/01(月) 09:48:26 ] 多いねぇ それにStrutsに限らずWebページベースのサーバサイドシステムだと、大前提としてコアJavaだけでなく、 HTMLやCSS、Java拡張技術として、Servlet、JSP、Tablib、等の技術をまんべんなく知ってないといけない。 更にその上にStruts等の知識が必要になる。 Strutsを採用している時点で物凄い教育コストがかかるってこと。 実装工程で、最低Javaは書けるって言う人間がスグに投入できないのは非常にまずい。 短期間作業に関わる技術者のスキルを当てにはできないし、仮にスキルがあったとして、その人がいなくなったら 保守できないようなつくり方たされたらかなわんし。 それに、Javaは書けるってレベルの技術者なら単価も安いしね。 28 名前：デフォルトの名無しさん mailto:sage [2007/01/03(水) 02:32:33 ] >>26 scriptletからtaglibではえらい進歩じゃないか？ いや、目標が低すぎるか。 とりあえずscriptletなんて一切使うことを許容するべきじゃないね。 俺が入った時点でゴリゴリ書きまくっていて後始末が大変だった。 >>27 こういうのを把握しているのはFWとかアーキテクチャを 抑えている人間だけでえーんちゃう？ 業務実装者は手順どおりに業務ロジックだけを こりこり書けばいいようにすればいいというか、 あいつらにそんなもの意識させちゃ駄目だ。 29 名前：デフォルトの名無しさん mailto:sage [2007/01/03(水) 02:55:54 ] >>28 ＞こういうのを把握して・・・・ 「・・・抑えている人間」って言うと、フレームワークを実装するプログラマとか も入るから、ホントウに意識しなきゃいけない人間はアーキテクトだろうな。 30 名前：デフォルトの名無しさん mailto:sage [2007/01/03(水) 15:01:05 ] >>26 scriptletなんて使う状況になるのは設計が破綻している証拠だな。 アホな連中に好き放題使われて地獄を見たことがないのかい？ まぁこれは上でコントロールする人間がいないのが悪いんだけど。 画面は渡されたbeanを展開するとか 条件（画面で判断した方が良いレベル）で 表示をちょっと切り替えるとかその程度だけにするべき。 それでまかなえないようなアプリなら それはもうStrutsでやるべきじゃない。 もうリッチクライアントを考えるべき、 と言いたいところだがなんか良い選択肢無いのかね・・・ 31 名前：デフォルトの名無しさん mailto:sage [2007/01/03(水) 15:13:28 ] Java Applet+Webサービスがいい気がするがフレームワークとかあったりするの？ じつはJava質問。相談スレにも投下してしまってるんだが 32 名前：デフォルトの名無しさん [2007/01/03(水) 23:21:24 ] MVCが徹底できていればscriptletもそんなに汚くならない。 でもscriptletを許可するとスキルの低いPGがjspにロジックを埋めちゃう。 taglibで全部やらせるには教育コストがかかる。 100画面程度のシステムならコードレビューで面倒見れるけど、 サブシステムごとにサブリーダーを置くようになると途中で破綻しちゃう。 どうしたもんかなあ 33 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 00:31:19 ] 画面の部品化 34 名前：res [2007/01/04(木) 11:32:44 ] Strutsって便利？？ ASPのほうがわかりやすくて好き 35 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 12:52:36 ] ASP知らないが、strutsは便利ではないｗ。 学習コストに見合わない生産性の低さに泣ける。 eclipse用のstruts plugin等を使えば、多少は、ましになるけれど。 今から新規の案件で使うのは、おすすめしない。 36 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 21:44:07 ] ASP.NETが最強だな 37 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 21:48:02 ] ASPはJSPとくれべるモンなんじゃね？ 38 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 21:52:45 ] >>35 ではﾅﾆがお勧めですか？ 39 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 22:07:35 ] ポストstrutsは何か？ ってのを言われて久しいけど、未だに決定的なのがないから 現場レベルでは、strutsしか使えない。 40 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 22:17:42 ] 多分Javaが廃れるまではStrutsを使い続けると思う Railsあたりの次世代FWが実績つけてきたところで乗り換える予定 41 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 22:41:27 ] あわれ・・・・ 42 名前：デフォルトの名無しさん [2007/01/04(木) 23:12:53 ] ASP.NETに比べるとStrutsってめちゃめちゃ難しい気がするんだけど、今時のWEBシステムってこんなもんなの？ PHP5とかってのも難しい？ 43 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 23:25:47 ] ASP.NETとStrutsって比べる対象になるのかってのが問題なんだが・・・ 44 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 23:28:03 ] でも一度ASP.NETの開発を経験しちゃったら もうJavaには戻りたくなくなってしまうし。 45 名前：デフォルトの名無しさん mailto:sage [2007/01/04(木) 23:30:07 ] ふーん 46 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 00:39:27 ] ASP.NETの真似をしようとしたJSFが失敗してしまったからな でもWin統一環境でないとASP.NETは採用し難いというのもあって、結局現在はJavaの開発がまだ多い 今年は減りそうな気がするけど 47 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 00:45:01 ] Javaが減ってどの言語が増えるの？ 48 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 00:51:51 ] 普通にRubyじゃね？ 自分の周りでも少しずつ開発事例を見かけるようになってきたし、 最近は本屋に行っても、どこもコンピュータコーナーはRuby本ばかりだし 個人的には、別に言語に拘りはないからどうでもいいけど 49 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 01:51:35 ] Rubyちらっと触っただけなんでよく知らないんですが、 性能面とかで大規模な案件に耐えられる代物なんですか？ どうしてもしょせんスクリプト言語ってイメージが取れません・・・ 偏見ですかね？？？ 個人的にはOOで設計した方がいいぐらいの大きさのプログラムなら もう慣れているJavaで書いた方が手っ取り早いし、 本当にささっと作るだけならPerlやるかなーって感じです。 50 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 01:52:10 ] Javaが出てきた時はC++プログラマはﾐﾝﾅそういってたな・・・・ 51 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 02:11:53 ] サーバーサイドのフレームワークじゃなくて、そろそろWebブラウザの側が もう少しリッチに進化してほしい。DBのデータを扱うことを想定したTABLEタグとか DIとかTDDとかで生産性向上するよりそっちの方が効果があるんじゃなかろーうか 52 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 07:36:28 ] >>51 ブラウザはWEBアプリ専用のソフトウェアじゃねえんだよ！！ 53 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 08:06:32 ] >>49 今のところRubyの方が遅いのは事実だが、 いいハードを買うかクラスタを増やすかすれば必要な性能は達成できる。 Rubyは生産性が高い（例のRailsの「Javaの10倍」ね）ので、開発コストを減らした分の金で 元は十分以上に取れる。というかハードなんて人件費に比べれば安いし。 ってのがRuby屋の言い分だと聞いた。 立場は逆だが、>>50の言うような「Java登場時にJavaプログラマが言ってたこと」に似てるな。 54 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 10:15:01 ] >>51 つAjax DBから取得したデータをJSON変換して、後はJavaScriptに扱わせる。 SwingのTableModelみたいなことは、今でもやろうと思えばできる。 Swingと同じで、Ajax主体でGUIを扱うFWがまだ無いけど 55 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 12:15:04 ] >>53 Javaちらっと触っただけなんでよく知らないんですが、 性能面とかで大規模な案件に耐えられる代物なんですか？ どうしてもしょせんインタープリタ言語ってイメージが取れません・・・ 偏見ですかね？？？ 個人的にはOOで設計した方がいいぐらいの大きさのプログラムなら もう慣れているC++で書いた方が手っ取り早いし、 本当にささっと作るだけならVBやるかなーって感じです。 今のところJavaの方が遅いのは事実だが、 いいハードを買うかクラスタを増やすかすれば必要な性能は達成できる。 Javaは生産性が高いので、開発コストを減らした分の金で 元は十分以上に取れる。というかハードなんて人件費に比べれば安いし。 ・・・なるほど、たしかに似てるなｗ 56 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 21:51:33 ] >>55 Amazon.comってWeblogicだそ？ 57 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 21:52:49 ] あ、なんでもない忘れてくれｗ 58 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 21:55:01 ] >>56 そうなのか? perlって記事もあるけど。 neta.ywcafe.net/000492.html 59 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 21:58:56 ] 相当前に聞いた話だからもうperlなのかも？ 60 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 22:56:58 ] >>54 Ajaxってどうなん？ 所詮JavaScriptじゃろ？ ていうかなんでJavaAppletがほったらかしなんだか判らんｗ 61 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:20:28 ] さっさとJSFに乗り換えた方が幸せになれると思うんだが。 再利用性などというマヤカシに捕らわれてるのが移りが遅いな。 実際に再利用できるものは汎用Util化されてるだろうしFWはなんでもいいはずなのに。 62 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:28:41 ] strutsで再利用と言えば、 Actionを連鎖させて途中のアクションをフィルタ的に使ったりすることもあるけど 実際は、1画面1アクションで作られてることが多いみたいだね。 明確にM-V-CとするよりもM-VCのほうが、効率いい場合もあるし。 63 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:31:16 ] >>62 ＞1画面1アクション そういう使いかたした事ない 64 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:36:42 ] >>62 多いっていうか、そういう風にしか使い道が思いつかないんだろ 65 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:36:58 ] うちのプロジェクトも原則は1画面1アクションだよ Action連鎖すると修正時の影響範囲がわかりにくくね？ しょせん、Actionなんてコントローラだし対して再利用性を求めてもしょうがないような 66 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:42:27 ] Actionでやるべき事と、業務ロジックを分離した時、Actionでやることはほとんど共通化できるんだけどね 67 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:47:03 ] っていうか、業務ロジックを呼び出すActionの振る舞いなんてﾐﾝﾅ同じじゃん 68 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:51:43 ] 普段はどちらかというと、1画面につき2Actionかな？ ただ、入力→確認→完了とか、複数ページにわたる入力みたいな いわゆる「画面フロー」の間は画面間で1Actionだな。 JSFだと、「1Action」が「1アクションメソッド」に変わる感じ？ 69 名前：デフォルトの名無しさん mailto:sage [2007/01/05(金) 23:54:46 ] 1画面1Actionにすると表示前準備とリクエスト処理が混在してわかりにくい。 あちこちの画面から呼ばれるような処理だと、さらにゴチャゴチャ。 70 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 00:15:25 ] ActionってCommandパターンだからと思って、最近は１URL１Actionにしている 以前は１画面毎にDispatchAction使ってたが、あまり意味ないし使いにくいのでやめた ロジックはサービス層のクラスにまとめて共通化してるので、 Action自体はパラメータの受け渡しぐらいしかやらないし 画面単位ではまとめないけど、初期化処理とか検索処理とか編集処理とか 似たような処理をするActionを継承でグループ化したりはしている 71 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 18:10:10 ] Action連鎖させるなんて絶対にやめるべき。 値の持ち回りはSessionにぶち込んででしょ？ 大量にバグが出るし、修正が発生した時地獄を見るよ。 コミットするような処理した後 一覧か業務フローのトップの画面を表示するActionにリダイクレトする、 とかならやるけど、これはもう処理の流れが切れているから。 OO中途半端にやってる人（俺含めて）を見ていつも思うんだけど 再利用って言葉の一人歩きがひどすぎないか？ 72 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 18:20:35 ] sessionじゃなくてrequestにぶち込むだろ普通。 sessionの使用禁止のプロジェクトもあるし。 どうでもいいけど、sessionの使用禁止ってのは無しにしてほしい。 ロードバランサ入れたときに別サーバに振り分けられるからって言うけど ロードバランサにsession維持機能あるんだから有効にすりゃいいだけじゃん。 73 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 18:23:42 ] NECダイレクトのサイトは、コンテナに頼らず自前でセッション管理してるっぽい？ URLに入ってるセッションIDらしき文字列がちょっと見慣れないんだが。 そういう方法もありかね。 74 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 18:25:24 ] 対話の質によるけどな。 フルGCの発生原因は中途半端な寿命のオブジェクトが在ることだし。 75 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 18:27:27 ] >>73 URLリライティングだろ、Tomcatでも使えたはず 76 名前：デフォルトの名無しさん [2007/01/06(土) 18:46:34 ] Action連鎖はわけわからなくなるな。。 validationとか絡んだら無限ループなる。 77 名前：デフォルトの名無しさん mailto:sage [2007/01/06(土) 20:24:05 ] >>76 atamawaruikaradayo(pu 78 名前：デフォルトの名無しさん mailto:sage [2007/01/08(月) 07:59:12 ] >Action連鎖 大昔から否定されてきたのをいまだ言ってるやつがいるのか・・ 少しはググってみたら、どうだ？ 79 名前：デフォルトの名無しさん mailto:sage [2007/01/10(水) 08:48:22 ] >>78 ttp://civic.xrea.jp/2006/02/28/strutsecii/ この人なんかは推奨してるみたいだけど、否定する理由っていうのはなに？ 80 名前：デフォルトの名無しさん [2007/01/10(水) 20:17:35 ] Strutsインアクションでは Actionを連鎖したくなるのは、Actionにビジネスロジックを書いているからだ！！ ビジネスロジックをサービス層に移せばActionの連鎖なんか必要ないはずだ！！ って書いてました 81 名前：デフォルトの名無しさん mailto:sage [2007/01/10(水) 20:23:21 ] >>80 そういう問題ではないな 82 名前：80 [2007/01/10(水) 20:30:46 ] >>81 そやな。。俺も自分でおもた 83 名前：デフォルトの名無しさん mailto:sage [2007/01/10(水) 20:51:58 ] forwardによる画面遷移、かつ同一ActionFormを利用する場面では Actionの連鎖を避けるべきだが、 リダイレクトによる画面遷移がOKな場面で、 かつ両Actionクラスで同一のActionFormを使わないような場所で、 画面表示前にビジネスロジックの実行が必要な場合は Actionの連鎖を使っても良いと思うよ。 人が否定したからと言って鵜呑みにする奴もアレだし。 Actionの連鎖がどういう動きをするのかをちゃんと理解して 使い分ければいいんじゃないかな。 84 名前：デフォルトの名無しさん mailto:sage [2007/01/10(水) 21:48:24 ] 独りよがりでやる分にはいいけど、 他人との合同開発や仕事でそんなもの出すなよ？ 85 名前：デフォルトの名無しさん mailto:sage [2007/01/10(水) 21:57:23 ] 厨乙。 86 名前：デフォルトの名無しさん mailto:sage [2007/01/11(木) 00:54:45 ] 俺は、登録してから、初回の表示と同じようなことする場合に、 初回表示用のアクションに連鎖させてる。 登録アクションには登録する処理しか書いておらず、 登録後に表示されるページの情報を作る処理は、連鎖先のアクションで作っている。 87 名前：デフォルトの名無しさん mailto:sage [2007/01/11(木) 01:04:20 ] >>86 アリだと思うよ。 88 名前：デフォルトの名無しさん mailto:sage [2007/01/11(木) 01:15:19 ] 何でもそうだけど、頭使って適切に使いこなすより、一律に同じ方法で統一しちゃう方が簡単だもんなぁ。 89 名前：デフォルトの名無しさん mailto:sage [2007/01/12(金) 00:08:26 ] 馬鹿の水準に合わせて開発すると、時間と体力ばかりくっていいこと無い 90 名前：デフォルトの名無しさん [2007/01/13(土) 12:26:10 ] すいません初心者で恐縮ですが Strutsの初心者向けの学習本で良いのありますか？ 91 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 16:10:56 ] なんか最近、自作の俺様専用フレームワークが最強のような気がしてきた。 92 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 16:33:44 ] >>91 気のせい。もしくは、限定された環境でのみ最強。例えば開発者があなただけとか。 93 名前：デフォルトの名無しさん mailto:sage [2007/01/13(土) 16:34:12 ] >>91 それは皆が通ってきた道だな 94 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:15:52 ] バリデータとコンバータが全てのFWで共通化されたら俺は平気で移る。 95 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:17:56 ] commons-validatorの事じゃなくて？ 96 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:20:40 ] strutsのバリデータって他フレームワークに簡単に持って行けないもん？ リクエストパラメタをBeanUtilsとかでBeanにセットしてvalidateってできないのかな。 97 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:27:37 ] commons-varidator commons-beanutils あとRequestUtilsクラスとかパクりゃいんじゃねーの？ 98 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:36:32 ] Webフレームワークを使う理由はバインディングしかないからね。 テンプレート機能だとか画面遷移だとかはフレームワーク作者のオナニーに付き合ってるだけ 99 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:38:47 ] 便利だけどね 100 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 00:54:24 ] JavaのWebフレームワークを一から作るくらいならStrutsつかっときゃいーと思うがの Strutsを使いやすいように拡張した方がな

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef