フレームワークStrutsをいじくり倒す人の為のスレ
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
03/04/28 08:14ID:Ub0n1fGRhttp://www.ingrid.org/jajakarta/struts/
http://jakarta.apache.org/struts/
0605nobodyさん
04/10/21 23:06:35ID:???0606nobodyさん
04/10/21 23:06:40ID:???>それと、FormBeanはいちいち作るべき。
>EclipseやNetBeansその他のツールでセッター・ゲッターは自動生成できる
>それに比べればxmlで書くほうがめんどうで、メリットもない。
考え方が古いな。
まあ、それで本当にDynaBean使うより工数が減るのなら、逆に大したもんだ。
0607nobodyさん
04/10/21 23:08:15ID:???そういうポリシーがあって、あえてFormBean作るのなら問題はないけどね。
>>601みたいな「俺はこっちの方が慣れてるんだ」的な理由ではどうもね。
0608nobodyさん
04/10/21 23:24:45ID:???工数減ると思うよ。
Dyna使うとプロパティ名やプロパティの型がコンパイル時にチェックできないから
テストやデバッグで余分な工数がかかるのは容易に想像できる。
DynaだとXDocletでのvalidator.xmlの自動生成にも対応できないし。
考え方が古いのは606じゃないの？Struts1.1b2の頃（約2年前）には
606みたいなこと言う人はたくさんいたけど。
0609nobodyさん
04/10/21 23:35:17ID:???どうも無駄なコードを沢山書いているように見えてしょうがない。
0610601
04/10/21 23:39:16ID:???struts-config.xmlとかvalidator.xmlはXDocletが生成してくれるから、管理はBean.javaだけでいいし。
0611nobodyさん
04/10/22 00:00:11ID:???これが最強とか最高とかはないだろ。
どっちにもメリット・デメリットはある。
ム板のこのテの議論はどれもリスキーシフトまっしぐらだな。
0か1かハッキリしなきゃ死ぬのか。そんなに二進数が好きか。
0612nobodyさん
04/10/22 00:01:02ID:???ステップ数という概念をオブジェクト指向言語に持ち込む時点でアタマ相当古い＆堅いね。アンタ。
インタフェースと実装を分ける設計とか抽象クラスを作成するのもステップ数稼ぎの無駄なコードとか言われたりしてｗ
0614nobodyさん
04/10/22 00:24:01ID:???自分の情勢が不利になると一般論を持ち出すんですね。
XDocletが現れて、DynaFormBeanのメリットはほとんどなくなって、デメリットがめだつようになったんだけどね。
0615nobodyさん
04/10/22 00:38:12ID:???もっと役に立つ話でも書いてくれ。
こういう議論は飽きるほど見てきたからもう十分。
0616nobodyさん
04/10/22 00:42:24ID:???株ロボコンテストのサイトはStrutsで動いてる
0617nobodyさん
04/10/22 01:19:09ID:???自分に不利な結論がでると、役に立たない話だったことになるんですね。
しかも、勝ち負けの話じゃない、といいながら「勝ちでいいから」と。
0か1かハッキリしなきゃ死ぬのは自分のことじゃないか。
２つの手法があって、どっちがいいのかという話は、宗教論にならない限りは役に立つと思うんだけどね。
0619nobodyさん
04/10/22 02:48:39ID:???0620nobodyさん
04/10/22 02:50:00ID:???0621nobodyさん
04/10/22 03:07:18ID:???0622nobodyさん
04/10/22 03:17:48ID:???0623nobodyさん
04/10/22 03:27:23ID:???0624nobodyさん
04/10/22 05:04:53ID:???0625nobodyさん
04/10/22 06:30:35ID:???0626nobodyさん
04/10/22 08:52:47ID:???みんながDyna、ダイナと騒いでいた2年前と今ではIDEの普及率に大きな開きがある。
アクセサを書かなくていい、というメリットは現在では無いに等しくなった。
極論すれば、EclipseがDynaFormBeanの存在価値を消した、ということか。
0627nobodyさん
04/10/22 09:27:02ID:???struts-config編集ができるだけのStrutsツールも無用になったし。
ま、「時の流れが」ってことだね。
0628nobodyさん
04/10/22 09:36:12ID:???0629nobodyさん
04/10/22 09:51:25ID:???どこにXDocletを使わない理由が？
0630628
04/10/22 10:23:23ID:???いや、正直使ったことなくて一通りサラッと調べてみたんだけど
俺にはメリットが理解できなかったもんで
XDoc童貞な俺にやさしい解説おながいしますエロい人
0631nobodyさん
04/10/22 10:53:26ID:???XDocletの利点
・xxx.javaだけをいじればいい
struts-config.xmlやらvalidator.xmlを記述する必要がない。
・クラス名の記述が必要ない
FQNを正確に入力するのは結構めんどくさい。
・複数人で同時にstruts-config.xmlをメンテするときの問題が少なくなる。
CVS使ったとしても、コンフリクトしたときは手作業
これが一番のメリット。
デメリット
・最新に即時対応しない
けっこう困る。
いまでも正式版は1.1まで。
1.2が使いたければXDoclet1.2RCを使う。
・struts-configの知識が必要ないわけはない
・集中管理ができなくなる。
でも、集中管理って必要？
・antが必要
ま、Tomcatで開発するならコンテキストの再起動するのにAnt使った方が便利だし。
0633nobodyさん
04/10/22 12:42:57ID:???XDocletはどっかに解凍。
<target name="xdoclet.struts">
<taskdef classname="xdoclet.modules.web.WebDocletTask" name="webdoclet">
<classpath>
<fileset dir="${dir.xdoclet}/lib" includes="*.jar"/>
<fileset dir="${dir.tomcat}/common/lib" includes="*.jar"/>
<fileset dir="${dir.web}/WEB-INF/lib" includes="*.jar"/>
<pathelement path="${dir.web}/WEB-INF/classes"/>
</classpath>
</taskdef>
<webdoclet destdir="${dir.src}" excludedtags="@version, @author, @todo"
force="true" mergedir="${dir.merge}" verbose="false">
<fileset dir="${dir.src}">
<include name="**/*.java"/>
</fileset>
<deploymentdescriptor destdir="${dir.web}/WEB-INF" servletspec="2.4"/>
<strutsconfigxml destdir="${dir.web}/WEB-INF" version="1.2"/>
<strutsvalidationxml destdir="${dir.web}/WEB-INF"/>
</webdoclet>
</target>
こんな感じのスクリプト動かす。
dir.xdoclet XDocletを解凍したところ
dir.tomcat Tomcatのベースディレクトリ
dir.src ソースの場所
dir.merge マージファイルの場所
dir.web 生成先
version="1.2"とかservletspec="2.4"が使えるのはXDoclet1.2RCからだから、どっかから拾ってきやがれ。
ム板のXDocletスレへでも逝け。
あとはググれ。
0634nobodyさん
04/10/22 14:01:17ID:???理解できればメリットがわかるんだろうけど漏れにはむりぽ＿|￣|○
0635nobodyさん
04/10/22 15:03:06ID:???/**
* @struts.action
* name="inputForm"
* path="/input"
* scope="request"
* input="/input.jsp"
* validate="true"
* @struts.action-forward
* name="success"
* path="/index.jsp"
*/
public class InputAction extends Action {
みたいな感じで書いて、あとは>>633のantスクリプト走らせるだけ。
0637nobodyさん
04/10/22 19:17:20ID:???tp://www.itmedia.co.jp/enterprise/0404/26/epn01.html
0638nobodyさん
04/10/23 14:22:29ID:???チェックボックスを各行の先頭につける一覧を表示しているのですが、
Actionの中でcheckboxの選択有無の判定がうまくいきません。
今はFormの中でチェックボックスプロパティを配列形式で宣言していますが、
選択したチェックボックス分のvalue値しか配列に格納されず、
配列の長さから「いくつチェックボックスを選択したか」しか判定できません。
チェックされないものは排除されてしまいます。
各行でチェックされたものとされないものの判定をする
いい方法はありませんでしょうか。
なお、JavaScriptで選択されてないチェックボックスのValueに
何かしらの値をセットして、選択されたものとの区別を測るという方法以外で。
JSPとForm,ActionFormの中でできる判定方法はないでしょうか？
0639nobodyさん
04/10/23 14:48:24ID:???0640nobodyさん
04/10/23 15:26:38ID:???0641638
04/10/24 11:10:44ID:???各行のFormを、それ自身のFormに配列形式で格納していくという方法でできました。
Form配列から一行分ずつのFormを取り出し、チェックボックスを判定。
各行のFormに含まれるチェックボックスのProperty変数は配列形式ではないので、
選択されていなくても変数のデフォルト値で判定可能というわけです。
>>640
multiboxも調べてみましたが、
チェックボックス以外の機能も含めてプログラム全体として考えると
自分の意図するものと少しずれていたので、今回はその方法はとりませんでしたが、
有益な情報サンクスです。
0642nobodyさん
04/11/08 00:14:18ID:Xgp3rIIQ取得したいと考えているのですが、何方かアドバイスいただけませんでしょうか？
選択している要素の取得方法はなんとなく分かるのですが、選択可能な要素を全て取得する方法が思いつきません。
出来ればJavaScriptは使わない方向で考えているのですが...
よろしくお願いいたします。
0643nobodyさん
04/11/08 00:17:56ID:???0644nobodyさん
04/11/08 00:24:59ID:???なんかよくわかんないが…
<select 〜>
<option value="value1">str1</option>
<option value="value2">str2</option>
…
</select>
の(value1,str1),(value2,str2)…みたいのが欲しいって事？
だとすれば、そもそも、そのフォームをＶする際のＭにその情報が有るでしょ。
それにアクセスすれば良いんじゃないの？
0645nobodyさん
04/11/08 00:27:48ID:???JavaScriptでhiddenタイプの変数として、カンマとかで値を結合して渡すとかは
思いついたのですが、もっと楽な方法があるだろう...と。
0646nobodyさん
04/11/08 00:33:22ID:???レス、ありがとうございます。
<SELECT>の要素は画面で追加・削除が行えるようにJavaScriptで組んでいるため、
<OPTION>の内容や数は変わることが前提となっているのです。
先ほど645で書いた方法程度であれば何となく考えているのですが、
何かございませんでしょうか？
0647nobodyさん
04/11/08 01:23:50ID:???0648nobodyさん
04/11/10 11:25:30ID:???<logic:iterate〜で、Beanに設定したテキストボックスの初期値は、正しく表示されているのですが、
テキストボックスの値を変えてsubmitしても、Actionで入力値が取得できません。
なにか思いつく原因などがあれば教えてもらえないでしょうか？
よろしくお願いします。
0649nobodyさん
04/11/10 14:33:28ID:qbk8LNSWよろしかったらもうすこし具体的にやり方を
教えてもらえないでしょうか。
今同じような事をやってつまっております。
0650nobodyさん
04/11/10 23:25:11ID:???やり方は2種類。
前提として、BeanにString id、String nameっていうフィールドがあるとして。
1. フィールドの配列で受ける。
<logic:iterate id="bean" 略>
<html:text name="bean" property="id"/>
<html:text name="bean" property="name"/>
</logic:iterate>
こういうJSPを書いて、この値が入るActionFormのフィールドに
String[] id と String[] name、およびそれぞれのアクセサメソッドを
用意しておけば、上から順番に値が格納される。
2. Beanの配列で受ける
<logic:iterate id="bean" 略>
<html:text name="bean" property="id"indexed="true"/>
<html:text name="bean" property="name"indexed="true"/>
</logic:iterate>
こう書いておいて、ActionFormにBeanの配列（もしくはList）と、
setBean(int index) を用意しておけば、Beanの配列として値が入る。
0651nobodyさん
04/11/11 05:13:30ID:hiuJkdtgstrutsのViewの部分をVelocityで実装してみるのは
有効なんですかね？
0652nobodyさん
04/11/11 05:23:51ID:???JSPとVelocityの違いは、XMLタグで制御構造を書くかそうではないかだけかと。
オーサリングツールが使いにくいとかブラウザでのプレビューがやりにくいとかじゃなければ、JSPの方がいいと思われ。
タグファイルとか考えると、JSPの方が便利だし。
0653649
04/11/12 14:00:22ID:???やり方としてはデータ用に作成したbeanの中に
indexを持たせてsubmit時にindexの値の配列を取得して
その他フィールドの値をindexをキーにして取得しています。
他にいい方法があれば教えてください。
やりたいことは、下記の通りです。
検索条件に従ってデータベース検索して結果を一覧表示する。
この際、各行にチェックボックスを作成する。
submit時にチェックボックスにチェックが入ったデータのみを
対象にある処理を行なう。
0654nobodyさん
04/11/23 00:13:58ID:???{0} が含まれている場合に
その {0} を入力された文字列に置き換える方法はないでしょうか？
たとえば、「入力された値は {0} ですが、その値は無効です。」とかいう
メッセージを表示したいのです。
書籍や Web サイトなどでは、固定文字列に置き換える方法ばかりしか見かけないので・・・。
0655nobodyさん
04/11/23 03:25:21ID:???試してないし君のValidatorのコードもわからないので適当書く。
たぶんActionErrors(ActionMessages)に
ActionError(ActionMessage)を追加してるところがあるとおもうけど、
後者は特にResources.getActionError()で取得する必要はなくて
ActionError(ActionMessage)でさえあればいい。
0657nobodyさん
04/11/23 11:22:18ID:???0658654
04/11/23 15:55:19ID:???それでは不可能、ということなんですね。
ありがとうございます。
0659nobodyさん
04/11/27 21:22:47ID:???ActionForm の代わりにPOJOを用いる方法を書いてるが、
こっちのスレの住人は使ってるのかな？
0660nobodyさん
04/11/29 21:50:18ID:???保守する身にもなってくれ。
0661nobodyさん
04/12/01 00:29:13ID:???0662nobodyさん
04/12/01 02:32:32ID:???0664nobodyさん
04/12/01 02:46:08ID:???DynaValidatorActionだといいの？
>>663
△△さらにStrutsの良さを教えて下さいSession3
http://pc5.2ch.net/test/read.cgi/tech/1088870989/
0668nobodyさん
04/12/02 12:22:43ID:???フィールド定義して、右クリックしてツールにセッターゲッター生成してもらって、XDocletタグを書くだけ。
あまりめんどくさくない。
0669nobodyさん
04/12/02 20:36:12ID:???いろいろそれ用の設定も必要だし
前準備だけでめんどくさいです
0670nobodyさん
04/12/02 20:47:10ID:???それなら、Struts使う必要もあまりなさそうだけど。
0672nobodyさん
04/12/04 02:23:43ID:???0673nobodyさん
04/12/04 15:46:09ID:???できますか？
@struts.actionと@struts.action-forwardを一つのクラスに複数個書いてみたら、
actionが複数できることは確認できたのですが、action-forwardが両方のactionの中に
入ってしまい、期待した動作はしませんでした。
みなさん、こういう場合ってどうしてますか？
それとも、一つのアクションクラスを使い回すってのがマズいんでしょうか？
0674nobodyさん
04/12/04 19:54:03ID:???マスタメンテとか一覧とか、共通のActionを使うことは多いと思う。
その場合は手書きになるね。
基本的にXDocletはシングルトンなクラスとValueObjectにしか適用できない気がする。
0675nobodyさん
04/12/11 02:21:47ID:???ビジネスロジックだけ分離させてそれを各アクションで呼べばいいだけだろ？
もしかしてActionクラスに処理べた書きか？
おまえらStrutsのこと全然わかってなさすぎ
@ITの山田と同レベルだな
0677nobodyさん
04/12/11 14:35:35ID:???ひょっとしてアクションクラスはクラスはModelだと思ってるの？
そうじゃなきゃそんな発言しないよね。
Controllerだと知ってたらそんな発言しないよね。
0678nobodyさん
04/12/11 20:35:55ID:???0679673
04/12/12 01:17:05ID:???今回は結局struts-actions.xmlでマージすることになったんですが、やはりアクションの使い回しはしないものなのでしょうか。
サーバサイドは初めてで、最近サーバサイドでのMVCの定義とクライアントでのMVC(というよりもプラットホーム準拠の作法)との差を感じることが多いです。
ロジックはModelに入るものということなのでしょうか。
僕の認識だと
M: データ構造
V: プレゼンテーション
C: データ操作のロジック
なので、同じロジックを複数の場所から実行して、別の結果ページに遷移したい時にはアクションを使いまわすべきか、と思って上の質問に至ったわけなんですが...
ちなみに、再利用性には気を配っているつもりですが、基本的にアクションクラスに処理べた書きです。
こういうことってStrutsやWebアプリの作法に反するっていうことなんですかね？
0680nobodyさん
04/12/12 01:46:09ID:???君の認識はどうでもいいからさ、ひとかけらでも疑問を持ったならちゃんと調べてくれよ。
ttp://e-words.jp/w/MVC.html
メインの処理はModelに実装し、Modelは画面出力などは行なわない。処理結果はViewに渡され、画面表示などが行なわれる。ユーザからの入力はControllerが受け取り、何らかの処理が必要な場合はModelに依頼し、出力が必要な場合はViewに依頼する。
知らない用語を自分用に解釈して使うことに何で疑問を持たないのかね。
0681nobodyさん
04/12/12 01:50:11ID:???0682nobodyさん
04/12/12 01:57:59ID:???Strutsは「MVC」の「C」だけを受け持つフレームワークだ。
それ以外のことはサポートしてくれない。
基本的にはViewもModelも自力で何とかする必要がある。
ここまで書けばわかるだろ？
0683nobodyさん
04/12/12 02:48:56ID:???> ちなみに、再利用性には気を配っているつもりですが、基本的にアクションクラスに処理べた書きです。
アクションクラスにロジックを書いてはいけない理由はないし、それはアプリケーションの規模や性質によるから一概にいえるものではない。
MVCという分け方があるとしても、CにMを併用するモデルを採用しようが、それは設計者の自由。
別のクラスにしないといけない理由はない。
メンテナンス性などを考えて最適であると判断できるならどうでもいい。
っていうか、処理するテーブルと入力フォームだけが違う場合にActionを共通化するようなことは普通にある。
0684nobodyさん
04/12/12 03:13:43ID:???アクションクラスにべた書きの時点で、再利用性には気を配っていないと言える。
そもそも、基本的にControllerは受け渡しのみを行ういわば使い捨てであり、それを再利用しようとする方が間違い。
あくまでも処理はModelで行う。
＞MVCという分け方があるとしても、CにMを併用するモデルを採用しようが、それは設計者の自由。
これはMVCではない。MVCを無視して
「Strutsを使ってとにかくアプリケーションを作る」ことに専念するつもりなら当然何をやろうが自由だが
MVCを意識する以上は間違い。
＞っていうか、処理するテーブルと入力フォームだけが違う場合にActionを共通化するようなことは普通にある。
自分の周りが全て正しいのか？
何も考えず周りに流されてるだけで、ちゃんとStrutsやMVCモデルについて勉強してない証拠だな。
それは単なるローカルルールだ。
要するにおまえは井の中の蛙だ。
0685nobodyさん
04/12/12 03:22:46ID:???自分だけうまい具合に自動生成できない時点で
「俺のプログラムはどこかアブノーマルな部分があるのかな」
とか気にしたんだろ？
それで>>673に書いたんだろ？
で、それに対する答えが「確かに君のやり方はアブノーマルな部分があるよ」だったわけだよ。
質問に対する回答を貰っておいて、それでもなぜ納得しないんだ？
0686nobodyさん
04/12/12 04:16:09ID:???htp://struts.apache.org/userGuide/building_controller.html#action_design_guide
って、上でも出てるし。
同じようなやりとりが定期的に出ている証拠だな
0687nobodyさん
04/12/12 04:46:15ID:???継承してちょっとした変更するより、同じクラスでパラメータによってちょっと動きを変えるほうがいいと思うが。
Actionなんて、再利用できるなら再利用した方がいいとおもうのだが。
> 要するにおまえは井の中の蛙だ。
自分がどんな井戸の中にいるのか把握してないみたい。
0690nobodyさん
04/12/12 11:19:21ID:???0691nobodyさん
04/12/12 11:37:13ID:???っていうか、別にActionにロジックを書いても当然動くけど、
（実際、ビジネスロジックと分離するかしないかの違いだし）
そういった使い方をするなら>>684にあるとおりMVCを持ち出すべきではないよね。
「CにMを併用するモデル」が既にMVCじゃないんだから。
入力パラメータが同じなのでActionFormを使い回したい、みたいな事はあるけどね。
>>687
どこから継承なんて言葉が出てきたんだ？
意味がわからん。
おまえの頭の中ではどんな作りになっているんだ？
0692nobodyさん
04/12/12 12:04:37ID:???0693nobodyさん
04/12/12 12:37:56ID:???MVCモデルは、意識して厳密にやろうとしないと>683のようにすぐに
曖昧になって混ざってしまいがちだから、頑固とは違う。
少なくとも>684の書いていることはまともだし、
>「Strutsを使ってとにかくアプリケーションを作る」ことに専念するつもりなら当然何をやろうが自由」
とあるとおり、「絶対にActionにロジックを書くな」と書いているわけでもない。
単にMVCモデルには則してないと書いているだけ。
こういうのは頭でっかちで頑固、とは言わないよ。
あと「基礎は知っていた上で多少は融通が利く」というより単なる「妥協」だね、この場合。
0694nobodyさん
04/12/12 16:26:36ID:???0695nobodyさん
04/12/12 16:31:33ID:???XDocletは基本的にシングルトンなクラスにしか便利に使えないし。
XDocletでうまく対応できないからといって、Struts側の設計としておかしいと考えるのは筋違い。
0697nobodyさん
04/12/12 16:59:50ID:???あの議論はいったい何だったんだという感じ。
せっかく記事を版管理無しでこっそり修正したのに
意味無かったね山田さん
0700nobodyさん
04/12/12 17:28:19ID:???M=ActionForm
V=JSP
C=Action
のことじゃなかったの？
0701nobodyさん
04/12/12 18:06:07ID:???ＭＶＣっていっても、Ｖの中にもＭＶＣ、Ｃの中にもＭＶＣ。
見る尺度によって、どこのレベルでもＭＶＣ．
0702nobodyさん
04/12/12 19:08:08ID:???0703nobodyさん
04/12/15 18:26:48ID:6uCmJkm40704nobodyさん
04/12/15 22:19:35ID:???
■ このスレッドは過去ログ倉庫に格納されています