- 1 名前:デフォルトの名無しさん mailto:sage [03/07/26 17:33]
- スレがないので新しくたてました
www.atmarkit.co.jp/fjava/special/jsf01/jsf01.html java.sun.com/webservices/downloads/webservicespack.html
- 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をメインに書いているような本は2,3冊買いました。 雑誌などで特集してるものも含めると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ページとも併用できるんだし
- 550 名前:463 mailto:sage [2005/09/10(土) 16:17:26 ]
- さて、またしばらくJSFを使ってみた。
まず、JSFだけではなんなのでStrutsとかも使ってみたが、 これはJSFでも同じような事ができるが、たしかにStrutsとかと比べると楽というか、 まぁ、雑誌とかの売り文句通りな気がした。 とりあえず、IBM実装を勧められたわけだが、会社に環境があったので来月にそれを使ってる プロジェクトが終わるらしいので、それが終わってから使わせてもらうことにした。 さて、まず気になったこと。 URLが変。 Page1とPage2というJSPをつくって、お互いにx:commandButtonで画面遷移させるだけ。 MyFacesだとPage2に行ったときPage1のURLのまま。 Page1へ戻ったとき、URLはPage2のまま。 うん・・・動きに問題が無いとはいえ、気持ち悪い。 SUN実装の方はそんなことなかった。 なんというか、この間、MyFacesが糞だと言っていたのが良く分かった気がした。 MyFacesってコアの部分はSunとかと同じで拡張コンポーネントがあるだけと思ってたけど、違うのね。 つうか、こういった部分も仕様に入れないでいいのか? まぁ、仕様が糞だから異なる実装で互換性がなくなるって事か・・・ あと、別のスレッド見て気が付いたけど、必須入力。 あれ、どうするんだ? 確かに何かの値によって必須入力チェックしたりしなかったりというのは有りだよな。 でも、必須入力かどうかの指定は <x:inputText id="name" value="#{Bean名.name}" required="true"/> って指定しちまうし・・・ この辺、PHPのmojaviとか優秀だったなぁと感じる。 まさしく、現場を分かった上でのフレームワークって感じで。 StrutsとかJSFって本当に現場わかった人間が設計してるのか怪しい感じ。
- 551 名前:463 mailto:sage [2005/09/10(土) 16:29:52 ]
- あと、なんで画面表示するだけでTomcatに警告がでるんだろうな。
警告: Unable to find component 'name' (calling findComponent on component '_id0:_id1') って感じの。 画面に入力欄1つ作って、後はサブミットのコマンドボタン。 まったく・・・ エラーメッセージもはまったな・・・ ユーザ名:<x:inputText id="name" value="#{Bean名.name}" required="true"/> <x:message for="name"/> と書いて、何も入力せずにSubmitしようとするとエラーメッセージが "name": 値を入力して下さい. もう・・・ いや、確かに分かるんだけどさ・・・ これをちゃんとさせるとなると、 <x:outputLabel for="name" value="ユーザ名:"/> <x:inputText id="name" value="#{Bean名.name}" required="true"/> <x:message for="name"/> という風にしなくちゃいけない・・・ おいおい、普通に書いて表示させられるのに、いちいちラベル作らないといけないのかよ・・・ 面倒なだ・・・ 真面目に不思議に思うんだ。 .NETFramework自体は無料。 SUNとかApache実装のJSFは無料。(IBMとかは優秀らしいが無料じゃないよな?) 明らかに、.NETの方が楽だし良く出来てるし動作も軽くて安定してるし、開発しやすい。 企業にとっては良い事だらけにしか見えないんだけどね・・・ MS製品はすぐにバージョンアップしてという意見もあったけど、どうせ2、3年とか 長くても5年ぐらいでシステム入れ替える癖に無駄な意見だよな・・・
- 552 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/10(土) 19:30:26 ]
- ハードウェアとアプリケーションの寿命は違うがな。
- 553 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 02:06:07 ]
- >> .NETFramework自体は無料。
このへんからトラップのにおひがするぉ
- 554 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 07:38:48 ]
- >>553
いや、フレームワーク自体は無料だろ。 有料なのは開発環境な訳だし。 .NETFrameworkSDKは無料でダウンロードできるし、 メモ帳とかでソースコード書いてコマンドラインでコンパイルすれば、そのまま配布もできるし。
- 555 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 08:48:43 ]
- .NETがいいと思うなら.NET使えばいいじゃん。
ここはJavaのほうが総合的に良いと思って使っている人たちのスレ。
- 556 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 12:06:15 ]
- 今時メモ帳でソース書く人とかいるのか?
- 557 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 12:17:42 ]
- 別にメモ帳の部分にこだわる必要はないんじゃない?
EclipseでだってC#とか書けるし、WebだけでいえばWebMatrixとかもあるし。
- 558 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 13:37:24 ]
- >>550
>確かに何かの値によって必須入力チェックしたりしなかったりというのは有りだよな。 まぁ、このスレの他の奴のレベルが低いんだろうから答えてやるよ。 エラーチェック用のBeanを作る必要があるんだよ。 public void 関数名(FacesContext context, UIComponent component, Object value) throws ValidatorException って感じで。 でもって、独自のエラーチェックしたい入力項目とかに <h:inputText validator="#{Bean名.関数名}"/> という風に指定する。 エラーチェック用の関数の中身は、 context.getExternalContext().getRequestParameterMap(); をつかってMapを取得して、欲しい情報をgetで受け取ればいい。 ただし、<h:form>にはちゃんとIDを付けておく。 <h:form id="frm"> こんな感じでな。 そうしておいて、取得したMapから値をgetで取得するときは、 map.get("frm:取得したい値のID"); という風にする。 あとは、エラーにしたい場合は、 throw new ValidatorException(new FacesMessage("エラーメッセージ")) とかすればいい。
- 559 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 13:47:59 ]
- おれがSunのJSF実装で試したときは
値が未入力の場合、Validatorにそもそも渡らなかった気がするんだが、気のせい?
- 560 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 14:12:05 ]
- >>559
SUN実装は使ったことないから分からない。 とりあえず、MyFacesでは問題無かった。 それと、余談になるんだが、お前様方の周辺でJSFってどんなかんじ? 俺の場合、会社だと新規のJava案件は殆どWebSphereを使うから、JSF使ってるから、 結構流行ってると言えば、流行ってるんだけど、他ではどうかとちょっと気になった。
- 561 名前:463 mailto:sage [2005/09/11(日) 14:36:10 ]
- >>558
なるほど、独自にチェックするしかないのね。 確かに出来そうだと思ったが、 >>559が書いてるようにMyFacesでも値が未入力だとValidatorに行かないな。 >>558=>>560も低レベル技術者のようで・・・ つうか、この辺はStrutsの方がマシだな。 登場してからの歴史が長いってのもあるんだろうな。 でも、JSFはやっぱいUIだけって感じなんだろうな。 だからStrutsとJSFが連携できるようになってるんだろうな。 Strutsを補う意味でJSFを使うのかと思ってたけど、 本当はJSFの貧弱さを隠すためだったんだな。 この辺を見ると、.NETFrameworkって素晴らしいと本当に実感したよ。
- 562 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 14:51:29 ]
- このスレとしてはJSF>>>>>(超えられない壁)>>>ASP.NETであってほしいが、そうもいかないって事か。
とりあえず、「h:output_text」とか書いてある古いJSFの資料は捨てちゃっても構わないよね?
- 563 名前:463 mailto:sage [2005/09/11(日) 15:11:38 ]
- >>562
>このスレとしてはJSF>>>>>(超えられない壁)>>>ASP.NETであってほしいが、そうもいかないって事か。 まぁ、スレ的にはそうだろうね。 俺も、ASP.NETマンセーと"だけ"言いたい訳じゃない。 Web開発者としては、提案するときに色々な選択肢がある訳で、 『こういった理由で○○をつかいます』と客に提案したい訳よ。 だから、JSFなりStrutsなりを勉強してる訳だけども、結局、両方使ってみると ASP.NET>>>>>>>>>(超えられない壁)>>>>>>>>>>>JSF なんだよね。 JSFなりStrutsが本当に使える物であるならば、俺はむしろJava信者になっても構わないんだけどね。 >とりあえず、「h:output_text」とか書いてある古いJSFの資料は捨てちゃっても構わないよね? いいの? Javaとかオープンソースって聞くと、例えバージョンが古くなったりしても、 ソースコードとかがあるからどうにでもなるってのも1つのメリットとしてよくあがるけど、 資料捨てて、数年後とか失敗したと思わなければいいんだけど。 俺の会社のJava開発チームは、前世紀からのJava資料を全部保管してるよ。 つうか、この資料だけで、会社の倉庫の半分使ってるんだけど・・・・ まぁ、あまりJSFやStrutsのスレが盛り上がってない事から見ても、きっと下火なんだろうね。 それと、最近、やけにJavaの技術者いませんか?との問い合わせが会社に多い。 聞くと、殆ど新規案件じゃなくて仕様変更なり拡張。 『今までの開発先は?』と聞くと『Java案件はもうやってない』とかで俺の会社とかに問い合わせがくるけど、 実際問題どうなの? 俺の会社やオフシェア先の中国でも、最近はASP.NETとかに以降してるから、 Java技術者って、実はこの先、仕事ないんじゃ?
- 564 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 16:41:41 ]
- (L)AMPのような手軽さもなければ、.NETほど生産性が高いわけでもない。
今はまだ数で圧倒的ではあるけど、難しい局面になってることは確かだな。
- 565 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 17:46:49 ]
- >>563
中国は国家主導でLinuxの導入進めてる。 個人レベルではWindowsのシェアが高いけど、企業レベルでは殆どがLinux環境。
- 566 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 18:20:02 ]
- >>565
別に国家レベルでLinux導入進めていたって、その中国の人間の客は日本なんだから、 日本向けに技術者を教育なり集めるのが普通だろ。 中国とかは関係無いよ。 あくまで客である日本企業の需要に合わせる。 俺らだって、客先が有無を言わさず『Linuxで!!』と言われればLinux使うし、 『Linuxは絶対に駄目。Windowsサーバで!!』と言われればそれに従うだけだし。
- 567 名前:名無しさん@そうだ選挙に行こう [2005/09/11(日) 18:42:37 ]
- JSFについて、日々意見が交換されているフォーラム等ってない?
「JSF フォーラム」で検索すると「日本宇宙フォーラム」や「ヤパーナ社会フォーラム もう一つの世界は可能だ」 とか、変なものがヒットするんだが。
- 568 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 19:11:44 ]
- >>567
だから、流行ってないんだって。 むしろ、Seasar2のS2JSFのメーリングリストとかの方が活発に意見交換されている。 だけど、あそこはあくまでもS2JSFの話題だからなぁ。 基本的にはJSFを使用するのは時期尚早って感じなんじゃない? だから、このスレとかでもあまり意見交換って行われてないじゃん。 JSFが気になった奴もちょっと使ってみて、『つかえねぇ』と感じて、 結局今まで通りって流れのような気がする・・・俺のように・・・
- 569 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 19:25:51 ]
- >>567
適当に探してみた jsf-jp JavaServer Facesに関するMLです。 groups.yahoo.co.jp/group/jsf-jp/ @ITのJava Solution 会議室 www.atmarkit.co.jp/bbs/phpBB/viewforum.php?forum=12
- 570 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 20:19:47 ]
- 一応、2つのプロジェクトでJSF(IBM実装で)使ったりしてはいるが
どうもここ見る限りでは浸透していない様子だなぁ・・・ あぼんの予感がする
- 571 名前:名無しさん@そうだ選挙に行こう mailto:sage [2005/09/11(日) 20:23:43 ]
- まだこれからでしょ。今は時期尚早という見方も多い。
実装による質のばらつきもまだまだ多いし。 初期のServletコンテナもベンダーによる質のばらつきが多かったのに似ている希ガス。 各ベンダーやオープンソースによる実装が安定して、さらに オープンソースの高機能なJSF開発環境やEclipseプラグインが 出てくると一気に普及すると思うけどな・・・。
- 572 名前:デフォルトの名無しさん mailto:sage [2005/09/12(月) 01:51:49 ]
- フレームワークのプログラミングモデルがたぶん大幅に変わらないから、
代わっても1.2見るだけでも局所的及び一部分だ。だとすると覚えるのは モデルだけで後は、どうやって利用するかどこに利用できるかってことに 今は知恵を使ったほうがいいよ。現状のレベルだといきなりASP置き換えはムリ それだとどこまでのレベルで使えるのか判断したほうがいいよ Webspherは全部のプロジェクトでつかえるものではないしな
- 573 名前:デフォルトの名無しさん mailto:sage [2005/09/12(月) 22:47:10 ]
- どっちかというとStrutsの置き換えみたいな考え方で、1.2以降ボチボチと使われ始めるんじゃないだろうか?
ASP.NETの対抗馬としてサンは開発環境込みで広めたかったんだろうが、 Eclipseで開発できない限りJavaの世界じゃ広まらないからな
- 574 名前:デフォルトの名無しさん mailto:sage [2005/09/13(火) 01:57:34 ]
- IBMかHPの実装がでないと意味が無い。SUNは弱体化してもう虫の息だ。
こんなところが実装するソフトウェア基盤はゴミでしかない。M$の金魚の糞は つぶれたほうがいいよ
- 575 名前:デフォルトの名無しさん mailto:sage [2005/09/14(水) 04:26:15 ]
- >>573
>Eclipseで開発できない限りJavaの世界じゃ広まらないからな Eclipseでの開発の有無より、スレ見てる限りJSFの仕様(実装)が糞だから みんな使わない(業務で役に立たない)んじゃない?
- 576 名前:デフォルトの名無しさん mailto:sage [2005/09/14(水) 08:02:40 ]
- >>575
いや、仕様よりもEclipseだろ
- 577 名前:デフォルトの名無しさん mailto:sage [2005/09/14(水) 08:12:35 ]
- そうだな、どんなに素晴らしい仕様でもどうしようもない
- 578 名前:デフォルトの名無しさん mailto:sage [2005/09/14(水) 21:00:29 ]
- 確かにツールがないとつらいな。
あとは日本語のマニュアルw
- 579 名前:デフォルトの名無しさん mailto:sage [2005/09/15(木) 15:04:20 ]
- >>534 >>545
Googleだと古い方のページがトップですが、 新オフイシャルサーバを参照する方がよいですよね。 「Servlet および JavaServer Pages API ドキュメント (Tomcat 4.0)」 www.jajakarta.org/tomcat/servletapi/servletapi-4.0/docs-ja/ Servlet API 2.3とJavaServer Pages API 1.2なので JakataのTomcat 4.1のページと同等ですね。 Servlet API Documentation (Tomcat 5.5) jakarta.apache.org/tomcat/tomcat-5.5-doc/servletapi/ JavaServer Pages API Documentation (Tomcat 5.5) jakarta.apache.org/tomcat/tomcat-5.5-doc/jspapi/ Servlet API Documentation (Tomcat 5.0) jakarta.apache.org/tomcat/tomcat-5.0-doc/servletapi/ JavaServer Pages API Documentation (Tomcat 5.0) jakarta.apache.org/tomcat/tomcat-5.0-doc/jspapi/ Servlet and JavaServer Pages API Documentation (Tomcat 4.1) jakarta.apache.org/tomcat/tomcat-4.1-doc/servletapi/ JSFもそうですが、最新バージョンの日本語マニュアル欲しいですね。
- 580 名前:デフォルトの名無しさん mailto:sage [2005/09/16(金) 00:48:26 ]
- Servlet + Velocity で十分でしょ。
- 581 名前:デフォルトの名無しさん mailto:sage [2005/09/16(金) 01:34:44 ]
- >>580
えらいねぇ。 漏れはもうStrutsなりJSFなりがないとしんどくてだめだよ。
- 582 名前:デフォルトの名無しさん mailto:sage [2005/09/16(金) 01:43:17 ]
- >>580
Velocity使うより、ふつうにJSPで充分。 というかVelocityよりはJSPのほうがいい。
- 583 名前:デフォルトの名無しさん mailto:sage [2005/09/16(金) 03:12:55 ]
- Velocityはマクロ周辺をもう少し使いやすく・・・
マクロファイル大量に分ければいいか・・・
- 584 名前:デフォルトの名無しさん mailto:sage [2005/09/16(金) 03:14:15 ]
- あえてVelocityを使うほどのメリットあるの?
HTML出力以外だと便利だけど。 JSPでよくない?
- 585 名前:デフォルトの名無しさん mailto:sage [2005/09/16(金) 13:35:11 ]
- て言うか、Maya最強!
- 586 名前:デフォルトの名無しさん mailto:sage [2005/09/16(金) 13:56:31 ]
- >>584
デザイナからするとJSPよりVelocityのほうが扱いやすいらしいよ
- 587 名前:デフォルトの名無しさん mailto:sage [2005/09/16(金) 14:11:06 ]
- >>585
いろいろ毎日忙しくて まだ検証にも踏み切ってないんだけど 実務に使えそう?
- 588 名前:デフォルトの名無しさん mailto:sage [2005/09/16(金) 14:22:56 ]
- >>586
#ifとかがプレビューで見えたほうがいいってこと?
- 589 名前:デフォルトの名無しさん mailto:sage [2005/09/16(金) 15:29:18 ]
- >>587
パフォーマンス的な事を言ってるなら、Velocityを使えると考えるなら それと同じくらいには使える。 CSSを用いればHTMLからレイアウトと装飾を分離できる。 ってのは最近では当たり前に知られてる利点だけど、それと同じ感 覚でWEBアプリ依存部分を分離できる。 これを逆に(Seasar的に)見ると、MayaファイルでHTMLに対してWEB アプリへの依存性を注入してる(所謂DI)とも言える。 あと、XPathを利用した複数箇所に現れる同一タグへの処理はAOP 的。こういった辺りが概念的に気持ちイイ!
- 590 名前:デフォルトの名無しさん mailto:sage [2005/09/16(金) 16:31:57 ]
- >>589
そういうのわかりやすくまとめてある資料ってありますか?
- 591 名前:デフォルトの名無しさん mailto:sage [2005/09/16(金) 17:10:21 ]
- >>590
maya.sandbox.seasar.org/ ここ読んであとはサンプル弄ってみるくらいかな? hoge.htmlとhoge.mayaが組になってる事さえ意識できれば 変更、結果表示の繰り返しで触れるようになると思うよ。
- 592 名前:デフォルトの名無しさん mailto:sage [2005/09/16(金) 19:12:21 ]
- いまのとこ使う気はないけど、どんなものか試してみたいっていうにはちょっと壁が高いな。
- 593 名前:デフォルトの名無しさん [2005/09/16(金) 20:58:15 ]
- Seasarって俺はどうも好きになれないんだよね。
メーリングリスト(参照だけならWebで見れる)でも、開発者自ら『MyFacesの糞実装』と 表現は違えど、名言しているにもかかわらず、S2JSFでは思いっきりMyFacesを使ってるし。 個人的には糞実装の上に、どんなに良いものを乗っけても、土台が糞な以上、 S2JSFも糞なんだよな・・・ つうかJSF自体オープンソースになったんだから、独自に実装すればいいんだよ。
- 594 名前:デフォルトの名無しさん [2005/09/17(土) 01:02:45 ]
- JSP+ELが最強ってことだな?
- 595 名前:デフォルトの名無しさん mailto:sage [2005/09/17(土) 01:11:48 ]
- >>594
JSP+EL+JSFでおけ
- 596 名前:デフォルトの名無しさん mailto:sage [2005/09/17(土) 01:45:34 ]
- まさたかさんはとりあえず
ttp://www.theserverside.com/news/thread.tss?thread_id=36575 を読んでおいてもらいたい。
|

|