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

1 名前：デフォルトの名無しさん [2006/12/30(土) 18:05:08 ] Apache Strutsフレームワークについて語るスレ 前スレ △△まだまだStrutsの良さを教えてくださいSession4 pc8.2ch.net/test/read.cgi/tech/1109465052/ 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を使いやすいように拡張した方がな 101 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 01:45:43 ] オライリーのJakarta Strutsクックブック ってどうですか？ 102 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 01:49:45 ] Strusの本読んだ事ね 103 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 01:57:32 ] 二日ほど他人のソースとテックスコアの記事読んで適当に実践に使ったから本は読んでない。 104 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 02:08:24 ] Ja-Jakarta Projectのページ ttp://www.jajakarta.org/struts/ 105 名前：デフォルトの名無しさん mailto:sage [2007/01/14(日) 10:00:49 ] >>101 あまり読んでないけど、JSTL関連の章は役に立った。 おかげでlogicタグとbeanタグからはおさらばして、Struts上でJSTLとELをフルに利用できるようになった 106 名前：デフォルトの名無しさん mailto:sage [2007/01/16(火) 14:27:59 ] strutsって重くないですか？ 107 名前：デフォルトの名無しさん mailto:sage [2007/01/16(火) 14:42:45 ] >>105 レスありがとうございます。オライリーのサイトで目次を見ると、自分にはいろいろ 参考になることがありそうなので、買って読んでみます。 108 名前：デフォルトの名無しさん [2007/01/16(火) 21:41:15 ] >>106 使わないよりは重いな 109 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 20:15:47 ] 今回初めて使ったけどこれひどいね Strutsタグのエラーとかstruts-config.xmlの記述間違いの際のエラーとか のメッセージが不親切すぎてデバッグできやしない 110 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 23:03:37 ] ﾌﾟ 111 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 23:24:07 ] >>109 WTPのJSP・XMLエディター使うといいよ 112 名前：デフォルトの名無しさん mailto:sage [2007/03/05(月) 00:12:36 ] >>109 まぁ確かに不親切だとは思うけどね。 IDEのサポートちゃんと受けてる？ 転職したら秀丸でソース編集とかしている俺から見れば・・・ 113 名前：デフォルトの名無しさん mailto:sage [2007/03/05(月) 00:55:45 ] ＥＸＣＥＬファイルで定義してstruts-config.xml、validation.xml、フォームBeanを自動生成してます。 114 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 23:59:17 ] >>113 画面の仕様書から バリデーションとフォームの生成まではやった。 ただしバリデーション定義はS2Strutsのアノテーションによる方式。 あれ結構自動生成と相性がいいと思う。 struts-configのExcelからの生成ってどうですかね？ いまいちもとのExcelシートのイメージができないです。 115 名前：デフォルトの名無しさん mailto:sage [2007/03/09(金) 01:02:39 ] 1ワークブック＝1モジュール 1シート＝1Form 　　　　＝1Action 　　　　＝1リソースファイル（忘れてた） フォームの定義はValidation定義も併用 フォームBeanも自動生成 ネスとしたBeanのValidationも対応 global-exception等は別に1シート 116 名前：デフォルトの名無しさん mailto:sage [2007/03/09(金) 01:03:51 ] 要するに1ワークブック＝１struts-config.xml 117 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 01:15:23 ] >>116 そのExcelファイルくれ。 118 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 02:50:48 ] >>117 残念ながら、Excelだけではだめなのだ 自動生成ツールが必要なのだ 119 名前：デフォルトの名無しさん [2007/03/14(水) 19:20:37 ] struts 2.x が正式リリースになっているな。(2/27) だけどこのスレではぜんぜん話題になってないな。

---

---

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

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