JSF(JavaServer Faces)【.NET死亡？！！！】
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGhttp://www.atmarkit.co.jp/fjava/special/jsf01/jsf01.html
http://java.sun.com/webservices/downloads/webservicespack.html
0492デフォルトの名無しさん
2005/09/02(金) 00:24:13大多数のドトネト厨はそんなところをキャッチアップできないDQNだからな。
0493デフォルトの名無しさん
2005/09/02(金) 00:29:02市場経済で何かが主流になっている＝優れている？
俺的には断然否だな。
ハリウッドやオリコンチャートやベストセラーなんぞ糞だし
大企業の工業生産された酒よりは断然地酒だし
VHSよりベータだし
ちなみに.NETは結構ウチの会社では使われてるよ。
.NETがJavaほど使われてない主な理由って
・クライアント向けに使うにはまだ時期尚早（バカでかい.NET Flamework
入れなきゃいかんしVBあたりに比べても重い）
・サーバサイドで使うとしてもIIS＋Win限定ではなんかヤだ
・技術者がまだ少ない
・枯れてないのが不安
ってなあたりでしょ。アーキテクチャの優劣以外の問題のがデカいと思う
0494デフォルトの名無しさん
2005/09/02(金) 00:30:50かつてWindowsアプリ開発のスタンダードだったMFCでさえ、
今ではC++と共にすいたいしてしまった。
.NETだって1.0と1.1じゃえらい違いだ。
0495デフォルトの名無しさん
2005/09/02(金) 00:32:32MFCは十分長生きしたと思うけどね
それにC++もそうだが、別に全然消え去ったワケじゃないよ
.NETはまあ2.0で随分変わるがJavaのTigerだって似たようなモンだろ
0496デフォルトの名無しさん
2005/09/02(金) 00:34:281) ServletContextListenerを使うのがいいんじゃね？
初期化専用Servletを使うのはServlet2.2の頃のやり方。
2) 1. ManagedPropertyでDIする。
2. ValidableResolverから名前を指定して取得する。
2.はExternalContextから取得する方法もあまり変わらない気もする。
まあ、ScopeとBean名はアプリにべた書きでもいいんじゃね？
JSPのVB式にもべた書きだろ？型名をべた書きじゃなきゃいいと思う。
これ以降はスレ違いだからこっちへ移動汁↓
JSF(JavaServer Faces)【.NET死亡？！！！】
http://pc8.2ch.net/test/read.cgi/tech/1059208396/
0497デフォルトの名無しさん
2005/09/02(金) 00:35:170498デフォルトの名無しさん
2005/09/02(金) 00:37:12＞俺的には断然否だな。
キミがここで何を叫ぼうが現実は現実。普及したものが勝ちだよ世の中は。
それはかつてMSがさんざん証明してきた真理。
＞ちなみに.NETは結構ウチの会社では使われてるよ。
キミの廻りの話なんて聞いてない（しかも根拠がないから信じろと言われても無理）。
＞時期尚早
＞技術者がまだ少ない
＞枯れてないのが不安
.NET厨が必ず使うよねこの一連のセリフ・・・.NETが登場してから一体何年たってると
思ってるんだ？？いい加減目を覚ませよ。
0499デフォルトの名無しさん
2005/09/02(金) 00:38:44.NETは2000年夏に登場で5年後の今年もぜんぜんぱっとしないなあ。
0500デフォルトの名無しさん
2005/09/02(金) 00:42:40いや、俺的には勝ち＝優れているとは全然思ってないだけ。
WindowsのC++フレームワークのデファクトになったMFCなんぞ
まさに糞の塊だし。まさに、「勝っただけ」の典型。
時期尚早はただの事実だろ。クライアントサイドで普及するには
Longhornを待つしかない。で、クライアントサイドでは別に
Javaは勝っていない。
MSはRADとしてVB6.0系列は止めちまったから、クライアントは
.NETに移行していくしかない。そうやって技術者が育ってくれば
サーバサイドにも当然動きが出てくるだろう。
ま、それでもC++やCOMが完全に置換されることは無いだろうけどね。
0501デフォルトの名無しさん
2005/09/02(金) 00:43:10今時はやらないんだな＿|￣|○||| 何時の間にやら時代遅れ……
0502デフォルトの名無しさん
2005/09/02(金) 00:44:38回答トンクス。
>>501
別にやってもいいんじゃないの？
今時はダッセーとか言われるのかもしれないけれど。
0503デフォルトの名無しさん
2005/09/02(金) 01:22:22サーバーサイドと言ってもいろいろなので。
以前ASPでやってたようなイントラ系の案件なら、ASP.NETに移行するのに何ら
問題はない気がする。
Javaであっても、SunやIBMに振り回されるのはかわらんだろう。まあ
程度問題ではあるけれども。
0504デフォルトの名無しさん
2005/09/02(金) 02:54:19サンプルを見ながら作ってまず思ったのは「セッション管理はどうすんの？」
で、次に思ったのは「jspに直でアクセスされたらどうすんの？｣なんですが、
ここらへんはどう解決するのがスタンダードなんでしょうか。
買った本のサンプルでは直でURL叩いたらフツーに表示されて鬱になりました。
層が違うとかJSFと関係ねーとかボロクソ言われそうな確信に近い予感がするんですが、
スレ違いだったら容赦くださいませ。
なんか夢のような話がいっぱい書いてあってやってみたくなったんだけど、
オレの能力ではなかなか前途は暗そうです。
つーか、そもそもJavaとかServletの知識も足りん気もします。
Javaの言語的な知識一通り+Servletのお勉強（モア・サーブレットで一通り）+Struts（+hibernate)の業務経験半年。
Webアプリ自体はレガシASPで過去2年ぐらいやってます。
ちなみに、今までのスタンスは、
セッション管理
フレームワークから生のセッションをｹﾞｯﾄしてｺﾁｮｺﾁｮチェックしてどうこうする。
jsp直アクセス
(ﾟ⊿ﾟ)ｼﾗﾈ。既存のがなんにも対策してないから俺もやらね。
でした。
0505デフォルトの名無しさん
2005/09/02(金) 06:59:29普通にManagedBeanのスコープをsessionにすればいいだけじゃないのか？
何を問題にしているのかさっぱりわからん。
＞「jspに直でアクセスされたらどうすんの？
WEB-INFの下にでも置いておけ。JSFだからという問題ではないだろ。
0506デフォルトの名無しさん
2005/09/02(金) 12:51:26あなたが純粋なアプリ屋で、アプリ基盤とか共通チームとか言われるチームから
サポートを受けられる立場なら、細かいところは任せちゃった方がいいです。
逆に、自分でそこまで見なきゃ行けない立場なら、まずはServletレベルから
ちゃんと勉強した方がいいです。
0507デフォルトの名無しさん
2005/09/02(金) 19:41:20Oかもと氏はContributerであって、Comitterではない。
いやあ、いつのまにコミッタに！？と一瞬あせったぞ。
0508デフォルトの名無しさん
2005/09/02(金) 19:42:350509デフォルトの名無しさん
2005/09/02(金) 20:36:48直接的なセッション管理についてはあまり気にすることはない、という感じかしら。
JSFはそういう汚いものをなるべく隠すようにデザインされてるから。
HttpSession#setAttribute()で明示的にオブジェクトを保存するかわりに、
SessionスコープのManagedBeanを使うのがJSFのやりかた。
JSFServlet通さずにJSFなjspに直接アクセスされたら、単に500になるだけでしょ。
0510504
2005/09/03(土) 00:41:37私がセッション管理と呼んでいたのはいわゆるログイン認証が必要な
サイトでのログイン状態の管理のことでした。
ログイン時に入力情報をセッションに格納し、その後リクエストごとに
セッションの情報を使って認証し、正当なものにのみリクエストされたページを
表示し、ダメならログインページにリダイレクト、
という処理をどう実装すべきなのかがぜんぜん思いつきません。
パッと思いついたのがFilterでHttpSessionを触ることなんですけど、どうなんでしょうか。
もはやJSFぜんぜん関係ないかもですが、ご指導お願いいたします。
0511デフォルトの名無しさん
2005/09/03(土) 09:59:06ログインページからsessionスコープのManagedBeanを呼び、そこにログイン状態を保持
ログインチェックはFilterで行い、Sessionからログインで使ったManagedBeanをチェックする。
ただし、ログインページから飛ぶときだけはチェックの対象外とする。
でいけるんじゃないの？
ただ、Strutsのときはログイン時のsubmit先のURLがすぐわかったけど、JSFではどうなるんだっけ？
0512デフォルトの名無しさん
2005/09/03(土) 10:11:33JSFを使ったフォームの場合は、送信先URLは自ページだよ。
送信元はわかるから、送信元がログインページかどうかを判断すればいいんじゃね？
0513デフォルトの名無しさん
2005/09/03(土) 10:37:56JSFではExternalContext経由で比較的低レベルの機能にアクセスできるよ。
もちろんSessionも触れるしRedirectもできる。
「リクエスト受信時に何かしたい」ような場合、まあServletFilterでも
いいんだけど、JSF的にはPhaseListenerを使うという選択肢もあるんじゃない
のかな。
0514デフォルトの名無しさん
2005/09/03(土) 12:00:34テーブル定義はこうして、こういった画面つくって、こういった設定、コードを書けば、
ログイン認証ができるよという明確なサンプル的なものが欲しいのですが？
それとも現時点ではJSFでは処理が複雑なのでしょうか？
それとも、ここの技術者レベルが低いのでしょうか？
0515デフォルトの名無しさん
2005/09/03(土) 13:48:16一冊、本買ってこいよ。
0516デフォルトの名無しさん
2005/09/03(土) 13:59:47JSFをメインに書いているような本は２，３冊買いました。
雑誌などで特集してるものも含めると10冊以上買いました。
しかし、雑誌などではコンポーネントとかの使い方などに注力しています。
また、ログイン画面などのサンプル的なものは存在しましたが、
やっていたのは、ログイン後にプログラムの中で固定でユーザ名とパスワードを
ifで判別してエラーメッセージを出して終わりとかその程度です。
実際に仕事で使えるレベルのサンプルが欲しいのですが、
書籍を書いている人も技術レベルが低かったり実務やってないのでしょうか？
0517デフォルトの名無しさん
2005/09/03(土) 14:47:500518デフォルトの名無しさん
2005/09/03(土) 14:51:49あなたの技術レベルというか知能レベルが低すぎるのです。
0519デフォルトの名無しさん
2005/09/03(土) 14:54:56突然逆切れか。しかも仕事か（苦笑）
お前、それでよく給料貰ってるな……。
0520デフォルトの名無しさん
2005/09/03(土) 15:06:31・本をたくさん読んだけどわからなかった
・本のレベルが低すぎるに違いない
・JSFが難しすぎるに違いない
・決して自分がバカなのではない
こいつの何がバカかって、514、516の最後の1行さえ書かなければ、それなりの意見がでてたかもしれないってところだ。
0521デフォルトの名無しさん
2005/09/03(土) 15:31:48そのif文を書き換えるだけで良いという考えが、技術力の低さ・業務での開発が分かってない、
典型的な例だと思います。
>>519
JSFでまだ仕事はしてません。
Strutsでの開発をしていますが、今後を考えての勉強です。
>>520
＞・本をたくさん読んだけどわからなかった
＞・本のレベルが低すぎるに違いない
これは、その通りでは？
単純に、その本が何をターゲットにしてるかが違うだけという事もありますが、
あまりにも仕事レベルで使えるものが少ない。
＞・JSFが難しすぎるに違いない
これは、勉強中なので何とも言えません。
＞・決して自分がバカなのではない
馬鹿では無いと思います。
＞こいつの何がバカかって、514、516の最後の1行さえ書かなければ、それなりの意見がでてたかもしれないってところだ。
ただの言い訳ですね。
これを言うからには、それなりの意見をだして納得させた上で、”馬鹿”だの言ってもらいたい。
意見が出なければ、技術レベルの低い人間しか居ない。
意見が出れば、素直に自分が馬鹿と認め、謝罪でもなんでもしますよ。
0522デフォルトの名無しさん
2005/09/03(土) 16:19:21という発想をする職業エンジニアがいることに驚いた。
自分で応用ができないレベルでしかないのに
本のレベルが低すぎるなんてよく言い切れるものだ。
0523デフォルトの名無しさん
2005/09/03(土) 16:25:080524504
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的には）どうすればいいんだろう。
ここでやるのは正しいんでしょうか。
0525デフォルトの名無しさん
2005/09/03(土) 16:54:21現在のバージョン(1.1)とその次のバージョン(1.2)ではJSF仕様で保証されている。
将来のバージョンではわからないけどね。
0526デフォルトの名無しさん
2005/09/03(土) 16:59:26どのみち、今のところ、それしかManagedBeanを参照する綺麗な方法が無いと
思う。あきらめれ。
0527デフォルトの名無しさん
2005/09/04(日) 01:37:56> そのif文を書き換えるだけで良いという考えが、技術力の低さ・業務での開発が分かってない、
> 典型的な例だと思います。
そうだねぇ。
キミの技術力の低さや、そんな技術力で業務での開発をやらないといけない事情を分かってないとは言える。
0528デフォルトの名無しさん
2005/09/04(日) 04:45:210529デフォルトの名無しさん
2005/09/04(日) 06:40:350530デフォルトの名無しさん
2005/09/04(日) 09:15:38それはJAAS実装でなくて？
それとも、俺様の知らない、Tomcat独自の秘密の認証機能があるのか？
0531デフォルトの名無しさん
2005/09/04(日) 13:59:41仕様を満たしてない部分があるとかかも。
どっちにしろJDBCやらLDAPのRealm作れば普通のWebアプリの認証は実現できるっしょ。
Tomcatだったら JdbcRealmは実装提供されてなかったっけ？
0532デフォルトの名無しさん
2005/09/04(日) 14:04:28TomcatにもJDBC Realmあるよ。
0533デフォルトの名無しさん
2005/09/04(日) 18:52:18JSFのELで取得するには、どのオブジェクトのなんという属性を
参照すればいいんでしょうか？
どういう暗黙オブジェクトがあるかというドキュメントは見ますが、
それぞれどういう情報を持っているかという資料は見つけられません。
どこかにいい資料はないものでしょうか？
#もしかして、中身については何も規定がなく、実装に依存する？
0534デフォルトの名無しさん
2005/09/04(日) 20:16:07> どこかにいい資料はないものでしょうか？
http://www.ingrid.org/jajakarta/servletapi/servletapi-4.0/docs-ja/
0535デフォルトの名無しさん
2005/09/04(日) 20:33:040536533
2005/09/04(日) 20:35:58というのも、BackingBeanはあくまでもPOJOのままにしておきたい
(=FacesContextなどは参照しない)→とするとfaces-config.xml内で
<managed-property>で外部から値を設定してやる必要がある→
ここに記述できるのはELだから、なんとかしてELで実ディレクトリを
求められないか？という流れです。
他にうまいこと外部から値を注入してやる方法があれば、それでも
いいんですが。
0537デフォルトの名無しさん
2005/09/04(日) 20:40:26何をしたいのか処理の順番が分からないから答えにならないかもしれないけど
普通にサーバ側のページ初期化アクションでbean.setPath()とかやるのはダメなの？＿
0538デフォルトの名無しさん
2005/09/04(日) 20:52:150539デフォルトの名無しさん
2005/09/04(日) 21:01:16<managed-property>の<value>に直接書くのは無しかな？
faces-config.xml にも環境依存の情報は書きたくない？
話しは少しずれるんだけど、
＞BackingBeanはあくまでもPOJOのままにしておきたい
これ、実は結構難しくない？俺もテストファーストでBeanを作ろうと
思ったんだけど、出力メッセージをFacesContextに入れるところや
UIComponentのComponent Bindingで断念した。orz
0540デフォルトの名無しさん
2005/09/04(日) 21:06:59これ、実は結構難しくない？俺もテストファーストでBeanを作ろうと
思ったんだけど、出力メッセージをFacesContextに入れるところや
UIComponentのComponent Bindingで断念した。orz
分かる、非常に同感
なんかさ、くちゃくちゃになるんだよねいろんなとこでいろんなことしたりしちゃって・・・
結局 static FacesContext.getCurrentContext()だっけ？
こいつが悪であり、しかしこいつがある理由が分かるような気がしないでもない
0541デフォルトの名無しさん
2005/09/04(日) 21:22:22JSFだとBeanがPOJOで作れてテストがカンタン！なんて幻想だったよ・・・orz
0542デフォルトの名無しさん
2005/09/04(日) 21:26:47コンバータ・バリデータ・アクションって分けて開発できることかなぁ
初心者にはコンバータ・バリデータ書かせておけばよいし
0543533
2005/09/04(日) 21:40:02JSFは始めたばかりなんで、原則通りやってみようと考えて
いるんですが、現実には理想通りにいかない部分もあるん
ですね。
その後調べてみて、やはりELで直接取得するのは難しい
ようなので、代替案を考えました。
1. applicationスコープのbeanをひとつだけ用意し、この
生成時に実ディレクトリを取得しプロパティに保持
(これだけコンテナ依存)
2. その他のbean(sessionスコープ)は<managed-property>で
上記beanのプロパティ値をセット
試したところうまく動くようですので、これでいってみようと思います。
開発環境と運用環境が違うので、faces-config.xmlに環境
依存情報を記述するのは避けたいですね。それよりはまだ
コンテナ依存の方が許容できます。
0544デフォルトの名無しさん
2005/09/04(日) 21:47:06そのパスって動的に変わる値だと思ってたけど固定なのね；；
ならば、web.xmlに環境変数として希望するパスの情報書くのはダメなのかな
<resource-env-ref> とか<env-entry>とか
0545デフォルトの名無しさん
2005/09/05(月) 02:19:29http://www.ingrid.org/jajakarta/
が引用されるのがさびしい限りだ。
0546デフォルトの名無しさん
2005/09/05(月) 14:03:49遅レスだけどJSFにこだわらないでこれでいいと思うけど...
>だったらManaged Beanに頼る意味あるのかなあ。どうせServletFilterで生のセッション触るなら
>ログイン情報もログイン時にHttpSessionに直に書いてもいいんじゃないだろうか、とか。
あとはServletFilterのInitParameterで認証失敗時の遷移先URIやチェック除外対象のURIのリスト
とかを設定できるようにすればいいんじゃないの？
0547504
2005/09/06(火) 00:59:21>525
仕様で決まっていたんですか。知らなかったです。不勉強でした。
そういうことだったらログイン時のManagedBeanをServletFilterでチェックする
というやり方で問題なく対処できそうです。
ありがとうございます。
Tomcatの認証はLDAP使ってやったことはあります。
その時も理屈が理解できてないのに機能だけ使うのに抵抗を感じ、
アプリケーション内で実装しようと目論んだわけですが。
なんせJAASという単語も今知ったくらいなので、これからお勉強して手の内
に入れたらそういう便利なしくみを使うのもよいかなーと思います。
でも、頭が悪いのか、チュートリアル読んでもｲﾏｲﾁ理解できませんが。
精進します。
>546
ええ。それでもいいわけですよね。むしろ、そうあるべきなのか。
そして、JSFと全然関係ないスレ違いな質問をしていたのだという事実にようやく気付いたりしつつ。
0548デフォルトの名無しさん
2005/09/06(火) 17:42:19新人達がJSFで社内ツール作らされてちゃんと作ってたみたいだけど、
どうやってたんだろう？
イントラだからセキュリティは若干甘いかもしれないけど
0549デフォルトの名無しさん
2005/09/06(火) 19:42:49そんなこたあ無いでしょ
別に（ふつうの）Servletや非JSFページとも併用できるんだし
0550463
2005/09/10(土) 16:17:26まず、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って本当に現場わかった人間が設計してるのか怪しい感じ。
0551463
2005/09/10(土) 16:29:52警告: 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製品はすぐにバージョンアップしてという意見もあったけど、どうせ２、３年とか
長くても5年ぐらいでシステム入れ替える癖に無駄な意見だよな・・・
0552名無しさん＠そうだ選挙に行こう
2005/09/10(土) 19:30:260553名無しさん＠そうだ選挙に行こう
2005/09/11(日) 02:06:07このへんからトラップのにおひがするぉ
0554名無しさん＠そうだ選挙に行こう
2005/09/11(日) 07:38:48いや、フレームワーク自体は無料だろ。
有料なのは開発環境な訳だし。
.NETFrameworkSDKは無料でダウンロードできるし、
メモ帳とかでソースコード書いてコマンドラインでコンパイルすれば、そのまま配布もできるし。
0555名無しさん＠そうだ選挙に行こう
2005/09/11(日) 08:48:43ここはJavaのほうが総合的に良いと思って使っている人たちのスレ。
0556名無しさん＠そうだ選挙に行こう
2005/09/11(日) 12:06:150557名無しさん＠そうだ選挙に行こう
2005/09/11(日) 12:17:42EclipseでだってC#とか書けるし、WebだけでいえばWebMatrixとかもあるし。
0558名無しさん＠そうだ選挙に行こう
2005/09/11(日) 13:37:24＞確かに何かの値によって必須入力チェックしたりしなかったりというのは有りだよな。
まぁ、このスレの他の奴のレベルが低いんだろうから答えてやるよ。
エラーチェック用の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("エラーメッセージ"))
とかすればいい。
0559名無しさん＠そうだ選挙に行こう
2005/09/11(日) 13:47:59値が未入力の場合、Validatorにそもそも渡らなかった気がするんだが、気のせい？
0560名無しさん＠そうだ選挙に行こう
2005/09/11(日) 14:12:05SUN実装は使ったことないから分からない。
とりあえず、MyFacesでは問題無かった。
それと、余談になるんだが、お前様方の周辺でJSFってどんなかんじ？
俺の場合、会社だと新規のJava案件は殆どWebSphereを使うから、JSF使ってるから、
結構流行ってると言えば、流行ってるんだけど、他ではどうかとちょっと気になった。
0561463
2005/09/11(日) 14:36:10なるほど、独自にチェックするしかないのね。
確かに出来そうだと思ったが、
>>559が書いてるようにMyFacesでも値が未入力だとValidatorに行かないな。
>>558=>>560も低レベル技術者のようで・・・
つうか、この辺はStrutsの方がマシだな。
登場してからの歴史が長いってのもあるんだろうな。
でも、JSFはやっぱいUIだけって感じなんだろうな。
だからStrutsとJSFが連携できるようになってるんだろうな。
Strutsを補う意味でJSFを使うのかと思ってたけど、
本当はJSFの貧弱さを隠すためだったんだな。
この辺を見ると、.NETFrameworkって素晴らしいと本当に実感したよ。
0562名無しさん＠そうだ選挙に行こう
2005/09/11(日) 14:51:29とりあえず、「h:output_text」とか書いてある古いJSFの資料は捨てちゃっても構わないよね？
0563463
2005/09/11(日) 15:11:38＞このスレとしてはJSF＞＞＞＞＞(超えられない壁)＞＞＞ASP.NETであってほしいが、そうもいかないって事か。
まぁ、スレ的にはそうだろうね。
俺も、ASP.NETマンセーと"だけ"言いたい訳じゃない。
Web開発者としては、提案するときに色々な選択肢がある訳で、
『こういった理由で○○をつかいます』と客に提案したい訳よ。
だから、JSFなりStrutsなりを勉強してる訳だけども、結局、両方使ってみると
ASP.NET＞＞＞＞＞＞＞＞＞（超えられない壁）＞＞＞＞＞＞＞＞＞＞＞JSF
なんだよね。
JSFなりStrutsが本当に使える物であるならば、俺はむしろJava信者になっても構わないんだけどね。
＞とりあえず、「h:output_text」とか書いてある古いJSFの資料は捨てちゃっても構わないよね？
いいの？
Javaとかオープンソースって聞くと、例えバージョンが古くなったりしても、
ソースコードとかがあるからどうにでもなるってのも１つのメリットとしてよくあがるけど、
資料捨てて、数年後とか失敗したと思わなければいいんだけど。
俺の会社のJava開発チームは、前世紀からのJava資料を全部保管してるよ。
つうか、この資料だけで、会社の倉庫の半分使ってるんだけど・・・・
まぁ、あまりJSFやStrutsのスレが盛り上がってない事から見ても、きっと下火なんだろうね。
それと、最近、やけにJavaの技術者いませんか？との問い合わせが会社に多い。
聞くと、殆ど新規案件じゃなくて仕様変更なり拡張。
『今までの開発先は？』と聞くと『Java案件はもうやってない』とかで俺の会社とかに問い合わせがくるけど、
実際問題どうなの？
俺の会社やオフシェア先の中国でも、最近はASP.NETとかに以降してるから、
Java技術者って、実はこの先、仕事ないんじゃ？
0564名無しさん＠そうだ選挙に行こう
2005/09/11(日) 16:41:41今はまだ数で圧倒的ではあるけど、難しい局面になってることは確かだな。
0565名無しさん＠そうだ選挙に行こう
2005/09/11(日) 17:46:49中国は国家主導でLinuxの導入進めてる。
個人レベルではWindowsのシェアが高いけど、企業レベルでは殆どがLinux環境。
0566名無しさん＠そうだ選挙に行こう
2005/09/11(日) 18:20:02別に国家レベルでLinux導入進めていたって、その中国の人間の客は日本なんだから、
日本向けに技術者を教育なり集めるのが普通だろ。
中国とかは関係無いよ。
あくまで客である日本企業の需要に合わせる。
俺らだって、客先が有無を言わさず『Linuxで！！』と言われればLinux使うし、
『Linuxは絶対に駄目。Windowsサーバで！！』と言われればそれに従うだけだし。
0567名無しさん＠そうだ選挙に行こう
2005/09/11(日) 18:42:37「JSF フォーラム」で検索すると「日本宇宙フォーラム」や「ヤパーナ社会フォーラム もう一つの世界は可能だ」
とか、変なものがヒットするんだが。
0568名無しさん＠そうだ選挙に行こう
2005/09/11(日) 19:11:44だから、流行ってないんだって。
むしろ、Seasar2のS2JSFのメーリングリストとかの方が活発に意見交換されている。
だけど、あそこはあくまでもS2JSFの話題だからなぁ。
基本的にはJSFを使用するのは時期尚早って感じなんじゃない？
だから、このスレとかでもあまり意見交換って行われてないじゃん。
JSFが気になった奴もちょっと使ってみて、『つかえねぇ』と感じて、
結局今まで通りって流れのような気がする・・・俺のように・・・
0569名無しさん＠そうだ選挙に行こう
2005/09/11(日) 19:25:51適当に探してみた
jsf-jp JavaServer Facesに関するMLです。
http://groups.yahoo.co.jp/group/jsf-jp/
@ITのJava Solution 会議室
http://www.atmarkit.co.jp/bbs/phpBB/viewforum.php?forum=12
0570名無しさん＠そうだ選挙に行こう
2005/09/11(日) 20:19:47どうもここ見る限りでは浸透していない様子だなぁ・・・
あぼんの予感がする
0571名無しさん＠そうだ選挙に行こう
2005/09/11(日) 20:23:43実装による質のばらつきもまだまだ多いし。
初期のServletコンテナもベンダーによる質のばらつきが多かったのに似ている希ガス。
各ベンダーやオープンソースによる実装が安定して、さらに
オープンソースの高機能なJSF開発環境やEclipseプラグインが
出てくると一気に普及すると思うけどな・・・。
0572デフォルトの名無しさん
2005/09/12(月) 01:51:49代わっても1.2見るだけでも局所的及び一部分だ。だとすると覚えるのは
モデルだけで後は、どうやって利用するかどこに利用できるかってことに
今は知恵を使ったほうがいいよ。現状のレベルだといきなりASP置き換えはﾑﾘ
それだとどこまでのレベルで使えるのか判断したほうがいいよ
Webspherは全部のプロジェクトでつかえるものではないしな
0573デフォルトの名無しさん
2005/09/12(月) 22:47:10ASP.NETの対抗馬としてサンは開発環境込みで広めたかったんだろうが、
Eclipseで開発できない限りJavaの世界じゃ広まらないからな
0574デフォルトの名無しさん
2005/09/13(火) 01:57:34こんなところが実装するソフトウェア基盤はゴミでしかない。M$の金魚の糞は
つぶれたほうがいいよ
0575デフォルトの名無しさん
2005/09/14(水) 04:26:15＞Eclipseで開発できない限りJavaの世界じゃ広まらないからな
Eclipseでの開発の有無より、スレ見てる限りJSFの仕様（実装）が糞だから
みんな使わない（業務で役に立たない）んじゃない？
0576デフォルトの名無しさん
2005/09/14(水) 08:02:40いや、仕様よりもEclipseだろ
0577デフォルトの名無しさん
2005/09/14(水) 08:12:350578デフォルトの名無しさん
2005/09/14(水) 21:00:29あとは日本語のマニュアルｗ
0579デフォルトの名無しさん
2005/09/15(木) 15:04:20Googleだと古い方のページがトップですが、
新オフイシャルサーバを参照する方がよいですよね。
「Servlet および JavaServer Pages API ドキュメント (Tomcat 4.0)」
http://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)
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/servletapi/
JavaServer Pages API Documentation (Tomcat 5.5)
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jspapi/
Servlet API Documentation (Tomcat 5.0)
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/servletapi/
JavaServer Pages API Documentation (Tomcat 5.0)
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jspapi/
Servlet and JavaServer Pages API Documentation (Tomcat 4.1)
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/servletapi/
JSFもそうですが、最新バージョンの日本語マニュアル欲しいですね。
0580デフォルトの名無しさん
2005/09/16(金) 00:48:260581デフォルトの名無しさん
2005/09/16(金) 01:34:44えらいねぇ。
漏れはもうStrutsなりJSFなりがないとしんどくてだめだよ。
0582デフォルトの名無しさん
2005/09/16(金) 01:43:17Velocity使うより、ふつうにJSPで充分。
というかVelocityよりはJSPのほうがいい。
0583デフォルトの名無しさん
2005/09/16(金) 03:12:55マクロファイル大量に分ければいいか・・・
0584デフォルトの名無しさん
2005/09/16(金) 03:14:15HTML出力以外だと便利だけど。
JSPでよくない？
0585デフォルトの名無しさん
2005/09/16(金) 13:35:110586デフォルトの名無しさん
2005/09/16(金) 13:56:31デザイナからするとJSPよりVelocityのほうが扱いやすいらしいよ
0587デフォルトの名無しさん
2005/09/16(金) 14:11:06いろいろ毎日忙しくて
まだ検証にも踏み切ってないんだけど
実務に使えそう？
0588デフォルトの名無しさん
2005/09/16(金) 14:22:56#ifとかがプレビューで見えたほうがいいってこと？
0589デフォルトの名無しさん
2005/09/16(金) 15:29:18パフォーマンス的な事を言ってるなら、Velocityを使えると考えるなら
それと同じくらいには使える。
CSSを用いればHTMLからレイアウトと装飾を分離できる。
ってのは最近では当たり前に知られてる利点だけど、それと同じ感
覚でWEBアプリ依存部分を分離できる。
これを逆に(Seasar的に)見ると、MayaファイルでHTMLに対してWEB
アプリへの依存性を注入してる(所謂DI)とも言える。
あと、XPathを利用した複数箇所に現れる同一タグへの処理はAOP
的。こういった辺りが概念的に気持ちイイ！
0590デフォルトの名無しさん
2005/09/16(金) 16:31:57そういうのわかりやすくまとめてある資料ってありますか？
0591デフォルトの名無しさん
2005/09/16(金) 17:10:21http://maya.sandbox.seasar.org/
ここ読んであとはサンプル弄ってみるくらいかな？
hoge.htmlとhoge.mayaが組になってる事さえ意識できれば
変更、結果表示の繰り返しで触れるようになると思うよ。
■ このスレッドは過去ログ倉庫に格納されています