- 1 名前：デフォルトの名無しさん mailto:sage [03/07/26 17:33]
- スレがないので新しくたてました
www.atmarkit.co.jp/fjava/special/jsf01/jsf01.html
java.sun.com/webservices/downloads/webservicespack.html
- 449 名前：デフォルトの名無しさん [2005/08/19(金) 19:38:43 ]
- 携帯向けサイトにJSF使おうと思って調べてたら
h:formってPOSTしかないのね。
i-mode公式サイト作ってる人ってJSF諦め？
- 450 名前：デフォルトの名無しさん [2005/08/20(土) 12:46:38 ]
- >>449
単純に実装を行っているのがWebブラウザ向けばかりというだけのことです
JSF自体はクライアントは何でもいい
どこかが作ったi-mode用カスタムコンポーネントがなければ
自分で作るしかない
- 451 名前：449 mailto:sage [2005/08/20(土) 13:21:15 ]
- >>450
そっか。
JSF的にPOSTで受け取らないと何か動作に問題があるので
POST固定ってなってるもんだと勝手に思ってたよ。
ありがと探してみる。
- 452 名前：デフォルトの名無しさん mailto:sage [2005/08/20(土) 14:25:11 ]
- submitボタン二度押し対策で、
ttp://d.hatena.ne.jp/naoya/20050803/1123053496
の方法はうまく行きませんね。
この方法は、ASP.NETでもダメだったような記憶がある。
「LightWeightJava」の方法はうまく行くけど、
送信中にブラウザの中止ボタンを押すと、それ以降
submitできなくなる。
IE限定なら、document.readyStateが使えるんだけど。
- 453 名前：デフォルトの名無しさん mailto:sage [2005/08/22(月) 08:48:02 ]
- submitボタン押せなくするよりもonsubmitイベントでfalse返すほうが確実っぽい
- 454 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 13:25:22 ]
- アクションリスナの存在意義がわかりません。
・処理分岐が不可能
・必ず後でアクションメソッドが呼ばれる
それでもなお、ここはアクションメソッドで実装せず、
アクションリスナを使うべきだ！
という具体例があれば教えてください。
- 455 名前：デフォルトの名無しさん mailto:sage [2005/08/26(金) 00:27:57 ]
- 何か勘違いしてる気がするけど、それはそれとして、ヒント：イベントドリブン、EoD
- 456 名前：デフォルトの名無しさん mailto:sage [2005/08/26(金) 10:28:54 ]
- >>455
もっと詳しくお願い。
アクションリスナとアクションメソッドの使い分けが本当にわからん。
リスナメソッドがアクションメソッドより先に呼ばれると言うだけじゃないのか？
リスナメソッドの処理結果を画面上に反映させてユーザに通知することも出来ない。
画面を再描画させる契機はアクションメソッドしかないのだから。
Swingなどのスタンドアロンアプリだったらわかるが、Webアプリでは
どうやって使い分けるんだ？
マジ教えて。
- 457 名前：デフォルトの名無しさん [2005/08/29(月) 22:23:41 ]
- >>455
俺もわからない。ヒントだけじゃなくて、具体的な使い分けを教えて欲しい。
- 458 名前：デフォルトの名無しさん mailto:sage [2005/08/29(月) 23:20:25 ]
- 僕もちゃんと理解してるわけではないんでアレなんだけど。
「アクションメソッド」と「アクションリスナ」があるって考えると確かにリスナの方はどうよって気にもなりますが、
基本的にはイベントドリブンなので、アクションを捕まえるのは常にアクションリスナの役割だってのが前提。
だけど、それをいちいち書くのもややこしいから、ラップして使いやすくしたのがアクションメソッド、
ってことなんじゃないでしょうかね？
- 459 名前：デフォルトの名無しさん [2005/08/29(月) 23:44:09 ]
- >>458
ご見解ありがとう。
でもさ・・・
大義名分とか、本来の意味での存在意義はその通りなんだろうけど、
JSFのアクションリスナは、例外を投げて処理を中断することはできるけど
画面の遷移先を変えたりができないってのが何とも中途半端に感じる。
ボタンが押されたら→DB検索→検索結果表示画面へ遷移（またはエラー画面へ遷移）
なんて動きはリスナではできないんだよね・・・・
書籍やWebの情報を見ても「イベントをハンドリングできます」とは書いてあるけど
リスナで実装するべき処理の具体例をなかなか見つけられない・・・
- 460 名前：デフォルトの名無しさん [2005/08/30(火) 00:02:35 ]
- 無理して使う必要ないんじゃない？
JSFに依存せずにコントローラを作れるという点からも、普段はアクションメソッドを使っていればいいんじゃないだろうか
- 461 名前：デフォルトの名無しさん [2005/08/30(火) 02:17:23 ]
- AjaxFaces とか既製品使わないでちょっと、簡単なサンプルを
JSF＋AJAXで作りたいのですが、どこかにサンプルはないでしょうか？
いまいましいことにﾄﾞﾄﾈﾄのやつはあるのですがどうにかならないものでしょうか？
- 462 名前：デフォルトの名無しさん mailto:sage [2005/08/31(水) 19:26:54 ]
- >>461
.Netを使う。
- 463 名前：デフォルトの名無しさん mailto:sage [2005/09/01(木) 20:42:18 ]
- JSFってつかえねぇ。
とくにMyFacesが駄目だな。
俺は今まで.NET一筋だったんだけど、どれだけJavaが使えないかを検証するために、
ここ一週間ほどJSF使ってみた。
<x:inputDate>とか最悪だな。
入力フィールドが日・月・年の順になってやがる。
しかもソースみるとこの順序固定で出力してやがる。
また<x:inputCalendar>も同様に駄目。
ポップアップさせて日付を選ぶと日付が入力欄に入る。
一見すると正常に動いてるようだが、ちょっと設定を変えるとおかしい。
例えば、表示形式をyyyy/MM/ddにする。
ポップアップから選択後、入力欄には確かにこの形式で表示される。
”しかし”
もう一度ポップアップさせると、動作がおかしい。
何がおかしいかを検証してみると、月が01とか02とかMMの形式だとポップアップが月を認識しない。
選択させるときはMMの形式でOKなのに、表示するときはMMだと認識せずMでないといけない。
つうか、Javaの魅力って何？
OSを選ばないところぐらいしかメリットが無い。
JSFで1ヶ月掛かる仕事も.NETなら1週間程度で終わりそうだし、
MySQLやPostgreSQLも.NETから使えるし、WindowsサーバのOS代だけ金使って、
あとはフリーでも問題無い。
ほんと、JSFって使えねぇ。
- 464 名前：デフォルトの名無しさん [2005/09/01(木) 20:53:02 ]
- >>463
それはJSFが使えねえんじゃなくて、MyFacesが使えないだけだ。
さすがWin/.NET厨。問題の切り分けもできないDQNだな。
- 465 名前：463 mailto:sage [2005/09/01(木) 20:56:56 ]
- >>464
JSFの機能 ”だけ” じゃ.NETの足元には及ばない。
そこで、拡張されていてApacheで開発されているMyFacesと比べるのが相応と判断しただけだ。
JSFだけじゃ.NETと比べる価値も無い。
- 466 名前：463 mailto:sage [2005/09/01(木) 21:06:59 ]
- JSF、問題は山積みだよ。
例えば、ブラウザの『戻る』ボタンの制御。
JSFではデフォルトで制御してくれているが、昨今、この制御をする方法は何通りもの方法があり、
既に決まった処理となっている。
”しかし”
制御したいのは更新などで多重登録になる場合であり、なんでもかんでもデフォルトで
この処理が付いてくるのは邪魔以外の何者でもない。
特に、検索など参照だけの場合、ボタンやリンクで戻ろうが、ブラウザの戻るボタンで戻ろうが、
どっちでもいいはず。
さらには、JSFだけじゃなくてJavaでのWebアプリ自体に無駄が多い。
ServletやJSPなどで構成されたシステムで、なぜApacheのHTTPServerと
TomcatなどのApplicationServerを連携させてる構成が多いのだろう？
とくにJSFやStrutsなど使ってる場合、システムの99％近くはServletやJSPで
APサーバが処理するのに、めったに処理しない静的コンテンツ用に
ApacheのHTTPServerと連携させる。
まったくもって無駄なサーバ構成である。
- 467 名前：デフォルトの名無しさん [2005/09/01(木) 21:29:25 ]
- >>465
＞ そこで、拡張されていてApacheで開発されているMyFacesと比べるのが相応と判断しただけだ。
その判断がDQNだな。
本業を別に持っている人たちが片手間に作ったモノとなぜ比べる？
せいぜいIBMの実装と比べてから言えよな。
そんな判断もつかないのか。M$厨は。
- 468 名前：デフォルトの名無しさん [2005/09/01(木) 21:30:52 ]
- ＞なぜApacheのHTTPServerと
＞ TomcatなどのApplicationServerを連携させてる構成が多いのだろう？
てめえがそう思うのならしなければいいだけの話し。
誰も連携させることを強制なんかしていない。
勝手に思いこむお前が糞。
- 469 名前：463 mailto:sage [2005/09/01(木) 21:43:26 ]
- >>467
＞その判断がDQNだな。
＞本業を別に持っている人たちが片手間に作ったモノとなぜ比べる？
これは無知ゆえの発言ですね。
Apacheは非営利目的の団体だけど、開発者は普通の企業に勤めてる人間が多い。
しかし、だからといって本業の片手間と決め付けるのは無知そのもの。
実際は、勤め先の会社から給料を貰いつつ、その会社での”仕事”として
Apacheプロジェクトの開発をする事が認められている。
つまり、本業。
＞せいぜいIBMの実装と比べてから言えよな。
＞そんな判断もつかないのか。M$厨は。
IBMの実装？
それに金払うのか？
ならば、金払わないでもつかえる.NETと比べる土台にすら上がってないよ。
＞てめえがそう思うのならしなければいいだけの話し。
＞誰も連携させることを強制なんかしていない。
＞勝手に思いこむお前が糞。
俺がサーバを立てるなら連携させることは無いだろうな。
だけど、Javaなどをメインに仕事してる会社とかが構築してる場合とかでも
ほぼデフォルトでそういった構成になってる。
正直言って不思議だよ。
ちなみに、思い込みじゃなくて実際に見てみた結果で言ってる。
- 470 名前：デフォルトの名無しさん [2005/09/01(木) 21:51:35 ]
- >>469
Apacheは非営利目的の団体だけど、開発者は普通の企業に勤めてる人間が多い。
しかし、だからといって本業の片手間と決め付けるのは無知そのもの。
実際は、勤め先の会社から給料を貰いつつ、その会社での”仕事”として
Apacheプロジェクトの開発をする事が認められている。
つまり、本業。
その辺はプロジェクトによって全く扱いが違うぞ。
MyFacesのコミッタが誰だかわかってて言ってる？
例えば、コミッタのうちのひとり、
Oかもと氏はみかかでーたの仕事としてMyFacesの開発なんかしてないぞ。
- 471 名前：デフォルトの名無しさん [2005/09/01(木) 21:52:13 ]
- ＞ 俺がサーバを立てるなら連携させることは無いだろうな。
じゃあそうすればいいだろ。文句たれるな。
- 472 名前：デフォルトの名無しさん [2005/09/01(木) 22:00:52 ]
- 俺も某Apache関連プロジェクトのコミッタだけど会社の業務中はコッソリ・・・
業務として給料もらってできたらいいなー
- 473 名前：デフォルトの名無しさん mailto:sage [2005/09/01(木) 22:01:10 ]
- わざわざJSFのスレにきて.NETの足元にも及ばないとか言ってる時点でお察し
- 474 名前：463 mailto:sage [2005/09/01(木) 22:22:58 ]
- >>470、>>472
それは、日本と欧米の違いじゃない？
まぁ、プロジェクトによって変わるというより、どこの国の奴って方が大きい気がする。
考え方の違いだな。
>>471
単純な文句ではない。
たとえばMyFacesの日付関連に関してもそう。
日付表示は国によって違うことも分かる。
だからこそinputCalendarとかではyyyyMMDDなど書式を指定できる。
にも関わらず書いたような事が起こる。
つまり、考えが足らない。
つうか、inputCalendarでyyyymmddの指定してもう一度ポップアップさせると
月を認識しないなんて、バグだろ・・・
それにMyFacesのコミッタに日本人がいるのに、日・月・年の並びになってて不思議に思わないのも変。
日付の表示方法ってのは何通りもあるから、大抵の言語とかでも日付の書式設定てのがある。
書式設定にあわせて入力欄も変わらないと意味が無いよな。
はっきり言って、コミッタの設計能力って新卒の新入社員並だよな・・・
HTTPServerに関してもそう。
書籍やインターネットなどで連携についてよく掛かれている。
確かに静的コンテンツを表示させるのには効率は良いだろう。
しかし静的コンテンツが殆ど無いにも関わらず、なんでも連携してる感があるのは否めない。
>>473
理論的に反論できない時点でお察し。
俺は実例もあげて言ってるわけだが、反論するなら例などあげて理論的に反論しないと、
負け犬の遠吠えにしか聞こえない。
- 475 名前：デフォルトの名無しさん mailto:sage [2005/09/01(木) 22:34:48 ]
- 先の見えない＆路線変更しまくりの.NETよりはJavaのほうがコミュニティーや各ベンダの
相互チェック体制がしっかりしている分いいかな。
- 476 名前：463 mailto:sage [2005/09/01(木) 22:38:01 ]
- >>475
Javaは路線変更していないと言えるのだろうか・・・
コミュニティーや各ベンダの相互チェック体制がしっかりしてるというが、
実装を行うコミュニティやベンダが多く、同じ仕様なはずなのに
多少なりとも独自仕様が入り、互換性がない。
つうかSunのJDK自体も独自仕様がはいってるし、正直終わってる。
- 477 名前：デフォルトの名無しさん mailto:sage [2005/09/01(木) 22:42:43 ]
-
また、本屋が儲かるな・・
- 478 名前：デフォルトの名無しさん [2005/09/01(木) 22:43:55 ]
- まあ、糞.NETには糞MyFacesが相応な比較対象ということなんだな。
まともな実装にはかなわないのがわかってるから勝てそうな相手を選んだってことか。
- 479 名前：デフォルトの名無しさん mailto:sage [2005/09/01(木) 22:45:40 ]
- >>474
MyFacesに関しては同意できるんだが、ApacheHTTPServerと同TOMCATの連携は
ロードバランスやクラスタリングの様な便利な使い方もあるわけで、なぜ否定的に見
られるのか分からん。
それに、TOMCATがガチでAPサーバとWEBサーバを兼ねてたら、IISとの混成なん
かで無駄な工夫が必要になる。
- 480 名前：463 mailto:sage [2005/09/01(木) 22:46:30 ]
- >>478
なら、そのまともな実装とやらを教えてくれよ。
俺のJavaの知識は1週間しかないんだよ。
1週間程度勉強した奴にここまで突っ込まれて、理論的にも反論できないってどういう事よ。
- 481 名前：デフォルトの名無しさん [2005/09/01(木) 22:49:00 ]
- いやホント .Net 案件無いんですわ
たのんますよ
- 482 名前：463 mailto:sage [2005/09/01(木) 22:53:24 ]
- そりゃ下請け、孫受けじゃ案件ないだろ。
俺の会社がそうだけど、元請けがしっかりと.NET案件でJavaと同じ期間・金額で見積もって
儲けてるからな。
いまやJava技術者は過剰供給で単価が安い。
しかも、トラブル続出、開発工数は膨らんで大変だから、下請けに丸投げする。
- 483 名前：デフォルトの名無しさん [2005/09/01(木) 23:06:03 ]
- >>480
IBMの実装でも試してみろよ。
期間限定（30日だったかな？）なら無料で使えるから。
- 484 名前：デフォルトの名無しさん [2005/09/01(木) 23:08:54 ]
- >>480
＞ 1週間程度勉強した奴にここまで突っ込まれて、理論的にも反論できないってどういう事よ。
糞実装と比較して文句たれて、どんな人物が開発してるかも知らずに「Apache」というだけで「本業で開発」と決めつけてる
ような奴に、「ここまで突っ込まれて」とも思わないのだが？
- 485 名前：デフォルトの名無しさん mailto:sage [2005/09/01(木) 23:44:31 ]
- 糞実装のMyFacesでも、少し前に新人に作らせた.NETプログラム（C#）よりはまともだ
だから、Javaの勝ちだな
- 486 名前：デフォルトの名無しさん mailto:sage [2005/09/01(木) 23:54:22 ]
- >>474
> しかし静的コンテンツが殆ど無いにも関わらず、なんでも連携してる感があるのは否めない。
普通は画像が大量にあったりするが、しょぼいイントラしかやったことないのか？
まー、検証もせずに Apache と連携させなきゃならんと思い込んでる人間が多いのは同意で
ローカル開発環境でも教科書どおりに Apache + Tomcat とか意味分からんとやってるプロジェクトが多い。
なぜローカル環境でも Apache と連携してるの？ とか聞いたら、え？無くてもいいの？
とかいうプロジェクトは俺が Tomcat のみで稼動するように今まで置き換えてきた。
SSL もクラスタリングも仮想ホストも Tomcat で出来るしな。
.NET のほうが楽なのは同意。.NET はそんなに経験ないがサクサク作れた。
ちょっと変わったことしようとしたら、ハマったが、それは経験不足だったからかもしれない。
悪くいうつもりは無いが、Java はもっとバカ向けに作られてもいいと思う。
DI やら AOP は便利だが、作ってる奴らが技術自体に酔ってる気がしてならない。
自分でも Javassist や CGLIB で AOP 組んだが確かにおもしろい。
そういう低レベルな技術が見えない .NET とは思想の差か。
- 487 名前：デフォルトの名無しさん [2005/09/02(金) 00:08:01 ]
- >>486
> ちょっと変わったことしようとしたら、ハマったが、それは経験不足だったからかもしれない。
俺もそこにギャップを感じた。
ありきたりの、おきまりのことをやるだけなら簡単なのだが、想定外の要件に対応しづらい。
- 488 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 00:14:06 ]
- >>486
.NETにもCodeDOMを使ったAOP実装とか、IoCコンテナでDelegateInjectionとか
.NETでも独自の特色を活かした技術的酔いどれは色々模索されてるよ。
２ちゃんで話題にならないのはレベルの差かｗ
- 489 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 00:17:32 ]
- 2chで議論するまでもなく、.NETとJavaのどちらが優れているかなんて市場（経済）が証明している。
.NETなんて「そのうちJavaを追い越す」なんて5年前から言われていて、いつまでたってもてんで普及しない。
Java＞＞＞＞＞.NETなのは某255が暴れていた5年前から変わらなかったし、これからもそう簡単には変わらないよ。
うちらがここでどう議論しようが、それが現実の企業の下している結果なんだから仕方ないじゃん。
これはJSFがいまだ流行らず従来のJ2EE仕様で現場が満足しているという状況にも同じことがいえるが。
つうかなんでいまさら.NET vs Javaをこのスレでやらにゃならんのだ？
- 490 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 00:18:56 ]
- 流れを読まずに低レベルな質問。
1) JSFでWebアプリの初期化仕事をしたい場合ってどうするのが
一般的？初期化専用のServletを作るしかないのかな？
2) ManagedBeanを取得／参照する一般的な方法はなに？
Session/Request/ContextをFacesContext経由で取得して
Bean名で参照すれば可能なのは分かるんだけど、
ScopeとBean名はfaces-config.xmlで設定するわけなんで、
↑のようなのをベタでやるのはキモチ悪いんですが。
- 491 名前：デフォルトの名無しさん [2005/09/02(金) 00:23:32 ]
- >>489
＞ これはJSFがいまだ流行らず従来のJ2EE仕様で現場が満足しているという状況にも同じことがいえるが。
これは来年が勝負だな。Java EEの標準仕様としてJSFが組み込まれるから、各ベンダーや開発環境の対応が充実してくると思われる。
.NETが普及しないのは、特定の企業の囲い込まれたくない、という企業や公共機関の思惑もありそう。
特定の企業の方針に振り回されたりぼったくられたりするのはカンベンだ、という。
あるいは、政府や公共機関だと特定企業との癒着イメージを付けたくないとか。
＞ つうかなんでいまさら.NET vs Javaをこのスレでやらにゃならんのだ？
それは、このスレがアンチスレだからだ。ここは>>1の空気を読んで欲しいところ。
- 492 名前：デフォルトの名無しさん [2005/09/02(金) 00:24:13 ]
- >>488
大多数のドトネト厨はそんなところをキャッチアップできないDQNだからな。
- 493 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 00:29:02 ]
- >>489
市場経済で何かが主流になっている＝優れている？
俺的には断然否だな。
ハリウッドやオリコンチャートやベストセラーなんぞ糞だし
大企業の工業生産された酒よりは断然地酒だし
VHSよりベータだし
ちなみに.NETは結構ウチの会社では使われてるよ。
.NETがJavaほど使われてない主な理由って
・クライアント向けに使うにはまだ時期尚早（バカでかい.NET Flamework
入れなきゃいかんしVBあたりに比べても重い）
・サーバサイドで使うとしてもIIS＋Win限定ではなんかヤだ
・技術者がまだ少ない
・枯れてないのが不安
ってなあたりでしょ。アーキテクチャの優劣以外の問題のがデカいと思う
- 494 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 00:30:50 ]
- MSの技術はすぐに廃れるから信用できない。
かつてWindowsアプリ開発のスタンダードだったMFCでさえ、
今ではC++と共にすいたいしてしまった。
.NETだって1.0と1.1じゃえらい違いだ。
- 495 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 00:32:32 ]
- >>494
MFCは十分長生きしたと思うけどね
それにC++もそうだが、別に全然消え去ったワケじゃないよ
.NETはまあ2.0で随分変わるがJavaのTigerだって似たようなモンだろ
- 496 名前：デフォルトの名無しさん [2005/09/02(金) 00:34:28 ]
- >>490
1) ServletContextListenerを使うのがいいんじゃね？
初期化専用Servletを使うのはServlet2.2の頃のやり方。
2) 1. ManagedPropertyでDIする。
2. ValidableResolverから名前を指定して取得する。
2.はExternalContextから取得する方法もあまり変わらない気もする。
まあ、ScopeとBean名はアプリにべた書きでもいいんじゃね？
JSPのVB式にもべた書きだろ？型名をべた書きじゃなきゃいいと思う。
これ以降はスレ違いだからこっちへ移動汁↓
JSF(JavaServer Faces)【.NET死亡？！！！】
pc8.2ch.net/test/read.cgi/tech/1059208396/
- 497 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 00:35:17 ]
- ｽﾏｿ。俺がスレ間違えてた・・・
- 498 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 00:37:12 ]
- ＞市場経済で何かが主流になっている＝優れている？
＞俺的には断然否だな。
キミがここで何を叫ぼうが現実は現実。普及したものが勝ちだよ世の中は。
それはかつてMSがさんざん証明してきた真理。
＞ちなみに.NETは結構ウチの会社では使われてるよ。
キミの廻りの話なんて聞いてない（しかも根拠がないから信じろと言われても無理）。
＞時期尚早
＞技術者がまだ少ない
＞枯れてないのが不安
.NET厨が必ず使うよねこの一連のセリフ・・・.NETが登場してから一体何年たってると
思ってるんだ？？いい加減目を覚ませよ。
- 499 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 00:38:44 ]
- Javaは1995年登場で5年後の2000年にはサーバサイドをかっさらっていったよなあ。
.NETは2000年夏に登場で5年後の今年もぜんぜんぱっとしないなあ。
- 500 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 00:42:40 ]
- >>498
いや、俺的には勝ち＝優れているとは全然思ってないだけ。
WindowsのC++フレームワークのデファクトになったMFCなんぞ
まさに糞の塊だし。まさに、「勝っただけ」の典型。
時期尚早はただの事実だろ。クライアントサイドで普及するには
Longhornを待つしかない。で、クライアントサイドでは別に
Javaは勝っていない。
MSはRADとしてVB6.0系列は止めちまったから、クライアントは
.NETに移行していくしかない。そうやって技術者が育ってくれば
サーバサイドにも当然動きが出てくるだろう。
ま、それでもC++やCOMが完全に置換されることは無いだろうけどね。
- 501 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 00:43:10 ]
- ｶﾞﾋﾞ━━(ﾟДﾟ;)━━━ﾝ!!!!! load-on-startupでホゲフガガって
今時はやらないんだな＿|￣|○||| 何時の間にやら時代遅れ……
- 502 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 00:44:38 ]
- >>496
回答トンクス。
>>501
別にやってもいいんじゃないの？
今時はダッセーとか言われるのかもしれないけれど。
- 503 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 01:22:22 ]
- >>491
サーバーサイドと言ってもいろいろなので。
以前ASPでやってたようなイントラ系の案件なら、ASP.NETに移行するのに何ら
問題はない気がする。
Javaであっても、SunやIBMに振り回されるのはかわらんだろう。まあ
程度問題ではあるけれども。
- 504 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 02:54:19 ]
- なんとなくLight Weight Javaという本を買ってﾁｮｺﾁｮｺいじり始めたんですが、あんまり理解できておりません。
サンプルを見ながら作ってまず思ったのは「セッション管理はどうすんの？」
で、次に思ったのは「jspに直でアクセスされたらどうすんの？｣なんですが、
ここらへんはどう解決するのがスタンダードなんでしょうか。
買った本のサンプルでは直でURL叩いたらフツーに表示されて鬱になりました。
層が違うとかJSFと関係ねーとかボロクソ言われそうな確信に近い予感がするんですが、
スレ違いだったら容赦くださいませ。
なんか夢のような話がいっぱい書いてあってやってみたくなったんだけど、
オレの能力ではなかなか前途は暗そうです。
つーか、そもそもJavaとかServletの知識も足りん気もします。
Javaの言語的な知識一通り+Servletのお勉強（モア・サーブレットで一通り）+Struts（+hibernate)の業務経験半年。
Webアプリ自体はレガシASPで過去2年ぐらいやってます。
ちなみに、今までのスタンスは、
セッション管理
フレームワークから生のセッションをｹﾞｯﾄしてｺﾁｮｺﾁｮチェックしてどうこうする。
jsp直アクセス
(ﾟ⊿ﾟ)ｼﾗﾈ。既存のがなんにも対策してないから俺もやらね。
でした。
- 505 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 06:59:29 ]
- ＞セッション管理はどうすんの？
普通にManagedBeanのスコープをsessionにすればいいだけじゃないのか？
何を問題にしているのかさっぱりわからん。
＞「jspに直でアクセスされたらどうすんの？
WEB-INFの下にでも置いておけ。JSFだからという問題ではないだろ。
- 506 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 12:51:26 ]
- >>504
あなたが純粋なアプリ屋で、アプリ基盤とか共通チームとか言われるチームから
サポートを受けられる立場なら、細かいところは任せちゃった方がいいです。
逆に、自分でそこまで見なきゃ行けない立場なら、まずはServletレベルから
ちゃんと勉強した方がいいです。
- 507 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 19:41:20 ]
- >>470
Oかもと氏はContributerであって、Comitterではない。
いやあ、いつのまにコミッタに！？と一瞬あせったぞ。
- 508 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 19:42:35 ]
- あ・・・Committerね。タイポスマソ。
- 509 名前：デフォルトの名無しさん mailto:sage [2005/09/02(金) 20:36:48 ]
- >>504
直接的なセッション管理についてはあまり気にすることはない、という感じかしら。
JSFはそういう汚いものをなるべく隠すようにデザインされてるから。
HttpSession#setAttribute()で明示的にオブジェクトを保存するかわりに、
SessionスコープのManagedBeanを使うのがJSFのやりかた。
JSFServlet通さずにJSFなjspに直接アクセスされたら、単に500になるだけでしょ。
- 510 名前：504 mailto:sage [2005/09/03(土) 00:41:37 ]
- やっぱり私は的外れな事をのたまっていたようで。
私がセッション管理と呼んでいたのはいわゆるログイン認証が必要な
サイトでのログイン状態の管理のことでした。
ログイン時に入力情報をセッションに格納し、その後リクエストごとに
セッションの情報を使って認証し、正当なものにのみリクエストされたページを
表示し、ダメならログインページにリダイレクト、
という処理をどう実装すべきなのかがぜんぜん思いつきません。
パッと思いついたのがFilterでHttpSessionを触ることなんですけど、どうなんでしょうか。
もはやJSFぜんぜん関係ないかもですが、ご指導お願いいたします。
- 511 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 09:59:06 ]
- >>510
ログインページからsessionスコープのManagedBeanを呼び、そこにログイン状態を保持
ログインチェックはFilterで行い、Sessionからログインで使ったManagedBeanをチェックする。
ただし、ログインページから飛ぶときだけはチェックの対象外とする。
でいけるんじゃないの？
ただ、Strutsのときはログイン時のsubmit先のURLがすぐわかったけど、JSFではどうなるんだっけ？
- 512 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 10:11:33 ]
- ＞ ただ、Strutsのときはログイン時のsubmit先のURLがすぐわかったけど、JSFではどうなるんだっけ？
JSFを使ったフォームの場合は、送信先URLは自ページだよ。
送信元はわかるから、送信元がログインページかどうかを判断すればいいんじゃね？
- 513 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 10:37:56 ]
- >>510
JSFではExternalContext経由で比較的低レベルの機能にアクセスできるよ。
もちろんSessionも触れるしRedirectもできる。
「リクエスト受信時に何かしたい」ような場合、まあServletFilterでも
いいんだけど、JSF的にはPhaseListenerを使うという選択肢もあるんじゃない
のかな。
- 514 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 12:00:34 ]
- で、いつになったら具体的なサンプルコードなど出てきますか？
テーブル定義はこうして、こういった画面つくって、こういった設定、コードを書けば、
ログイン認証ができるよという明確なサンプル的なものが欲しいのですが？
それとも現時点ではJSFでは処理が複雑なのでしょうか？
それとも、ここの技術者レベルが低いのでしょうか？
- 515 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 13:48:16 ]
- >>514
一冊、本買ってこいよ。
- 516 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 13:59:47 ]
- >>515
JSFをメインに書いているような本は２，３冊買いました。
雑誌などで特集してるものも含めると10冊以上買いました。
しかし、雑誌などではコンポーネントとかの使い方などに注力しています。
また、ログイン画面などのサンプル的なものは存在しましたが、
やっていたのは、ログイン後にプログラムの中で固定でユーザ名とパスワードを
ifで判別してエラーメッセージを出して終わりとかその程度です。
実際に仕事で使えるレベルのサンプルが欲しいのですが、
書籍を書いている人も技術レベルが低かったり実務やってないのでしょうか？
- 517 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 14:47:50 ]
- そのif文を適当に変えりゃいいだけじゃないか。
- 518 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 14:51:49 ]
- >>514
あなたの技術レベルというか知能レベルが低すぎるのです。
- 519 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 14:54:56 ]
- >>514,516
突然逆切れか。しかも仕事か（苦笑）
お前、それでよく給料貰ってるな……。
- 520 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 15:06:31 ]
- 要約すると
・本をたくさん読んだけどわからなかった
・本のレベルが低すぎるに違いない
・JSFが難しすぎるに違いない
・決して自分がバカなのではない
こいつの何がバカかって、514、516の最後の1行さえ書かなければ、それなりの意見がでてたかもしれないってところだ。
- 521 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 15:31:48 ]
- >>517
そのif文を書き換えるだけで良いという考えが、技術力の低さ・業務での開発が分かってない、
典型的な例だと思います。
>>519
JSFでまだ仕事はしてません。
Strutsでの開発をしていますが、今後を考えての勉強です。
>>520
＞・本をたくさん読んだけどわからなかった
＞・本のレベルが低すぎるに違いない
これは、その通りでは？
単純に、その本が何をターゲットにしてるかが違うだけという事もありますが、
あまりにも仕事レベルで使えるものが少ない。
＞・JSFが難しすぎるに違いない
これは、勉強中なので何とも言えません。
＞・決して自分がバカなのではない
馬鹿では無いと思います。
＞こいつの何がバカかって、514、516の最後の1行さえ書かなければ、それなりの意見がでてたかもしれないってところだ。
ただの言い訳ですね。
これを言うからには、それなりの意見をだして納得させた上で、”馬鹿”だの言ってもらいたい。
意見が出なければ、技術レベルの低い人間しか居ない。
意見が出れば、素直に自分が馬鹿と認め、謝罪でもなんでもしますよ。
- 522 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 16:19:21 ]
- いつになったらコードが出てくるのか？
という発想をする職業エンジニアがいることに驚いた。
自分で応用ができないレベルでしかないのに
本のレベルが低すぎるなんてよく言い切れるものだ。
- 523 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 16:25:08 ]
- 他人に具体的なコードをもらうまで自分でなんとかできる技術力が521に無いことは確かなようだ。
- 524 名前：504 mailto:sage [2005/09/03(土) 16:40:41 ]
- なんか妙に伸びてると思ったら誰かが私の代わりに盛り上げてくれた人がいたのですね。
というかひょっとして現在進行中ですか。
なんか流れに水を注すようで申し訳ないのですが、せっかくだから書いときます。
セッションにログイン情報を格納する方式はJSFが提供するManaged Bean、
セッションからログイン状態を評価するタイミングとしてServletFilterとPhaseListener、
という方式を教えていただいたので、いろいろ考えておりました。
ServletFilterで処理する場合、FacesServletの処理の前にManagedBeanを取得して評価
することになると思うんですが、そうなると、HttpSessionからStringのキーを指定して
Managed Beanを取得せねばならない気がします。
どうやらfaces-config.xmlで<managed-bean>要素内の<managed-bean-name>要素
に指定された文字列を指定してgetAttributeしたら取れそうなんですが、
そういう名前でセッションにぶら下がってる保証があるのかどうかわからんくて困っております。
LoginBean loginBean = （LoginBean）((HttpServletRequest)request).getSession().getAttribute("loginBean");
とかフィルタで書いといて、JSFの実装差し替えたらセッションにManaged Beanを格納する方式
が変わってたりして動かなくなったらどうしようみたいな。
だったらManaged Beanに頼る意味あるのかなあ。どうせServletFilterで生のセッション触るなら
ログイン情報もログイン時にHttpSessionに直に書いてもいいんじゃないだろうか、とか。
なんかまとまってないですね。もうちょい考えます。
PhaseListenerの場合は、実装に特に問題はなさそうなんですが、
「フェーズと何の関係があるんだろう？」という疑問が湧き。
とりあえずrestoreViewのあたりに仕込んでValiableResolverでログイン時のManaged Beanを取得
して評価する。ｵｯｹｰならｽﾙｰで、ダメなら、、。うーん、（JSF的には）どうすればいいんだろう。
ここでやるのは正しいんでしょうか。
- 525 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 16:54:21 ]
- ＞ そういう名前でセッションにぶら下がってる保証があるのかどうかわからんくて困っております。
現在のバージョン(1.1)とその次のバージョン(1.2)ではJSF仕様で保証されている。
将来のバージョンではわからないけどね。
- 526 名前：デフォルトの名無しさん mailto:sage [2005/09/03(土) 16:59:26 ]
- >>524
どのみち、今のところ、それしかManagedBeanを参照する綺麗な方法が無いと
思う。あきらめれ。
- 527 名前：デフォルトの名無しさん mailto:sage [2005/09/04(日) 01:37:56 ]
- >>521
> そのif文を書き換えるだけで良いという考えが、技術力の低さ・業務での開発が分かってない、
> 典型的な例だと思います。
そうだねぇ。
キミの技術力の低さや、そんな技術力で業務での開発をやらないといけない事情を分かってないとは言える。
- 528 名前：デフォルトの名無しさん mailto:sage [2005/09/04(日) 04:45:21 ]
- なんつうか認証だったら単純にJAAS使うのがいいんでない？
- 529 名前：デフォルトの名無しさん mailto:sage [2005/09/04(日) 06:40:35 ]
- つうか、Tomcatの認証機能使えばいいと思う。
- 530 名前：デフォルトの名無しさん mailto:sage [2005/09/04(日) 09:15:38 ]
- >>529
それはJAAS実装でなくて？
それとも、俺様の知らない、Tomcat独自の秘密の認証機能があるのか？
- 531 名前：デフォルトの名無しさん mailto:sage [2005/09/04(日) 13:59:41 ]
- 確かTomcatのはJAAS「互換」だけどJAAS実装じゃないとかよく分からんがそんな感じだった。
仕様を満たしてない部分があるとかかも。
どっちにしろJDBCやらLDAPのRealm作れば普通のWebアプリの認証は実現できるっしょ。
Tomcatだったら JdbcRealmは実装提供されてなかったっけ？
- 532 名前：デフォルトの名無しさん mailto:sage [2005/09/04(日) 14:04:28 ]
- >>531
TomcatにもJDBC Realmあるよ。
- 533 名前：デフォルトの名無しさん [2005/09/04(日) 18:52:18 ]
- アプリの配置された実ディレクトリのパスを取得したいんですけど、
JSFのELで取得するには、どのオブジェクトのなんという属性を
参照すればいいんでしょうか？
どういう暗黙オブジェクトがあるかというドキュメントは見ますが、
それぞれどういう情報を持っているかという資料は見つけられません。
どこかにいい資料はないものでしょうか？
#もしかして、中身については何も規定がなく、実装に依存する？
- 534 名前：デフォルトの名無しさん mailto:sage [2005/09/04(日) 20:16:07 ]
- JSFとか意味わかってないんじゃね？
> どこかにいい資料はないものでしょうか？
www.ingrid.org/jajakarta/servletapi/servletapi-4.0/docs-ja/
- 535 名前：デフォルトの名無しさん [2005/09/04(日) 20:33:04 ]
- JSFのEL
- 536 名前：533 [2005/09/04(日) 20:35:58 ]
- いや、ServletAPIじゃなくてJSFのELで取得する方法を探しています。
というのも、BackingBeanはあくまでもPOJOのままにしておきたい
(=FacesContextなどは参照しない)→とするとfaces-config.xml内で
<managed-property>で外部から値を設定してやる必要がある→
ここに記述できるのはELだから、なんとかしてELで実ディレクトリを
求められないか？という流れです。
他にうまいこと外部から値を注入してやる方法があれば、それでも
いいんですが。
- 537 名前：デフォルトの名無しさん [2005/09/04(日) 20:40:26 ]
- うーんムズイねそれは
何をしたいのか処理の順番が分からないから答えにならないかもしれないけど
普通にサーバ側のページ初期化アクションでbean.setPath()とかやるのはダメなの？＿
- 538 名前：デフォルトの名無しさん mailto:sage [2005/09/04(日) 20:52:15 ]
- 533は大人だ。
- 539 名前：デフォルトの名無しさん mailto:sage [2005/09/04(日) 21:01:16 ]
- 実ディレクトリは動的に求めないとダメ？
<managed-property>の<value>に直接書くのは無しかな？
faces-config.xml にも環境依存の情報は書きたくない？
話しは少しずれるんだけど、
＞BackingBeanはあくまでもPOJOのままにしておきたい
これ、実は結構難しくない？俺もテストファーストでBeanを作ろうと
思ったんだけど、出力メッセージをFacesContextに入れるところや
UIComponentのComponent Bindingで断念した。orz
- 540 名前：デフォルトの名無しさん [2005/09/04(日) 21:06:59 ]
- ＞BackingBeanはあくまでもPOJOのままにしておきたい
これ、実は結構難しくない？俺もテストファーストでBeanを作ろうと
思ったんだけど、出力メッセージをFacesContextに入れるところや
UIComponentのComponent Bindingで断念した。orz
分かる、非常に同感
なんかさ、くちゃくちゃになるんだよねいろんなとこでいろんなことしたりしちゃって・・・
結局 static FacesContext.getCurrentContext()だっけ？
こいつが悪であり、しかしこいつがある理由が分かるような気がしないでもない
- 541 名前：デフォルトの名無しさん mailto:sage [2005/09/04(日) 21:22:22 ]
- FacesContext#getCurrentInstance() ね。
JSFだとBeanがPOJOで作れてテストがカンタン！なんて幻想だったよ・・・orz
- 542 名前：デフォルトの名無しさん [2005/09/04(日) 21:26:47 ]
- あまり不満ばっか並べてもJSFがかわいそうなので利点を挙げると
コンバータ・バリデータ・アクションって分けて開発できることかなぁ
初心者にはコンバータ・バリデータ書かせておけばよいし
- 543 名前：533 [2005/09/04(日) 21:40:02 ]
- なるほど、参考になります。
JSFは始めたばかりなんで、原則通りやってみようと考えて
いるんですが、現実には理想通りにいかない部分もあるん
ですね。
その後調べてみて、やはりELで直接取得するのは難しい
ようなので、代替案を考えました。
1. applicationスコープのbeanをひとつだけ用意し、この
生成時に実ディレクトリを取得しプロパティに保持
(これだけコンテナ依存)
2. その他のbean(sessionスコープ)は<managed-property>で
上記beanのプロパティ値をセット
試したところうまく動くようですので、これでいってみようと思います。
開発環境と運用環境が違うので、faces-config.xmlに環境
依存情報を記述するのは避けたいですね。それよりはまだ
コンテナ依存の方が許容できます。
- 544 名前：デフォルトの名無しさん [2005/09/04(日) 21:47:06 ]
- >>533
そのパスって動的に変わる値だと思ってたけど固定なのね；；
ならば、web.xmlに環境変数として希望するパスの情報書くのはダメなのかな
<resource-env-ref> とか<env-entry>とか
- 545 名前：デフォルトの名無しさん mailto:sage [2005/09/05(月) 02:19:29 ]
- しかし、いまだに
www.ingrid.org/jajakarta/
が引用されるのがさびしい限りだ。
- 546 名前：デフォルトの名無しさん mailto:sage [2005/09/05(月) 14:03:49 ]
- >>524
遅レスだけどJSFにこだわらないでこれでいいと思うけど...
>だったらManaged Beanに頼る意味あるのかなあ。どうせServletFilterで生のセッション触るなら
>ログイン情報もログイン時にHttpSessionに直に書いてもいいんじゃないだろうか、とか。
あとはServletFilterのInitParameterで認証失敗時の遷移先URIやチェック除外対象のURIのリスト
とかを設定できるようにすればいいんじゃないの？
- 547 名前：504 mailto:sage [2005/09/06(火) 00:59:21 ]
- 規制されて書けないうちにどんどん話が進んでゆく。。
>525
仕様で決まっていたんですか。知らなかったです。不勉強でした。
そういうことだったらログイン時のManagedBeanをServletFilterでチェックする
というやり方で問題なく対処できそうです。
ありがとうございます。
Tomcatの認証はLDAP使ってやったことはあります。
その時も理屈が理解できてないのに機能だけ使うのに抵抗を感じ、
アプリケーション内で実装しようと目論んだわけですが。
なんせJAASという単語も今知ったくらいなので、これからお勉強して手の内
に入れたらそういう便利なしくみを使うのもよいかなーと思います。
でも、頭が悪いのか、チュートリアル読んでもｲﾏｲﾁ理解できませんが。
精進します。
>546
ええ。それでもいいわけですよね。むしろ、そうあるべきなのか。
そして、JSFと全然関係ないスレ違いな質問をしていたのだという事実にようやく気付いたりしつつ。
- 548 名前：デフォルトの名無しさん mailto:sage [2005/09/06(火) 17:42:19 ]
- JSFって、まだ本読んでもちゃんとアプリ作れないレベルなんですか？
新人達がJSFで社内ツール作らされてちゃんと作ってたみたいだけど、
どうやってたんだろう？
イントラだからセキュリティは若干甘いかもしれないけど
- 549 名前：デフォルトの名無しさん mailto:sage [2005/09/06(火) 19:42:49 ]
- >>548
そんなこたあ無いでしょ
別に（ふつうの）Servletや非JSFページとも併用できるんだし
|
 |
