- 1 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 14:34:57 ]
- JSFについて語ってくれ
前スレ
JSF(JavaServer Faces)【.NET死亡？！！！】
pc8.2ch.net/test/read.cgi/tech/1059208396/l50
- 411 名前：デフォルトの名無しさん mailto:sage [2007/07/18(水) 19:22:56 ]
- >>410
> 項目ごとにバリデータクラスがある
JSF 1.1だよな？
項目ごとにバリデーションエラーのメッセージを変える必要があるなら、
それ以外にうまい方法はなさそうだぞ。
> しかもセッションタイムアウトの設定を24時間に
> すごい勢いでOutOfMemoryです・・・
それくらいでメモリ不足になるかね？
1万セッション×100KBでも1GB。
AP鯖ならそれくらい積めよと思う。
しかしJSFはログイン処理が標準化されてないのが
嫌だね。
include-preludeでsession変数とクッキー見るのが
一番？
- 412 名前：デフォルトの名無しさん mailto:sage [2007/07/18(水) 19:49:52 ]
- まぁマネージドビーンになんでもかんでもデータ突っ込んでたら
すぐ何十MBにもなってしまうわな。
sessionにどういうデータをどのようにぶら下げるかあまり意識
しなくてもいいというのがJSFの利点でもあるわけだが。
- 413 名前：デフォルトの名無しさん mailto:sage [2007/07/18(水) 21:23:47 ]
- メモリ不足は無いと思うけど、問題はGCじゃない？
無駄にオブジェクトの寿命を長くしたら、
Old GCが頻発して、あまりよくないような気がするなぁ。
ハードウェアのスペックを上げれば、要求性能は満たせるかもしれないが、
糞設計のためにハードウェアコストが上がる、というのが納得がいかない。
ハードウェアに金掛けた分、開発で手を抜いて開発費押さえて元を取る、
というのが近年の流れというのは分かるけど、
同じ工数で負荷の低い設計ができる、というのが分かるだけに、
タコな技術者のせいで顧客に余計なコストを背負わせていると思えてくる。
JSFは使ってないが、なんでもかんでもセッションに入れる設計のWebアプリの開発に関わった時にそう思った。
高価なPCサーバ（はっきり言ってイントラ向けにはオーバスペック）を使ってて、
その有り余る性能がこんな糞設計を吸収するために使われるのかと考えると、
正直お客さんに悪いような気がした。
- 414 名前：デフォルトの名無しさん mailto:sage [2007/07/18(水) 22:29:50 ]
- クラスタしなくてもセッション情報のディスクI/Oってあるんだっけ？
少なくともセッションレプリケーションのコストで、全然スケールしなさそう。
- 415 名前：デフォルトの名無しさん mailto:sage [2007/07/18(水) 23:34:49 ]
- 漏れもよく理解してJSF使っているワケではない素人だけど
>バリデータは独自実装で、項目ごとにバリデータクラスがある
>バリデータクラスは使うたびにnewしないとならない
独自実装する必要がたぶんあったんだと好意的解釈をしたとしても
なんちゃら.xmlに記述すればソースでnewとかしなくても、タグに
そのクラス記述しとけば使えなかったか？
managedBeanってあんましコンストラクタでどーこーしようとは思わんけど
ログイン判定をコンストラクタでやろうとする発想が凄いな。
とか言いつつもどこでやるのが適切か？と言われるとうまく答えられんけど。
漏れはmanagedBeanにフィールドで持たせていて、
判定はDB鯖にアクセスする時に例外が発生したら・・・、とかやってるけど。
- 416 名前：デフォルトの名無しさん mailto:sage [2007/07/18(水) 23:47:44 ]
- ログイン判定ってFilterでやるもんじゃないの？
- 417 名前：デフォルトの名無しさん mailto:sage [2007/07/20(金) 10:03:51 ]
- >>411
項目ごとにメッセージ変えるからって個別にクラス作るなんてどんだけアホな設計だよ
しかも一分間に7セッション弱ってかなり小さすぎだろ、システム的に
- 418 名前：デフォルトの名無しさん mailto:sage [2007/07/20(金) 13:16:45 ]
- メッセージが指定できるクラスを作るでござる
- 419 名前：デフォルトの名無しさん mailto:sage [2007/07/20(金) 13:23:56 ]
- >>413
逆に考えるんだ、「高コストの技術者を長期に使うよりは安い」と考えるんだ
- 420 名前：デフォルトの名無しさん mailto:sage [2007/07/22(日) 02:06:10 ]
- >>417
> 項目ごとにメッセージ変えるからって個別にクラス作るなんてどんだけアホな設計だよ
JSFの設計者に言えよ。
1.2では微妙に直ってる。
それでもまだ、エラーの原因ごとにメッセージを変えるには個別にクラスが
必要。
> しかも一分間に7セッション弱ってかなり小さすぎだろ、システム的に
ユニークビジターが毎日1万人くるサイトなら真面目にやれ、としか。
ひょいと「お前これやれ」と投げて引き継ぎ終了、そんなんで
まともなコードが出てくるわけがない。
- 421 名前：デフォルトの名無しさん [2007/07/22(日) 18:14:04 ]
- >>410
>なお、マネージドビーンは全部セッション
JSC開発したら，デフォルトでマネージドビーンのスコープはセッションになるからな．
JSFってそういうもんだと思ってしまう．
- 422 名前：デフォルトの名無しさん mailto:sage [2007/07/22(日) 18:28:10 ]
- セッションは 24 時間でもいいが、
5 分でディスクに永続化されるようにすればいい。
Tomcat とかデフォルトで永続化されると
思ってるバカが多いからな。
- 423 名前：デフォルトの名無しさん mailto:age [2007/07/28(土) 17:12:33 ]
- ここで聞くこっちゃないけど、Click Frameworkのスレってないよね？WebProg板にも。
今までずっとJSF使ってきたけど、最近Clickを試してみたらperlでcgi書くみたいに
サクサク書けるんで感激した。
- 424 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 23:04:07 ]
- Wicket とどっちがいい？
- 425 名前：デフォルトの名無しさん [2007/07/30(月) 16:19:38 ]
- Wicket、いつのまにかApacheのプロジェクトになってる…
- 426 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 07:34:34 ]
- Wicket こそ正解。
所詮、設定ファイルなど無力よ。
- 427 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 11:49:47 ]
- Ymir いいぜ。
Seasar 系で初めていいと思った。
JSF や Wicket 見てもなんだかなー、俺様フレームワークを
作りたい衝動を抑えてきたが、Ymir は思想的に完璧だ。
完全に俺様の考えとオーバーラップする。
動かしてねーけど。
- 428 名前：デフォルトの名無しさん mailto:sage [2007/09/12(水) 13:38:43 ]
- 427見たいな自己中なやつの作る
- 429 名前：デフォルトの名無しさん mailto:sage [2007/09/12(水) 13:40:09 ]
- 427見たいな自己中なやつの作るフレームワークで開発するやつらかわいそうだな。
こーゆーやつの作るフレームワークって大概思想押し付けのオナニーフレームワークだし
- 430 名前：デフォルトの名無しさん mailto:sage [2007/09/13(木) 02:37:23 ]
- どうした？ 嫌なことでもあったのか？
- 431 名前：デフォルトの名無しさん mailto:sage [2007/09/13(木) 03:34:40 ]
- ああ。思想押し付けのオナニーフレームワークを作る奴がいてだな
- 432 名前：デフォルトの名無しさん mailto:sage [2007/09/13(木) 06:41:21 ]
- それを言い出すとStrutsもオナニーから始まったと思ったが。
- 433 名前：デフォルトの名無しさん mailto:sage [2007/09/13(木) 15:53:34 ]
- 独善的でない設計は総花的。
総花的な設計はみんなが「いーんじゃね？」と言ってくれる。
そして誰も使わない。
独善的な設計は信者が使う。
そして信者以外の奴も使わされるようになる。
- 434 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 03:24:43 ]
- そもそも思想押し付けんのがフレームワーク。
- 435 名前：デフォルトの名無しさん [2007/10/18(木) 01:28:26 ]
- <h:inputText id="hoge1" value="#{bean.foo}" />
<h:inputText id="hoge2" value="#{bean.foo}" />
inputTextのidに上記の様に連番をつけたいのですが、
何か方法はないでしょうか？
<h:inputText id="hoge"<%= i %> ... />
とか、式を書くと怒られます。
- 436 名前：デフォルトの名無しさん [2007/11/04(日) 19:28:07 ]
- NetBeans6はVisualWebが独立したプロジェクトじゃなくて
strutsやJSFのようにフレームワークを選択するようになったね
Tomcatが標準で６になってJSFも1.2が使いやすくなったし
地味ーによくなりつつあるか
- 437 名前：デフォルトの名無しさん [2007/11/08(木) 03:35:18 ]
- MyFaces もJSFもまぁ使えるようになってきたわ。
彼らの努力じゃなくて、各現場の努力だけどね
- 438 名前：デフォルトの名無しさん mailto:sage [2007/11/08(木) 06:42:39 ]
- なんか使わせてもらってる立場のクセに妙に偉ぶるヤツいるよなｗ
- 439 名前：デフォルトの名無しさん mailto:sage [2007/11/09(金) 01:27:13 ]
- >>438
お前のことか？ｗｗｗ
- 440 名前：デフォルトの名無しさん mailto:sage [2007/11/09(金) 08:37:40 ]
- どう読んでも>>437のことだろ
- 441 名前：デフォルトの名無しさん mailto:sage [2007/11/09(金) 09:22:22 ]
- 皮肉を理解できないのか、空気を読めないのか、あるいは本人なのか。
- 442 名前：デフォルトの名無しさん mailto:sage [2007/11/09(金) 21:38:35 ]
- >>435
ID属性を動的に設定できないのは仕様なのかな？
自分は、どうしようか悩んだ挙句、classに動的に設定した後、
onloadで呼び出したJavaScriptでclassからIDに振り替えるように実装したが・・・
- 443 名前：442 mailto:sage [2007/11/09(金) 21:42:12 ]
- すまん、>>435の例はformのタグだから、IDを自分のやり方で変えちゃまずいかも
formのタグってJSFが勝手にID振ってた気がするし
- 444 名前：デフォルトの名無しさん mailto:sage [2007/11/09(金) 23:37:14 ]
- 自分でcomponent作ってbindingしてやるとか？
試してないからsetId()したのがちゃんと有効になるかどうかは知らん。
- 445 名前：デフォルトの名無しさん [2007/11/10(土) 01:36:04 ]
- >>442
IDは開発時にわかるからそれを使ってscript組むしかない
かってにIDいじっちゃうとデコードとかで問題になるはず
setIdはhtmlのIDとイコールではないよ
でも連番は可能
というか、テーブルはRowで連番ふってる
- 446 名前：デフォルトの名無しさん [2007/11/11(日) 13:42:02 ]
- JSFだとテーブルつくるとき、columnspanつかえないんですけど、
方法あるのでしょうか？
あまりにしょぼくて困っています
- 447 名前：デフォルトの名無しさん mailto:sage [2007/11/11(日) 13:49:26 ]
- 静的なテーブルで良いなら、htmLib.jarが重宝する
- 448 名前：デフォルトの名無しさん [2007/11/11(日) 15:01:14 ]
- >>446
セルは１つにしてグリッドレイアウトとかやるのがいいと思う
- 449 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 02:32:56 ]
- 質問です。
<h:dataTable>ってヘッダのスタイルをカラム毎に指定できないじゃないですか。
で、行（表示するデータ用）のスタイルはカラム毎に指定できるから、
それぞれのカラムに最適な幅を指定するんだけど、
１行も表示してない状態（ヘッダのみの状態）だとカラムの幅が適当な幅に
なっちゃいますよね。（当たり前だけど行のスタイルが適用されない）
コレが「行あり」→「行なし」とページを切り替えるとズレるのがモロバレなんで
なんとかしたいんですが、いい方法はないでしょうか？
- 450 名前：デフォルトの名無しさん [2007/11/23(金) 12:43:37 ]
- >>449
ヘッダにグリッドパネルをセットするといい
テキストはその中へ入れたり
そうすると1つのセルに複数のコンポーネント入れたり画像入れたり自由に出来る
- 451 名前：449 mailto:sage [2007/11/23(金) 18:49:35 ]
- >>450
なるほど。ちょっとやってみます。ありがとう。
- 452 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 19:04:33 ]
- JSF初心者の素朴な疑問：
1. なんかブラウザで表示されるURLと、実際に表示されるjspが違うんだけど、これってなんで同期できないの？もし仕様ならすごく不自然だと思うんだが。
2. HTMLのソースを見ると、入力したデータがシリアライズ(?)されてhiddenタグに埋め込まれてるみたいなんだけど、これってセキュリティ的にまずくない？そもそもなんでそんなことする必要があるの？
- 453 名前：デフォルトの名無しさん [2007/11/23(金) 22:15:36 ]
- >>452
１と２に共通するものとして・・・
URLベース（アクションベース）のHTTPとHTMLを抽象化していないものと
イベントベースとは考え方が違う
URLに機能があるのではなくあくまでもWEBの上で動かしたからURLがついてきたと思えばいい
もしURLに機能を割り当てたいという旧世代の開発者ならPost後RedirectするようにJSFのconfigにタグを入れるといい
その代わりなんでもかんでもセッションにいれないとだめでそれを取り出すロジックとか作りこんでいくとバグが増えたり
メモリを圧迫することになるかもしれない
JSFはコンポーネントを復元する機能がある
この機能のおかげで前の画面で入力したものにミスがあった場合それを使って戻したり変更を検地できる
入力項目を反映させつつ、セッションを使わないで値を保存しておくことが可能
ちなみにデフォはsessionだったと思うけど、NetBeansVisualWebとかCreatorとかはデフォをclientで上書きしてるね
web.xmlをみるといいよ
「javax.faces.STATE_SAVING_METHOD」とかあるはずだから
- 454 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 22:32:38 ]
- >>453
それを補完するためにJBoss Seam（WebBeans）などもあるよ。
.NETはデフォでそうしているね。
- 455 名前：452 mailto:sage [2007/11/23(金) 23:07:12 ]
- >>453
>URLベース（アクションベース）のHTTPとHTMLを抽象化していないものと
>イベントベースとは考え方が違う
>URLに機能があるのではなくあくまでもWEBの上で動かしたからURLがついてきたと思えばいい
どうなんだろう。少なくともJSFでは表示画面とURLとが一致しなくても構わないというスタンスということ？
そうだとすると、ブックマークするときに困ると思うんだけど。ブックマークを許さないアプリしか作れない？そんなはずはないと思いたい。
それから、イベントベースのフレームワークだと、どれもJSFのようにURLと画面が一致しないものなの？イベントベースかどうかはあんまり関係ないと思うんだけど。
>もしURLに機能を割り当てたいという旧世代の開発者ならPost後RedirectするようにJSFのconfigにタグを入れるといい
別に「URLに機能を割り当てる」とか考える必要あるのかな？おれは、URLはリソースを表すものだと思うんだけど。
URLと機能とを結びつけてるわけじゃなくて、画面に表示されているリソース（HTML）とURLとが一致していないことが問題なんじゃないかな。
>その代わりなんでもかんでもセッションにいれないとだめでそれを取り出すロジックとか作りこんでいくとバグが増えたり
>メモリを圧迫することになるかもしれない
それをかわりにやってくれるのがフレームワークじゃないか。
- 456 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 23:11:47 ]
- MyFacesなんかの実装だとForwardベースでやるとブックマークできないね。だからRedirectで実現することもある。
Formの送信なんかを考えると機能という呼び方もおかしいとは思わない。
なんか455がすげームカつく。
- 457 名前：452 mailto:sage [2007/11/23(金) 23:16:31 ]
- >>453
>JSFはコンポーネントを復元する機能がある
>この機能のおかげで前の画面で入力したものにミスがあった場合それを使って戻したり変更を検地できる
>入力項目を反映させつつ、セッションを使わないで値を保存しておくことが可能
だから、これだとセキュリティ的にまずくない？
HTTPヘッダーでCacheをオフにさせても、HTMLページに前の入力結果が勝手に残っているわけでしょ？
シリアライズされているからパッと見ただけではわからないけど、すごく気持ち悪い気がするのは俺だけ？
なんかさ、「前の画面で入力したものにミスがあった場合それを使って戻したり変更を検地できる」っていうの、この方法じゃないとできないのかな。
こんなの、普通のCGIアプリケーションでもできるよね。
- 458 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 23:18:29 ]
- REST志向か強すぎることによるギャップでしょ。
あなたはJSFを使う事も出来れば、使わない事もできる。
よくある回答だがそういうことさね。
- 459 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 23:24:22 ]
- >>457
私はセキュリティ的にまずくないと考えますが、あなたはどうまずいと思いますか？
- 460 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 23:29:06 ]
- RESTとJSFは絶望的に合わないと思う
HTTPを基礎とする志向に対し、HTTPを隠蔽するFWだから
REST志向で作りたいならRails等を検討した方がいい
- 461 名前：デフォルトの名無しさん [2007/11/24(土) 00:00:48 ]
- >>457
文章は最後まで読めよ
- 462 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 00:02:40 ]
- >>457
そのcgiってのは入力項目の変更があった場所とかに応じて自動的にバリデータとかイベントでのプログラミングできるの?
なんか生臭いコードかいてそうだけど
- 463 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 08:19:43 ]
- JSFを使う様な場面でブックマーク使うなんて事ない思うが。
ログインページやトップページ以外でブックマークされても困るケースの方が
ほとんどだろうし。
そしてURLと画面が一致しないのはあんま気にならないと言うか
誰が気にするんだ？って思う。
とりあえずユーザーはまったく気にしていなかったが。
- 464 名前：452 mailto:sage [2007/11/24(土) 11:22:08 ]
- >>458
>あなたはJSFを使う事も出来れば、使わない事もできる。
使うと決めた人しか質問しちゃいけないわけじゃないよね。JSFを勉強している中での質問なので、使う使わないの判断は関係ないと思う。
>>459
すでに>>457に書いてるけど、前の入力データが自動的に今のページに含まれることがセキュリティ的にまずいと思う。
登録完了ページにアカウントやパスワードのデータが残っていたらまずくない？
>>460
>RESTとJSFは絶望的に合わないと思う
>HTTPを基礎とする志向に対し、HTTPを隠蔽するFWだから
そうなのかな。HTTPを隠蔽するしないは関係あるんだろうか。
>>462
>そのcgiってのは入力項目の変更があった場所とかに応じて自動的にバリデータとかイベントでのプログラミングできるの?
462がどういうのを想像しているのか分かんないけど、自動的にバリデータがかかることと今回の質問とは関係があるの？
自動的にバリデータかかったりイベントベースでのプログラムが書けることと、URLやセキュリティのこととは関係なくない？
>>463
>JSFを使う様な場面でブックマーク使うなんて事ない思うが。
>ログインページやトップページ以外でブックマークされても困るケースの方が
>ほとんどだろうし。
だったら、URLをかえないか、ランダムなURLにすればいいと思う。
今のJSFの挙動だと、ユーザに大きな誤解を与えるだけにしか見えない。
とりあえずブックマークを許したいならJSF使ったらダメということでFA？
>そしてURLと画面が一致しないのはあんま気にならないと言うか
>誰が気にするんだ？って思う。
気にしない開発者がいることにびっくりだ。世の中はひろい。
- 465 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 11:42:55 ]
- >>464
>そうなのかな。HTTPを隠蔽するしないは関係あるんだろうか。
あくまで私見だが、とても関係あると思っている。
たとえば、JSFで作った画面のHTMLソースを見ても、
サーバのどのManagedBeanメソッドが呼び出されるかはなかなかわからない
その時点で、URLとHTTPメソッドで呼び出し先が決定されるREST的Webアプリとは
根本的に違うし、当然ブックマークの常識も通用しない
だから通常のWebアプリの常識で考えるとありえないって結論になる。
個人的にはJSFのこの仕組みは嫌いだが、仕事で使っている以上一通り勉強している。
- 466 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 13:51:47 ]
- >気にしない開発者がいることにびっくりだ。世の中はひろい。
このスレじゃないしJSFでもないけど、
「それじゃユーザーが混乱するのでは？」みたいな書き込みしたら
そもそもなんでそんなこと気にするのかわからないっていうレスばかりで
自分もビックリしたことがある。
とにかく「自分の責務の範囲外のとこは関与しない」っていう文化が浸透してるみたい。
- 467 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 14:25:21 ]
- 関東はその傾向が強いね
- 468 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 14:29:32 ]
- >>464は>>461を無視かよ
解決方法のポインタしめしてるのに
- 469 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 14:33:51 ]
- ＞だったら、URLをかえないか、ランダムなURLにすればいいと思う。
どっちも出来るはずだから喪前が好きに実装すればいいのでは？
＞今のJSFの挙動だと、ユーザに大きな誤解を与えるだけにしか見えない。
＞とりあえずブックマークを許したいならJSF使ったらダメということでFA？
なぜにそんな極論になるのか知らんが、ユーザーに文句言われて
喪前の技量ではどうしようもないなら、そうすれば？
＞たとえば、JSFで作った画面のHTMLソースを見ても、
＞サーバのどのManagedBeanメソッドが呼び出されるかはなかなかわからない
ソース見て、どのBeanが呼び出される方が解る方が大問題だろ。
仕事で使っているとか言いながら、持論は壮絶にアマチュア精神丸出しだな。
- 470 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 14:40:51 ]
- >そもそもなんでそんなこと気にするのかわからないっていうレスばかりで
>自分もビックリしたことがある。
そりゃ、底辺のマにありがちな「どーでもいい事は熱心クセに
実際の生産・成果物がショボイ」って上の方が辟易している状態だろ。
- 471 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 14:41:01 ]
- Railsだって勝手にブックマークされるとまずい・・・っていうか問題ある場所なら
セッションなかったら入り口に戻すとかするだろうと
- 472 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 14:42:06 ]
- >>452は全てにおいて勘違いしてるな
- 473 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 14:52:03 ]
- 気になる奴はREST志向が強いだけで結論付いてるじゃん。
JSFにとってURLはイベントメッセージ、RESTにとってURLはコマンドライン引数。
普通のアプリケーションとなんら変わらないと思うんだが。
- 474 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 14:52:39 ]
- しかし、そんなに入力データ云々言うならセッションに入れとけよ、って思うんだが
なんで、病的にフレームワークの性にしているんだ？
- 475 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 14:55:54 ]
- >>473
しかもredirectいれとけばURLベースと動きがかわらんのにな
- 476 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 15:02:07 ]
- でもURLって重要だよね。
ブックマークや検索エンジンのインデクサに登録されたら
もう基本的に自分のところではコントロール不能で面倒だし。
半永久的にリダイレクトとかのフォローしないといけなくなる。
あとフィッシングサイト対策とかブラクラなんかの影響で、ユーザーも
ブラウザのアドレス欄に表示される文字列に気にするようになってると思うし。
できれば短ければ短いほうがいいよね。
- 477 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 15:11:02 ]
- servletでいうdomain/context/servletまでが分かれば、
それ以降に何が付こうがどうでもいいんだが。
- 478 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 16:58:38 ]
- >>476
自作自演乙
- 479 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 17:06:32 ]
- そんなにヤならJSF使わなきゃいいじゃん。
上司に2chのこのスレ見せて「漏れが452です！漏れの言っている事正しいですよね！」
って力説すれば、上司は快くオマエをプロジェクトから外してくれるだろうから、
嫌なJSFを使わなくてすむぞ。w
- 480 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 17:09:30 ]
- そおいや、検索エンジンって拡張子が.jspやらjsfは拾わない気がしたんだが、
どこぞのエンジンは拾うのか？
- 481 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 17:33:00 ]
- >>480
inurl:index.jsp - Google 検索
www.google.com/search?q=inurl%3Aindex.jsp
inurl:index.jsf - Google 検索
www.google.com/search?q=inurl%3Aindex.jsf
拾いまくり
- 482 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 18:40:08 ]
- googleの結果だと別にurlとられても問題ないケースに見えるんだが
452はナニが不満なんだ？
- 483 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 18:47:43 ]
- 末端の仕事してる者同士仲良くしろ
- 484 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 19:07:26 ]
- >>482
それはindex.jsfだから。
.jsfで検索するとカッコ悪いURLたくさん出てくるよ。
そもそもJSFがあまり使われてないから探すの面倒くさいけど。
- 485 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 19:10:08 ]
- www.google.com/search?q=site:store.americangirl.com+inurl:jsf&filter=0
なんかここ無茶なことやってるなあ・・・
- 486 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 19:14:12 ]
- まだ潜伏してんのかｗ
- 487 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 19:22:22 ]
- 何が理由で工作してるんだろう・・・
- 488 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 19:30:19 ]
- Servlet自体はRESTのことちゃんと考えて規格を調整してきたし（HTTP METHODあたり）
各WebコンテナベンダもCometに対応できるようにコンテナを改造している。
JSFに粘着しないで他をあたればいいのだよ
- 489 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 20:01:19 ]
- URLがどうのって奴はフォワードを一切許容しないってこと？
JSFに限らずほぼすべてのservletアプリケーションがダメってことじゃん。
- 490 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 21:00:52 ]
- servletにすら限らないけどな
POST先をどこにするかだけの話だから
- 491 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 22:27:31 ]
- 452は今までどんな環境でWebアプリ作っていたのか気になるな。
servletやRailsを知らんのは明白だし。
- 492 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 23:08:16 ]
- >>475
JSFのリクエスト保持データってredirectで引き継がれたっけ？
TeedaやRailsなら対応してるけど、素のJSFはforward前提のFWだという認識だったのだが
- 493 名前：デフォルトの名無しさん mailto:sage [2007/11/24(土) 23:14:12 ]
- >>492
Servlet直、Struts、SpringMVC
ともに処理はRedirect前にやるからredirect後特殊な処理をしたいのなら普通にsessionからとりだすんでそ？
redirect先でリクエスト使うって処理はどのフレームワーク使ってもないよ
- 494 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 01:14:46 ]
- >>489
> JSFに限らずほぼすべてのservletアプリケーションがダメってことじゃん
どういう極論だよ。
redirect-after-postでやってるWebアプリなんて普通にあるじゃん。
- 495 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 01:54:42 ]
- 常に一つ前の状態がほしければセッションビーンにリクエストビーンのセッターゲッター用意して上書きさせればいいだけ
- 496 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 07:47:56 ]
- >>493
ここ読んでると、みんな普通にJSFでredirect使ってるんだね。自分の勉強不足だったのか
普通のWebアプリだと、例えばPOSTで登録したあとそのデータを表示する為に
IDをパラメータ（かURL）で渡して詳細データを検索するURLにGETでredirect
みたいなことが普通に出来ると思うけど、JSFの場合どうやったらいいんだろう
session使えばいいのはわかるんだけど、
URL使うパターンでは手動での画面操作を介さない限りsessionって使わなくてもいいので
できるだけsessionには保持したくない
- 497 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 08:10:10 ]
- ＞ここ読んでると、みんな普通にJSFでredirect使ってるんだね。自分の勉強不足だったのか
ナニがどうあっても個人の異端な思考を「普通」と思い込みたい病人みたいな台詞だな
- 498 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 08:37:25 ]
- だからURLに文句がある奴はJBossSeam使えよ。
JavaEE6で標準仕様になるんだし。
- 499 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 08:37:30 ]
- >>497
ん？ なんでそんな敵意むき出しなの？
ちなみに>>452とは別人だぞ
- 500 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 08:39:52 ]
- >>498
素のJSFでは駄目ってこと？
SeamはステートフルSessionBean使いまくりってイメージがあったので敬遠していたのだが
そういや最近のバージョンはEJB3への依存が消えたんだっけ？
- 501 名前：デフォルトの名無しさん [2007/11/25(日) 09:52:38 ]
- 素のJSFってどこのJSF使ってんだよ。
仕事とかいいつつ趣味でやってんじゃねーのか？
このURL粘着君は。
仕事で商用鯖使ってんなら2chでなくてサポートに泣き付けよ。
- 502 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 10:20:41 ]
- >>501
MyFaces1.1系
自分が調べた限り、JSFのredirectはManagedBeanのメソッドを呼ぶような使い方が出来ないので
使い物にならないという結論を出していた。
でもこのスレでredirect使えばOKというレスが多かったのを見て
>>496の質問をしただけだよ
URL粘着って>>452あたりの話か？ 自分じゃないんだけど・・・
- 503 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 12:17:54 ]
- >>496
「普通のWEBアプリ」ってなんだよと思う
URLにパラメータをまったく乗せたくないからセッションに入れるという場合だってあるんだぜ？
- 504 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 12:48:10 ]
- ショッピングモールみたいなサンプルアプリ的なものは典型的だな。
- 505 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 13:38:24 ]
- まぁURLベースの典型ではあるが、用途によって最適解が違うというのも>>452は気がついてるんだろうか
- 506 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 14:53:03 ]
- なんかURL粘着が必死に他人のフリしているから話がややこしいよな。
やたら別人を強調しているし。
>>452の望む動作はJSFでも実装可能なのに、なんか必死に出来ない事にしたがって
「普通のWEBアプリ」って脳内理想をブチまかれてもな。
嫌なら使うなよ。
- 507 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 15:05:07 ]
- JSFのHTTPの使い方がRESTfulでないのもがいしゅつ。
とにかくMVCが偉かった時代の産物だからな。
頭を切り替えろと。
いまJSFが一番お勧めな用途ってのも思いつかない。
- 508 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 15:09:16 ]
- cgiの時代に戻っとけ、って事でFA
#漏れは戻りたくないが
- 509 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 17:07:38 ]
- >>507
JSFはJavaのフレームワークで一番イベントベースでの処理と入力検証が一番容易だから
開発効率と安定性を追求したい場合いいんじゃない？
- 510 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 18:55:57 ]
- >>509
その入力値検証が
>>411>>417>>420
という体たらくだからな。
JSFのバリデータをベースに作り込もうとしたら
保守不可能なシロモノができあがる。
NetBeansでポトペタできるのはメリットかな。
- 511 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 19:16:20 ]
- 項目ごとにエラーメッセージを分ける必要があるなら
UIコンポーネントのIDかClientIDで分けるようにすればいいのでは？
エラーメッセージはResourceBundleから読み込むようにして
ResourceBundleのキーにUIコンポーネントのIDかClientIDを含ませるようにするとか。
|
 |
