JSF(JavaServer Faces)【.NET死亡？！！！】

JSF(JavaServer Faces ..

480:463
05/09/01 22:46:30
>>478
なら、そのまともな実装とやらを教えてくれよ。
俺のJavaの知識は1週間しかないんだよ。

1週間程度勉強した奴にここまで突っ込まれて、理論的にも反論できないってどういう事よ。

481:デフォルトの名無しさん
05/09/01 22:49:00
いやホント　.Net 案件無いんですわ
たのんますよ

482:463
05/09/01 22:53:24
そりゃ下請け、孫受けじゃ案件ないだろ。
俺の会社がそうだけど、元請けがしっかりと.NET案件でJavaと同じ期間・金額で見積もって
儲けてるからな。

いまやJava技術者は過剰供給で単価が安い。
しかも、トラブル続出、開発工数は膨らんで大変だから、下請けに丸投げする。

483:デフォルトの名無しさん
05/09/01 23:06:03
>>480
IBMの実装でも試してみろよ。
期間限定（30日だったかな？）なら無料で使えるから。

484:デフォルトの名無しさん
05/09/01 23:08:54
>>480
＞ 1週間程度勉強した奴にここまで突っ込まれて、理論的にも反論できないってどういう事よ。
糞実装と比較して文句たれて、どんな人物が開発してるかも知らずに「Apache」というだけで「本業で開発」と決めつけてる
ような奴に、「ここまで突っ込まれて」とも思わないのだが？

485:デフォルトの名無しさん
05/09/01 23:44:31
糞実装のMyFacesでも、少し前に新人に作らせた.NETプログラム（C#）よりはまともだ
だから、Javaの勝ちだな

486:デフォルトの名無しさん
05/09/01 23:54:22
>>474
> しかし静的コンテンツが殆ど無いにも関わらず、なんでも連携してる感があるのは否めない。

普通は画像が大量にあったりするが、しょぼいイントラしかやったことないのか？
まー、検証もせずに Apache と連携させなきゃならんと思い込んでる人間が多いのは同意で
ローカル開発環境でも教科書どおりに Apache + Tomcat とか意味分からんとやってるプロジェクトが多い。
なぜローカル環境でも Apache と連携してるの？とか聞いたら、え？無くてもいいの？
とかいうプロジェクトは俺が Tomcat のみで稼動するように今まで置き換えてきた。
SSL もクラスタリングも仮想ホストも Tomcat で出来るしな。

.NET のほうが楽なのは同意。.NET はそんなに経験ないがサクサク作れた。
ちょっと変わったことしようとしたら、ハマったが、それは経験不足だったからかもしれない。
悪くいうつもりは無いが、Java はもっとバカ向けに作られてもいいと思う。
DI やら AOP は便利だが、作ってる奴らが技術自体に酔ってる気がしてならない。
自分でも Javassist や CGLIB で AOP 組んだが確かにおもしろい。
そういう低レベルな技術が見えない .NET とは思想の差か。

487:デフォルトの名無しさん
05/09/02 00:08:01
>>486
> ちょっと変わったことしようとしたら、ハマったが、それは経験不足だったからかもしれない。
俺もそこにギャップを感じた。
ありきたりの、おきまりのことをやるだけなら簡単なのだが、想定外の要件に対応しづらい。

488:デフォルトの名無しさん
05/09/02 00:14:06
>>486
.NETにもCodeDOMを使ったAOP実装とか、IoCコンテナでDelegateInjectionとか
.NETでも独自の特色を活かした技術的酔いどれは色々模索されてるよ。
２ちゃんで話題にならないのはレベルの差かｗ

489:デフォルトの名無しさん
05/09/02 00:17:32
2chで議論するまでもなく、.NETとJavaのどちらが優れているかなんて市場（経済）が証明している。
.NETなんて「そのうちJavaを追い越す」なんて5年前から言われていて、いつまでたってもてんで普及しない。
Java＞＞＞＞＞.NETなのは某255が暴れていた5年前から変わらなかったし、これからもそう簡単には変わらないよ。

うちらがここでどう議論しようが、それが現実の企業の下している結果なんだから仕方ないじゃん。
これはJSFがいまだ流行らず従来のJ2EE仕様で現場が満足しているという状況にも同じことがいえるが。

つうかなんでいまさら.NET vs Javaをこのスレでやらにゃならんのだ？

490:デフォルトの名無しさん
05/09/02 00:18:56
流れを読まずに低レベルな質問。

1) JSFでWebアプリの初期化仕事をしたい場合ってどうするのが
　一般的？初期化専用のServletを作るしかないのかな？

2) ManagedBeanを取得／参照する一般的な方法はなに？
　Session/Request/ContextをFacesContext経由で取得して
　Bean名で参照すれば可能なのは分かるんだけど、
　ScopeとBean名はfaces-config.xmlで設定するわけなんで、
　↑のようなのをベタでやるのはキモチ悪いんですが。

491:デフォルトの名無しさん
05/09/02 00:23:32
>>489
＞これはJSFがいまだ流行らず従来のJ2EE仕様で現場が満足しているという状況にも同じことがいえるが。
これは来年が勝負だな。Java EEの標準仕様としてJSFが組み込まれるから、各ベンダーや開発環境の対応が充実してくると思われる。

.NETが普及しないのは、特定の企業の囲い込まれたくない、という企業や公共機関の思惑もありそう。
特定の企業の方針に振り回されたりぼったくられたりするのはカンベンだ、という。
あるいは、政府や公共機関だと特定企業との癒着イメージを付けたくないとか。

＞つうかなんでいまさら.NET vs Javaをこのスレでやらにゃならんのだ？
それは、このスレがアンチスレだからだ。ここは>>1の空気を読んで欲しいところ。

492:デフォルトの名無しさん
05/09/02 00:24:13
>>488
大多数のドトネト厨はそんなところをキャッチアップできないDQNだからな。

493:デフォルトの名無しさん
05/09/02 00:29:02
>>489
市場経済で何かが主流になっている＝優れている？
俺的には断然否だな。

ハリウッドやオリコンチャートやベストセラーなんぞ糞だし
大企業の工業生産された酒よりは断然地酒だし
VHSよりベータだし

ちなみに.NETは結構ウチの会社では使われてるよ。
.NETがJavaほど使われてない主な理由って

・クライアント向けに使うにはまだ時期尚早（バカでかい.NET Flamework
　入れなきゃいかんしVBあたりに比べても重い）
・サーバサイドで使うとしてもIIS＋Win限定ではなんかヤだ
・技術者がまだ少ない
・枯れてないのが不安

ってなあたりでしょ。アーキテクチャの優劣以外の問題のがデカいと思う

494:デフォルトの名無しさん
05/09/02 00:30:50
MSの技術はすぐに廃れるから信用できない。
かつてWindowsアプリ開発のスタンダードだったMFCでさえ、
今ではC++と共にすいたいしてしまった。
.NETだって1.0と1.1じゃえらい違いだ。

495:デフォルトの名無しさん
05/09/02 00:32:32
>>494
MFCは十分長生きしたと思うけどね
それにC++もそうだが、別に全然消え去ったワケじゃないよ

.NETはまあ2.0で随分変わるがJavaのTigerだって似たようなモンだろ

496:デフォルトの名無しさん
05/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死亡？！！！】
ｽﾚﾘﾝｸ(tech板)

497:デフォルトの名無しさん
05/09/02 00:35:17
ｽﾏｿ。俺がスレ間違えてた・・・

498:デフォルトの名無しさん
05/09/02 00:37:12
＞市場経済で何かが主流になっている＝優れている？
＞俺的には断然否だな。

キミがここで何を叫ぼうが現実は現実。普及したものが勝ちだよ世の中は。
それはかつてMSがさんざん証明してきた真理。

＞ちなみに.NETは結構ウチの会社では使われてるよ。

キミの廻りの話なんて聞いてない（しかも根拠がないから信じろと言われても無理）。

＞時期尚早
＞技術者がまだ少ない
＞枯れてないのが不安

.NET厨が必ず使うよねこの一連のセリフ・・・.NETが登場してから一体何年たってると
思ってるんだ？？いい加減目を覚ませよ。

499:デフォルトの名無しさん
05/09/02 00:38:44
Javaは1995年登場で5年後の2000年にはサーバサイドをかっさらっていったよなあ。
.NETは2000年夏に登場で5年後の今年もぜんぜんぱっとしないなあ。

500:デフォルトの名無しさん
05/09/02 00:42:40
>>498
いや、俺的には勝ち＝優れているとは全然思ってないだけ。
WindowsのC++フレームワークのデファクトになったMFCなんぞ
まさに糞の塊だし。まさに、「勝っただけ」の典型。

時期尚早はただの事実だろ。クライアントサイドで普及するには
Longhornを待つしかない。で、クライアントサイドでは別に
Javaは勝っていない。
MSはRADとしてVB6.0系列は止めちまったから、クライアントは
.NETに移行していくしかない。そうやって技術者が育ってくれば
サーバサイドにも当然動きが出てくるだろう。

ま、それでもC++やCOMが完全に置換されることは無いだろうけどね。

501:デフォルトの名無しさん
05/09/02 00:43:10
ｶﾞﾋﾞ━(ﾟДﾟ;)━━ﾝ!!!!! load-on-startupでホゲフガガって
今時はやらないんだな＿|￣|○||| 何時の間にやら時代遅れ……

502:デフォルトの名無しさん
05/09/02 00:44:38
>>496
回答トンクス。
>>501
別にやってもいいんじゃないの？
今時はダッセーとか言われるのかもしれないけれど。

503:デフォルトの名無しさん
05/09/02 01:22:22
>>491
サーバーサイドと言ってもいろいろなので。
以前ASPでやってたようなイントラ系の案件なら、ASP.NETに移行するのに何ら
問題はない気がする。

Javaであっても、SunやIBMに振り回されるのはかわらんだろう。まあ
程度問題ではあるけれども。

504:デフォルトの名無しさん
05/09/02 02:54:19
なんとなくLight Weight Javaという本を買ってﾁｮｺﾁｮｺいじり始めたんですが、あんまり理解できておりません。
サンプルを見ながら作ってまず思ったのは「セッション管理はどうすんの？」
で、次に思ったのは「jspに直でアクセスされたらどうすんの？｣なんですが、
ここらへんはどう解決するのがスタンダードなんでしょうか。
買った本のサンプルでは直でURL叩いたらフツーに表示されて鬱になりました。
層が違うとかJSFと関係ねーとかボロクソ言われそうな確信に近い予感がするんですが、
スレ違いだったら容赦くださいませ。
なんか夢のような話がいっぱい書いてあってやってみたくなったんだけど、
オレの能力ではなかなか前途は暗そうです。

つーか、そもそもJavaとかServletの知識も足りん気もします。
Javaの言語的な知識一通り+Servletのお勉強（モア・サーブレットで一通り）+Struts（+hibernate)の業務経験半年。
Webアプリ自体はレガシASPで過去2年ぐらいやってます。

ちなみに、今までのスタンスは、
セッション管理
フレームワークから生のセッションをｹﾞｯﾄしてｺﾁｮｺﾁｮチェックしてどうこうする。
jsp直アクセス
(ﾟ⊿ﾟ)ｼﾗﾈ。既存のがなんにも対策してないから俺もやらね。
でした。

505:デフォルトの名無しさん
05/09/02 06:59:29
＞セッション管理はどうすんの？
普通にManagedBeanのスコープをsessionにすればいいだけじゃないのか？
何を問題にしているのかさっぱりわからん。

＞「jspに直でアクセスされたらどうすんの？
WEB-INFの下にでも置いておけ。JSFだからという問題ではないだろ。

506:デフォルトの名無しさん
05/09/02 12:51:26
>>504
あなたが純粋なアプリ屋で、アプリ基盤とか共通チームとか言われるチームから
サポートを受けられる立場なら、細かいところは任せちゃった方がいいです。
逆に、自分でそこまで見なきゃ行けない立場なら、まずはServletレベルから
ちゃんと勉強した方がいいです。

507:デフォルトの名無しさん
05/09/02 19:41:20
>>470
Oかもと氏はContributerであって、Comitterではない。

いやあ、いつのまにコミッタに！？と一瞬あせったぞ。

508:デフォルトの名無しさん
05/09/02 19:42:35
あ・・・Committerね。タイポスマソ。

509:デフォルトの名無しさん
05/09/02 20:36:48
>>504
直接的なセッション管理についてはあまり気にすることはない、という感じかしら。
JSFはそういう汚いものをなるべく隠すようにデザインされてるから。
HttpSession#setAttribute()で明示的にオブジェクトを保存するかわりに、
SessionスコープのManagedBeanを使うのがJSFのやりかた。

JSFServlet通さずにJSFなjspに直接アクセスされたら、単に500になるだけでしょ。

510:504
05/09/03 00:41:37
やっぱり私は的外れな事をのたまっていたようで。
私がセッション管理と呼んでいたのはいわゆるログイン認証が必要な
サイトでのログイン状態の管理のことでした。
ログイン時に入力情報をセッションに格納し、その後リクエストごとに
セッションの情報を使って認証し、正当なものにのみリクエストされたページを
表示し、ダメならログインページにリダイレクト、
という処理をどう実装すべきなのかがぜんぜん思いつきません。

パッと思いついたのがFilterでHttpSessionを触ることなんですけど、どうなんでしょうか。
もはやJSFぜんぜん関係ないかもですが、ご指導お願いいたします。

511:デフォルトの名無しさん
05/09/03 09:59:06
>>510
ログインページからsessionスコープのManagedBeanを呼び、そこにログイン状態を保持
ログインチェックはFilterで行い、Sessionからログインで使ったManagedBeanをチェックする。
ただし、ログインページから飛ぶときだけはチェックの対象外とする。

でいけるんじゃないの？
ただ、Strutsのときはログイン時のsubmit先のURLがすぐわかったけど、JSFではどうなるんだっけ？

512:デフォルトの名無しさん
05/09/03 10:11:33
＞ただ、Strutsのときはログイン時のsubmit先のURLがすぐわかったけど、JSFではどうなるんだっけ？
JSFを使ったフォームの場合は、送信先URLは自ページだよ。
送信元はわかるから、送信元がログインページかどうかを判断すればいいんじゃね？

513:デフォルトの名無しさん
05/09/03 10:37:56
>>510
JSFではExternalContext経由で比較的低レベルの機能にアクセスできるよ。
もちろんSessionも触れるしRedirectもできる。

「リクエスト受信時に何かしたい」ような場合、まあServletFilterでも
いいんだけど、JSF的にはPhaseListenerを使うという選択肢もあるんじゃない
のかな。

514:デフォルトの名無しさん
05/09/03 12:00:34
で、いつになったら具体的なサンプルコードなど出てきますか？

テーブル定義はこうして、こういった画面つくって、こういった設定、コードを書けば、
ログイン認証ができるよという明確なサンプル的なものが欲しいのですが？

それとも現時点ではJSFでは処理が複雑なのでしょうか？
それとも、ここの技術者レベルが低いのでしょうか？

515:デフォルトの名無しさん
05/09/03 13:48:16
>>514
一冊、本買ってこいよ。

516:デフォルトの名無しさん
05/09/03 13:59:47
>>515
JSFをメインに書いているような本は２，３冊買いました。
雑誌などで特集してるものも含めると10冊以上買いました。

しかし、雑誌などではコンポーネントとかの使い方などに注力しています。
また、ログイン画面などのサンプル的なものは存在しましたが、
やっていたのは、ログイン後にプログラムの中で固定でユーザ名とパスワードを
ifで判別してエラーメッセージを出して終わりとかその程度です。

実際に仕事で使えるレベルのサンプルが欲しいのですが、
書籍を書いている人も技術レベルが低かったり実務やってないのでしょうか？

517:デフォルトの名無しさん
05/09/03 14:47:50
そのif文を適当に変えりゃいいだけじゃないか。

518:デフォルトの名無しさん
05/09/03 14:51:49
>>514
あなたの技術レベルというか知能レベルが低すぎるのです。

519:デフォルトの名無しさん
05/09/03 14:54:56
>>514,516
突然逆切れか。しかも仕事か（苦笑）
お前、それでよく給料貰ってるな……。

520:デフォルトの名無しさん
05/09/03 15:06:31
要約すると
・本をたくさん読んだけどわからなかった
・本のレベルが低すぎるに違いない
・JSFが難しすぎるに違いない
・決して自分がバカなのではない

こいつの何がバカかって、514、516の最後の1行さえ書かなければ、それなりの意見がでてたかもしれないってところだ。

521:デフォルトの名無しさん
05/09/03 15:31:48
>>517
そのif文を書き換えるだけで良いという考えが、技術力の低さ・業務での開発が分かってない、
典型的な例だと思います。

>>519
JSFでまだ仕事はしてません。
Strutsでの開発をしていますが、今後を考えての勉強です。

>>520
＞・本をたくさん読んだけどわからなかった
＞・本のレベルが低すぎるに違いない
これは、その通りでは？
単純に、その本が何をターゲットにしてるかが違うだけという事もありますが、
あまりにも仕事レベルで使えるものが少ない。

＞・JSFが難しすぎるに違いない
これは、勉強中なので何とも言えません。

＞・決して自分がバカなのではない
馬鹿では無いと思います。

＞こいつの何がバカかって、514、516の最後の1行さえ書かなければ、それなりの意見がでてたかもしれないってところだ。
ただの言い訳ですね。
これを言うからには、それなりの意見をだして納得させた上で、”馬鹿”だの言ってもらいたい。
意見が出なければ、技術レベルの低い人間しか居ない。
意見が出れば、素直に自分が馬鹿と認め、謝罪でもなんでもしますよ。

522:デフォルトの名無しさん
05/09/03 16:19:21
いつになったらコードが出てくるのか？
という発想をする職業エンジニアがいることに驚いた。
自分で応用ができないレベルでしかないのに
本のレベルが低すぎるなんてよく言い切れるものだ。

523:デフォルトの名無しさん
05/09/03 16:25:08
他人に具体的なコードをもらうまで自分でなんとかできる技術力が521に無いことは確かなようだ。

524:504
05/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:デフォルトの名無しさん
05/09/03 16:54:21
＞そういう名前でセッションにぶら下がってる保証があるのかどうかわからんくて困っております。
現在のバージョン(1.1)とその次のバージョン(1.2)ではJSF仕様で保証されている。
将来のバージョンではわからないけどね。

526:デフォルトの名無しさん
05/09/03 16:59:26
>>524
どのみち、今のところ、それしかManagedBeanを参照する綺麗な方法が無いと
思う。あきらめれ。

527:デフォルトの名無しさん
05/09/04 01:37:56
>>521
> そのif文を書き換えるだけで良いという考えが、技術力の低さ・業務での開発が分かってない、
> 典型的な例だと思います。

そうだねぇ。
キミの技術力の低さや、そんな技術力で業務での開発をやらないといけない事情を分かってないとは言える。

528:デフォルトの名無しさん
05/09/04 04:45:21
なんつうか認証だったら単純にJAAS使うのがいいんでない？

529:デフォルトの名無しさん
05/09/04 06:40:35
つうか、Tomcatの認証機能使えばいいと思う。

530:デフォルトの名無しさん
05/09/04 09:15:38
>>529
それはJAAS実装でなくて？
それとも、俺様の知らない、Tomcat独自の秘密の認証機能があるのか？

531:デフォルトの名無しさん
05/09/04 13:59:41
確かTomcatのはJAAS「互換」だけどJAAS実装じゃないとかよく分からんがそんな感じだった。
仕様を満たしてない部分があるとかかも。
どっちにしろJDBCやらLDAPのRealm作れば普通のWebアプリの認証は実現できるっしょ。
Tomcatだったら JdbcRealmは実装提供されてなかったっけ？

532:デフォルトの名無しさん
05/09/04 14:04:28
>>531
TomcatにもJDBC Realmあるよ。

533:デフォルトの名無しさん
05/09/04 18:52:18
アプリの配置された実ディレクトリのパスを取得したいんですけど、
JSFのELで取得するには、どのオブジェクトのなんという属性を
参照すればいいんでしょうか？

どういう暗黙オブジェクトがあるかというドキュメントは見ますが、
それぞれどういう情報を持っているかという資料は見つけられません。
どこかにいい資料はないものでしょうか？
#もしかして、中身については何も規定がなく、実装に依存する？

534:デフォルトの名無しさん
05/09/04 20:16:07
JSFとか意味わかってないんじゃね？

> どこかにいい資料はないものでしょうか？
URLﾘﾝｸ(www.ingrid.org)

535:デフォルトの名無しさん
05/09/04 20:33:04
JSFのEL

536:533
05/09/04 20:35:58
いや、ServletAPIじゃなくてJSFのELで取得する方法を探しています。

というのも、BackingBeanはあくまでもPOJOのままにしておきたい
(=FacesContextなどは参照しない)→とするとfaces-config.xml内で
<managed-property>で外部から値を設定してやる必要がある→
ここに記述できるのはELだから、なんとかしてELで実ディレクトリを
求められないか？という流れです。
他にうまいこと外部から値を注入してやる方法があれば、それでも
いいんですが。

537:デフォルトの名無しさん
05/09/04 20:40:26
うーんムズイねそれは

何をしたいのか処理の順番が分からないから答えにならないかもしれないけど
普通にサーバ側のページ初期化アクションでbean.setPath()とかやるのはダメなの？＿

538:デフォルトの名無しさん
05/09/04 20:52:15
533は大人だ。

539:デフォルトの名無しさん
05/09/04 21:01:16
実ディレクトリは動的に求めないとダメ？
<managed-property>の<value>に直接書くのは無しかな？
faces-config.xml にも環境依存の情報は書きたくない？

話しは少しずれるんだけど、
＞BackingBeanはあくまでもPOJOのままにしておきたい
これ、実は結構難しくない？俺もテストファーストでBeanを作ろうと
思ったんだけど、出力メッセージをFacesContextに入れるところや
UIComponentのComponent Bindingで断念した。orz

540:デフォルトの名無しさん
05/09/04 21:06:59
＞BackingBeanはあくまでもPOJOのままにしておきたい
これ、実は結構難しくない？俺もテストファーストでBeanを作ろうと
思ったんだけど、出力メッセージをFacesContextに入れるところや
UIComponentのComponent Bindingで断念した。orz

分かる、非常に同感
なんかさ、くちゃくちゃになるんだよねいろんなとこでいろんなことしたりしちゃって・・・
結局　static FacesContext.getCurrentContext()だっけ？
こいつが悪であり、しかしこいつがある理由が分かるような気がしないでもない

541:デフォルトの名無しさん
05/09/04 21:22:22
FacesContext#getCurrentInstance() ね。
JSFだとBeanがPOJOで作れてテストがカンタン！なんて幻想だったよ・・・orz

542:デフォルトの名無しさん
05/09/04 21:26:47
あまり不満ばっか並べてもJSFがかわいそうなので利点を挙げると
コンバータ・バリデータ・アクションって分けて開発できることかなぁ
初心者にはコンバータ・バリデータ書かせておけばよいし

543:533
05/09/04 21:40:02
なるほど、参考になります。
JSFは始めたばかりなんで、原則通りやってみようと考えて
いるんですが、現実には理想通りにいかない部分もあるん
ですね。

その後調べてみて、やはりELで直接取得するのは難しい
ようなので、代替案を考えました。
1. applicationスコープのbeanをひとつだけ用意し、この
　生成時に実ディレクトリを取得しプロパティに保持
　(これだけコンテナ依存)
2. その他のbean(sessionスコープ)は<managed-property>で
　上記beanのプロパティ値をセット
試したところうまく動くようですので、これでいってみようと思います。

開発環境と運用環境が違うので、faces-config.xmlに環境
依存情報を記述するのは避けたいですね。それよりはまだ
コンテナ依存の方が許容できます。

544:デフォルトの名無しさん
05/09/04 21:47:06
>>533
そのパスって動的に変わる値だと思ってたけど固定なのね；；
ならば、web.xmlに環境変数として希望するパスの情報書くのはダメなのかな
<resource-env-ref> とか<env-entry>とか

545:デフォルトの名無しさん
05/09/05 02:19:29
しかし、いまだに
URLﾘﾝｸ(www.ingrid.org)
が引用されるのがさびしい限りだ。

546:デフォルトの名無しさん
05/09/05 14:03:49
>>524
遅レスだけどJSFにこだわらないでこれでいいと思うけど...

>だったらManaged Beanに頼る意味あるのかなあ。どうせServletFilterで生のセッション触るなら
>ログイン情報もログイン時にHttpSessionに直に書いてもいいんじゃないだろうか、とか。

あとはServletFilterのInitParameterで認証失敗時の遷移先URIやチェック除外対象のURIのリスト
とかを設定できるようにすればいいんじゃないの？

547:504
05/09/06 00:59:21
規制されて書けないうちにどんどん話が進んでゆく。。

>525
仕様で決まっていたんですか。知らなかったです。不勉強でした。
そういうことだったらログイン時のManagedBeanをServletFilterでチェックする
というやり方で問題なく対処できそうです。
ありがとうございます。

Tomcatの認証はLDAP使ってやったことはあります。
その時も理屈が理解できてないのに機能だけ使うのに抵抗を感じ、
アプリケーション内で実装しようと目論んだわけですが。
なんせJAASという単語も今知ったくらいなので、これからお勉強して手の内
に入れたらそういう便利なしくみを使うのもよいかなーと思います。
でも、頭が悪いのか、チュートリアル読んでもｲﾏｲﾁ理解できませんが。
精進します。

>546
ええ。それでもいいわけですよね。むしろ、そうあるべきなのか。
そして、JSFと全然関係ないスレ違いな質問をしていたのだという事実にようやく気付いたりしつつ。

548:デフォルトの名無しさん
05/09/06 17:42:19
JSFって、まだ本読んでもちゃんとアプリ作れないレベルなんですか？
新人達がJSFで社内ツール作らされてちゃんと作ってたみたいだけど、
どうやってたんだろう？
イントラだからセキュリティは若干甘いかもしれないけど

549:デフォルトの名無しさん
05/09/06 19:42:49
>>548
そんなこたあ無いでしょ
別に（ふつうの）Servletや非JSFページとも併用できるんだし

550:463
05/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
05/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製品はすぐにバージョンアップしてという意見もあったけど、どうせ２、３年とか
長くても5年ぐらいでシステム入れ替える癖に無駄な意見だよな・・・

552:名無しさん＠そうだ選挙に行こう
05/09/10 19:30:26
ハードウェアとアプリケーションの寿命は違うがな。

553:名無しさん＠そうだ選挙に行こう
05/09/11 02:06:07
>> .NETFramework自体は無料。
このへんからトラップのにおひがするぉ

554:名無しさん＠そうだ選挙に行こう
05/09/11 07:38:48
>>553
いや、フレームワーク自体は無料だろ。
有料なのは開発環境な訳だし。
.NETFrameworkSDKは無料でダウンロードできるし、
メモ帳とかでソースコード書いてコマンドラインでコンパイルすれば、そのまま配布もできるし。

555:名無しさん＠そうだ選挙に行こう
05/09/11 08:48:43
.NETがいいと思うなら.NET使えばいいじゃん。
ここはJavaのほうが総合的に良いと思って使っている人たちのスレ。

556:名無しさん＠そうだ選挙に行こう
05/09/11 12:06:15
今時メモ帳でソース書く人とかいるのか？

557:名無しさん＠そうだ選挙に行こう
05/09/11 12:17:42
別にメモ帳の部分にこだわる必要はないんじゃない？
EclipseでだってC#とか書けるし、WebだけでいえばWebMatrixとかもあるし。

558:名無しさん＠そうだ選挙に行こう
05/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:名無しさん＠そうだ選挙に行こう
05/09/11 13:47:59
おれがSunのJSF実装で試したときは
値が未入力の場合、Validatorにそもそも渡らなかった気がするんだが、気のせい？

560:名無しさん＠そうだ選挙に行こう
05/09/11 14:12:05
>>559
SUN実装は使ったことないから分からない。
とりあえず、MyFacesでは問題無かった。

それと、余談になるんだが、お前様方の周辺でJSFってどんなかんじ？
俺の場合、会社だと新規のJava案件は殆どWebSphereを使うから、JSF使ってるから、
結構流行ってると言えば、流行ってるんだけど、他ではどうかとちょっと気になった。

561:463
05/09/11 14:36:10
>>558
なるほど、独自にチェックするしかないのね。
確かに出来そうだと思ったが、

>>559が書いてるようにMyFacesでも値が未入力だとValidatorに行かないな。
>>558=>>560も低レベル技術者のようで・・・

つうか、この辺はStrutsの方がマシだな。
登場してからの歴史が長いってのもあるんだろうな。
でも、JSFはやっぱいUIだけって感じなんだろうな。
だからStrutsとJSFが連携できるようになってるんだろうな。

Strutsを補う意味でJSFを使うのかと思ってたけど、
本当はJSFの貧弱さを隠すためだったんだな。

この辺を見ると、.NETFrameworkって素晴らしいと本当に実感したよ。

562:名無しさん＠そうだ選挙に行こう
05/09/11 14:51:29
このスレとしてはJSF＞＞＞＞＞(超えられない壁)＞＞＞ASP.NETであってほしいが、そうもいかないって事か。
とりあえず、「h:output_text」とか書いてある古いJSFの資料は捨てちゃっても構わないよね？

563:463
05/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とかオープンソースって聞くと、例えバージョンが古くなったりしても、
ソースコードとかがあるからどうにでもなるってのも１つのメリットとしてよくあがるけど、
資料捨てて、数年後とか失敗したと思わなければいいんだけど。
俺の会社のJava開発チームは、前世紀からのJava資料を全部保管してるよ。
つうか、この資料だけで、会社の倉庫の半分使ってるんだけど・・・・

まぁ、あまりJSFやStrutsのスレが盛り上がってない事から見ても、きっと下火なんだろうね。

それと、最近、やけにJavaの技術者いませんか？との問い合わせが会社に多い。
聞くと、殆ど新規案件じゃなくて仕様変更なり拡張。
『今までの開発先は？』と聞くと『Java案件はもうやってない』とかで俺の会社とかに問い合わせがくるけど、
実際問題どうなの？
俺の会社やオフシェア先の中国でも、最近はASP.NETとかに以降してるから、
Java技術者って、実はこの先、仕事ないんじゃ？

564:名無しさん＠そうだ選挙に行こう
05/09/11 16:41:41
（L）AMPのような手軽さもなければ、.NETほど生産性が高いわけでもない。
今はまだ数で圧倒的ではあるけど、難しい局面になってることは確かだな。

565:名無しさん＠そうだ選挙に行こう
05/09/11 17:46:49
>>563
中国は国家主導でLinuxの導入進めてる。
個人レベルではWindowsのシェアが高いけど、企業レベルでは殆どがLinux環境。

566:名無しさん＠そうだ選挙に行こう
05/09/11 18:20:02
>>565
別に国家レベルでLinux導入進めていたって、その中国の人間の客は日本なんだから、
日本向けに技術者を教育なり集めるのが普通だろ。

中国とかは関係無いよ。
あくまで客である日本企業の需要に合わせる。

俺らだって、客先が有無を言わさず『Linuxで！！』と言われればLinux使うし、
『Linuxは絶対に駄目。Windowsサーバで！！』と言われればそれに従うだけだし。

567:名無しさん＠そうだ選挙に行こう
05/09/11 18:42:37
JSFについて、日々意見が交換されているフォーラム等ってない？
「JSF フォーラム」で検索すると「日本宇宙フォーラム」や「ヤパーナ社会フォーラムもう一つの世界は可能だ」
とか、変なものがヒットするんだが。

568:名無しさん＠そうだ選挙に行こう
05/09/11 19:11:44
>>567
だから、流行ってないんだって。

むしろ、Seasar2のS2JSFのメーリングリストとかの方が活発に意見交換されている。
だけど、あそこはあくまでもS2JSFの話題だからなぁ。

基本的にはJSFを使用するのは時期尚早って感じなんじゃない？
だから、このスレとかでもあまり意見交換って行われてないじゃん。

JSFが気になった奴もちょっと使ってみて、『つかえねぇ』と感じて、
結局今まで通りって流れのような気がする・・・俺のように・・・

569:名無しさん＠そうだ選挙に行こう
05/09/11 19:25:51
>>567
適当に探してみた

jsf-jp　JavaServer Facesに関するMLです。
URLﾘﾝｸ(groups.yahoo.co.jp)

@ITのJava Solution 会議室
URLﾘﾝｸ(www.atmarkit.co.jp)

570:名無しさん＠そうだ選挙に行こう
05/09/11 20:19:47
一応、２つのプロジェクトでJSF（IBM実装で）使ったりしてはいるが
どうもここ見る限りでは浸透していない様子だなぁ・・・
あぼんの予感がする

571:名無しさん＠そうだ選挙に行こう
05/09/11 20:23:43
まだこれからでしょ。今は時期尚早という見方も多い。
実装による質のばらつきもまだまだ多いし。
初期のServletコンテナもベンダーによる質のばらつきが多かったのに似ている希ガス。
各ベンダーやオープンソースによる実装が安定して、さらに
オープンソースの高機能なJSF開発環境やEclipseプラグインが
出てくると一気に普及すると思うけどな・・・。

572:デフォルトの名無しさん
05/09/12 01:51:49
フレームワークのプログラミングモデルがたぶん大幅に変わらないから、
代わっても1.2見るだけでも局所的及び一部分だ。だとすると覚えるのは
モデルだけで後は、どうやって利用するかどこに利用できるかってことに
今は知恵を使ったほうがいいよ。現状のレベルだといきなりASP置き換えはﾑﾘ
それだとどこまでのレベルで使えるのか判断したほうがいいよ
Webspherは全部のプロジェクトでつかえるものではないしな

573:デフォルトの名無しさん
05/09/12 22:47:10
どっちかというとStrutsの置き換えみたいな考え方で、1.2以降ボチボチと使われ始めるんじゃないだろうか？
ASP.NETの対抗馬としてサンは開発環境込みで広めたかったんだろうが、
Eclipseで開発できない限りJavaの世界じゃ広まらないからな

574:デフォルトの名無しさん
05/09/13 01:57:34
IBMかHPの実装がでないと意味が無い。SUNは弱体化してもう虫の息だ。
こんなところが実装するソフトウェア基盤はゴミでしかない。M$の金魚の糞は
つぶれたほうがいいよ

575:デフォルトの名無しさん
05/09/14 04:26:15
>>573
＞Eclipseで開発できない限りJavaの世界じゃ広まらないからな

Eclipseでの開発の有無より、スレ見てる限りJSFの仕様（実装）が糞だから
みんな使わない（業務で役に立たない）んじゃない？

576:デフォルトの名無しさん
05/09/14 08:02:40
>>575
いや、仕様よりもEclipseだろ

577:デフォルトの名無しさん
05/09/14 08:12:35
そうだな、どんなに素晴らしい仕様でもどうしようもない

578:デフォルトの名無しさん
05/09/14 21:00:29
確かにツールがないとつらいな。
あとは日本語のマニュアルｗ

579:デフォルトの名無しさん
05/09/15 15:04:20
>>534 >>545
Googleだと古い方のページがトップですが、
新オフイシャルサーバを参照する方がよいですよね。
「Servlet および JavaServer Pages API ドキュメント (Tomcat 4.0)」
URLﾘﾝｸ(www.jajakarta.org)

Servlet API 2.3とJavaServer Pages API 1.2なので
JakataのTomcat 4.1のページと同等ですね。

Servlet API Documentation (Tomcat 5.5)
URLﾘﾝｸ(jakarta.apache.org)
JavaServer Pages API Documentation (Tomcat 5.5)
URLﾘﾝｸ(jakarta.apache.org)
Servlet API Documentation (Tomcat 5.0)
URLﾘﾝｸ(jakarta.apache.org)
JavaServer Pages API Documentation (Tomcat 5.0)
URLﾘﾝｸ(jakarta.apache.org)
Servlet and JavaServer Pages API Documentation (Tomcat 4.1)
URLﾘﾝｸ(jakarta.apache.org)

JSFもそうですが、最新バージョンの日本語マニュアル欲しいですね。

580:デフォルトの名無しさん
05/09/16 00:48:26
Servlet + Velocity で十分でしょ。

581:デフォルトの名無しさん
05/09/16 01:34:44
>>580
えらいねぇ。
漏れはもうStrutsなりJSFなりがないとしんどくてだめだよ。

582:デフォルトの名無しさん
05/09/16 01:43:17
>>580
Velocity使うより、ふつうにJSPで充分。
というかVelocityよりはJSPのほうがいい。

583:デフォルトの名無しさん
05/09/16 03:12:55
Velocityはマクロ周辺をもう少し使いやすく・・・
マクロファイル大量に分ければいいか・・・

584:デフォルトの名無しさん
05/09/16 03:14:15
あえてVelocityを使うほどのメリットあるの？
HTML出力以外だと便利だけど。
JSPでよくない？

585:デフォルトの名無しさん
05/09/16 13:35:11
て言うか、Maya最強！

586:デフォルトの名無しさん
05/09/16 13:56:31
>>584
デザイナからするとJSPよりVelocityのほうが扱いやすいらしいよ

587:デフォルトの名無しさん
05/09/16 14:11:06
>>585
いろいろ毎日忙しくて
まだ検証にも踏み切ってないんだけど
実務に使えそう？

588:デフォルトの名無しさん
05/09/16 14:22:56
>>586
#ifとかがプレビューで見えたほうがいいってこと？

589:デフォルトの名無しさん
05/09/16 15:29:18
>>587
パフォーマンス的な事を言ってるなら、Velocityを使えると考えるなら
それと同じくらいには使える。

CSSを用いればHTMLからレイアウトと装飾を分離できる。
ってのは最近では当たり前に知られてる利点だけど、それと同じ感
覚でWEBアプリ依存部分を分離できる。

これを逆に(Seasar的に)見ると、MayaファイルでHTMLに対してWEB
アプリへの依存性を注入してる(所謂DI)とも言える。
あと、XPathを利用した複数箇所に現れる同一タグへの処理はAOP
的。こういった辺りが概念的に気持ちイイ！

590:デフォルトの名無しさん
05/09/16 16:31:57
>>589
そういうのわかりやすくまとめてある資料ってありますか？

591:デフォルトの名無しさん
05/09/16 17:10:21
>>590
URLﾘﾝｸ(maya.sandbox.seasar.org)
ここ読んであとはサンプル弄ってみるくらいかな？
hoge.htmlとhoge.mayaが組になってる事さえ意識できれば
変更、結果表示の繰り返しで触れるようになると思うよ。

592:デフォルトの名無しさん
05/09/16 19:12:21
いまのとこ使う気はないけど、どんなものか試してみたいっていうにはちょっと壁が高いな。

593:デフォルトの名無しさん
05/09/16 20:58:15
Seasarって俺はどうも好きになれないんだよね。

メーリングリスト（参照だけならWebで見れる）でも、開発者自ら『MyFacesの糞実装』と
表現は違えど、名言しているにもかかわらず、S2JSFでは思いっきりMyFacesを使ってるし。

個人的には糞実装の上に、どんなに良いものを乗っけても、土台が糞な以上、
S2JSFも糞なんだよな・・・

つうかJSF自体オープンソースになったんだから、独自に実装すればいいんだよ。

594:デフォルトの名無しさん
05/09/17 01:02:45
JSP+ELが最強ってことだな？

595:デフォルトの名無しさん
05/09/17 01:11:48
>>594
JSP+EL+JSFでおけ

596:デフォルトの名無しさん
05/09/17 01:45:34
まさたかさんはとりあえず
URLﾘﾝｸ(www.theserverside.com)
を読んでおいてもらいたい。

597:デフォルトの名無しさん
05/09/17 03:09:57
>>593
S2JSFのどの辺が糞ですか？
個人的には、S2JSFはMyFacesの糞実装をうまく隠蔽する仕組みにしたつもりですが

598:デフォルトの名無しさん
05/09/17 11:10:08
Seasarを避難すると個人掲示板だろうがどこでも現れてくるよね
中の人

599:デフォルトの名無しさん
05/09/17 11:31:24
まぁ、確かに糞実装と言っておいて、その糞実装を核として使ってるんだから、
いくら上から隠蔽しても糞だよな。

家でいえば、土台の基礎工事がちゃんと出来ていないのに、豪華な家を建ててるようなもの。
崩れるときは土台から崩れるし、土台を修正しようとすると、可也の時間が掛かる。
隠蔽する前に土台をしっかりとさせる方が重要だよな。

オープンソースなんだから、土台を自分たちで実装するなり改造するなり手は幾らでもある。

その結果が今のS2JSFなんじゃない？
確か、1.0.5に核のMyFaces1.0.9関連で不具合出て、対策わかったから昨日には1.0.6を出すと言っていたのに、
まだ出てないよね。
これが、結局は核の部分に問題があるのを上から無理やり隠蔽しようとするから時間掛かってるんじゃない？

それと、ビューの部分をHTMLで書いて簡単に確認できるって考え方は悪くないんだけど、
俺らがJSFで開発するのに本当に欲しいものはVisualStudioのように
画面にコントロールを貼り付けていって・・・という作業がしたいんだよね。

IBMとかの使えばできるけど、WebSphereに依存しちまうし、なにより値段が高い。
あれを買う金があるなら、素直にVisualStudio買ってASP.NETで作っちまうよ。
無料のWebMatrixでさえ、画面にコントロール貼り付けられるし、
次のVisualStudioだってWeb開発しかしないなら、1万ちょっとで開発環境が手に入る訳だし。

あとは拡張コンポーネント次第だよな。
MyFacesの拡張コンポーネントは糞だし、S2JSFでのコンポーネントもそれ程実用性は無い。
既存のものをちょっと使いやすくした程度。

600:デフォルトの名無しさん
05/09/17 11:34:04
>>599
Sunの実装は？
ぽとぺたできて1万くらいだったような

601:デフォルトの名無しさん
05/09/17 11:37:57
>>599

> ビューの部分をHTMLで書いて簡単に確認できる

え？カスタムタグ使ってる系ってこれが出来ないから
デザイナーとのやりとりや変更が多いタイプの仕事では
テンプレート系がもてはやされてるんじゃないの？

602:デフォルトの名無しさん
05/09/17 11:41:24
>>600
Sunの実装って、色々なJSF使えるの？

jsf-1_1_01、MyFacesとかとかIBMのとかOracleのとか。

俺が言いたいのは、開発するのに貼り付けられるってのは重要だけど、
何を使うかは自由でいたいの。

仕様としてちゃんと決められてるんだから、その仕様に基づいて実装させていれば、
この部分は自由に出来るはずだよね。（できないなら開発ツールが糞か実装が糞か仕様がそもそも糞）

603:デフォルトの名無しさん
05/09/17 11:45:47
あともう1つは、開発環境、もう少し軽くならないもんかなぁ・・・

Javaで作られてる開発環境重過ぎる。
IBMのなんて、CPU3.5G、メモリ2GBでも余裕で重いし落ちるしな。

.NETFrameworkで作られた開発環境は、CPU800MHz、メモリ512でも
Javaの開発環境と比較して、比べ物にならないほどスムーズだしな。

ある程度のマシンスペックが要求されるのは、我慢できるが、
ハイスペックのマシンで、やっと動いてますってのは我慢できない。

604:デフォルトの名無しさん
05/09/17 11:50:26
>>601
MSの世界ではUIはVBプログラマの仕事みたいよ。
レイアウト、デザイン、ロジックで分離とか言っても、そもそも
そういう視点を持ってないMS側の人には分からんだろう。
一人で全部作るには確かに楽ではあるしね＞ASP.NET

605:デフォルトの名無しさん
05/09/17 11:52:17
>>604
JSF（JSP）だって、UIはJavaプログラマの仕事じゃん。
レイアウト、デザイン、ロジックで分離とか言っても、そもそも
そういう視点を持ってないJava信者の人には分からんだろう。
一人で全部作るには可也の苦労があるしね＞JSF

次ページ