1001コメント384KB

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

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

NGNG

スレがないので新しくたてました
http://www.atmarkit.co.jp/fjava/special/jsf01/jsf01.html
http://java.sun.com/webservices/downloads/webservicespack.html

0415デフォルトの名無しさん

2005/07/23(土) 12:47:53

>>414
いや、その一人の作業負荷が高くなりそう
半分ぐらい知っている場合
「知らない奴は勉強すれ」

一人しか知らない場合
「操作手順書書いといて」

わかりきった事実やるせない事実

0416デフォルトの名無しさん

2005/07/23(土) 13:23:15

EclipseにJSFのプロジェクトあったんだね。
VisualEditor関連の機能が気になるんだけど、いつ頃モノはできるんだろう？

http://www.eclipse.org/proposals/eclipse-jsf/index.html

# Graphical/Visual Editor for JSF Pages

1. Visual editing of JSF components
2. Support drag and drop, wizards for standard and core JSF tags
3. Support for backing beans

# Graphical/Visual Editor for faces-config.xml (Page-flow Editor)

1. Create and remove pages (Navigation Cases) from the diagram
2. Rename navigation rule outcomes and actions and navigation cases on the diagram
3. Automatically diagram navigation data from any JSF configuration file

# JSF Preview

1. The JSF Editors will have a preview capability

0417デフォルトの名無しさん

2005/07/23(土) 13:29:10

>>416
その「will」がいつになるのか書かれていないのでかなり先の予感

0418デフォルトの名無しさん

2005/07/23(土) 13:34:19

現行のVEみたいに中途半端で終わりそうな気もする

0419デフォルトの名無しさん

2005/07/23(土) 13:44:41

とりあえずOracleとIBMとの間で打ち合わせが行われた模様。
まあIBMの連中にしてみれば「全部俺らにやらせろや」とか
思ってんだろうな。

0420デフォルトの名無しさん

2005/07/23(土) 14:02:35

>>413
フレームワークってそういうもの。
導入初期には覚えるためのコストがかかることを忘れてはいけない。
わかっているプロジェクトでは学習のための期間や書籍購入、セミナー参加等を計上するが
ダメプロジェクトではフレームワークの効率性のみを期待してあぼーん。

0421デフォルトの名無しさん

2005/07/24(日) 05:09:20

あ

0422デフォルトの名無しさん

2005/07/24(日) 05:22:23

ぼ

0423デフォルトの名無しさん

2005/07/24(日) 13:40:55

>>404
セッション切れ判定はHttpSessionListenerじゃやりにくい。
無効化されたの伝えようにもセッションが切れちゃってるから。
切れたセッションIDを記録する方法もあるだろうけど。

セッション切れ画面を出したい場合は、
RESTORE_VIEWなPhaseListener#afterPhase()で、

HttpSession#isNew() -> true
HttpServletRequest#isRequestedSessionIdValid() -> false
HttpServletRequest#getRequestedSessionId() -> != null (不要かも)

この条件が成立するリクエストはセッション切れと扱える。

で、これを捉えたら、FacesContext#setViewRoot()に
ViewHandler#createView()で作ったビューをセットして
FacesContext#renderResponse()を呼べば、
セッション切れ画面に切り替えることができる。

ただし、ログアウト画面に再ログインのリンクがあったりすると、
そこからログインした時にセッション切れ扱いされちゃうかも。

一月近く経ってるからさすがにもう見てないだろうなー。。

0424デフォルトの名無しさん

2005/07/27(水) 00:22:43

>>416 夕べ、Oracle, IBM, BEAの間で打ち合わせがあって、リリースは
WTP1.5にあわせて2006Q3にしようっていうIBMの意見がとりあえず通ったみたいだ。
WTPがJ2EE5.0対応になるタイミングだしね。

あと、>>349- から話題になってるExadel Inc.が仲間に入れてくれって
表明した。まあ現時点でWTPに寄生したJSF製品売ってるExadelStudioに
してみりゃ死活問題だろうしなあ。

0425デフォルトの名無しさん

2005/07/28(木) 12:01:54

<h:inputText id="age" required="true"/>
<h:message for="age"/>

入力チェックで引っかかった場合、
リソースの{0}の部分にid(age)が入るみたいなんだけど
ここを別の文字に変更したい場合はどうすればいいの？

0426425

2005/07/28(木) 12:11:28

MyFacesのサンプルにあったわ。

0427デフォルトの名無しさん

2005/07/28(木) 13:00:53

>>426
本当に！！
MyFacesを使ってないわっしにぜひ教えてはくれないでしょうか。

0428デフォルトの名無しさん

2005/08/02(火) 00:53:59

>>424さんどうもすんません
その解決方法は、とりあえずセッションスコープのビーンを作成してそこでＩＤをもたせて
それがnullになった瞬間セッション切れているって判別することで解決しました。
ライフサイクルの中でＪＳＦはListnerで何らかの処理が走るのでその中に継承して埋め込む
形で埋葬し解決しました。どうもです。
　ところでまたまたしょうもない質問ですが、多重送信を防止する場合どのような解決方法で
回避しているのが教えてください。
　ID+アクション名というユニークな値を作ってある瞬間アクセスされたとき、過去に時間を記録していない
もしくは、現在の時間と過去の時間の差分が閾値を超えた場合、送信内容を受け付ける。それ以外は
しばらくお待ちくださいページに飛ぶって方法で逃げようと思っています。
　これだとダメでしょうか？

0429デフォルトの名無しさん

2005/08/02(火) 01:06:37

>>428
俺はStrutsのTransactionTokenの仕組みに、前画面情報を付加してアレンジした仕組みを使ってる。

0430デフォルトの名無しさん

2005/08/03(水) 01:04:54

>>429
ありがと、同期メソッドにユニークな値作らせるだけでいいのか。
たいした話じゃなくてよかったよ。どうもね

0431デフォルトの名無しさん

2005/08/04(木) 00:33:44

例えば、ログインフォームで
タブでログインボタンや、ユーザIDの入力フィールドにフォーカスを合わせた状態にします。
そこで、リターンキーを連打し、ごく僅かな時間に複数のリクエストを送信します。そうるすると、
com.sun.faces.lifecycle.InvokeApplicationPhase　execute
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:507)
at java.util.ArrayList.remove(ArrayList.java:392)at
javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:271)at
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:381)at
com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:75)at
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)at
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:90)以下省略
というふうにエラーが出ます。しかし、これがどこから発生していたどこでキャッチできるのか
解りません。変数にアクセスする前であればHTTP500も発生しないし問題はあまりないのですが
出ると気持ち悪いので原因改善できる工夫をどのようにすればいいのか教えてください。

0432デフォルトの名無しさん

2005/08/04(木) 00:38:52

>>431
環境を全く書かないのは釣り。

0433デフォルトの名無しさん

2005/08/04(木) 01:44:36

JSFでバイナリデータのダウンロードをしたいのですが、上手くいきません。

ExternalContext context = FacesContext.getCurrentInstance().getExternalContext();
HttpServletResponse response = (HttpServletResponse) context.getResponse();
OutputStream out = response.getOutputStream();
FileInputStream in = new FileInputStream(fileName);
response.setContentLength(size);
response.setHeader("Content-Disposition", "attachment; filename=" + fileName);
int c;
while ((c = in.read()) != -1) {
out.write(c);
}
out.close();
in.close();
FacesContext.getCurrentInstance().responseComplete();

ダウンロード自体は出来ています。
ですが、クライアントにダウンロードの要求確認の画面が表示されるのが、このメソッドが終了した後です。
つまり、
while ((c = in.read()) != -1) {
out.write(c);
}
↑を実行した後、ダウンロードしますか？と聞かれます。
小さいサイズですと、正常にダウンロードしたように見えますが、
少し大きくなると、1分後くらいにダウンロード確認画面が出ます。
さらに大きいサイズになると、途中でjava.lang.OutOfMemoryErrorが起きます。
普通のServletではほぼ同じコードでも問題なく動作しました。
JSFでは、responseを取得する以外に特別な記述が必要なんでしょうか？
ご教授いただければ幸いです。

0434431

2005/08/04(木) 01:49:02

環境といっても
JSF1.1
J2SDK1.4
Tomcat 5.x.xだけでしか試していないのでなんとも言えない。けど

0435デフォルトの名無しさん

2005/08/04(木) 07:09:19

>>431
おまえ、バカだろ？
JSF実装に何を使っているのかが重要なんだよ。
そんな調子じゃ道は遠そうだな。

0436デフォルトの名無しさん

2005/08/04(木) 13:01:33

>>431
二度押し対策なら本屋に逝って「LightWeightJava」を買ってP168を開けて解決するという方法もある。

0437デフォルトの名無しさん

2005/08/04(木) 15:25:33

これでもいい
http://d.hatena.ne.jp/naoya/20050803/1123053496

0438デフォルトの名無しさん

2005/08/06(土) 17:15:48

0439デフォルトの名無しさん

2005/08/07(日) 13:15:01

社内アプリ、クライアントWindows2000/XPという前提で、何か入力画面を作ったとして、
クライアント側でログインしているＮＴのアカウントを取りたいんだけど、できる？

0440デフォルトの名無しさん

2005/08/07(日) 14:13:44

>>439 できる。が、スレ違いの予感。とりあえずNTLM認証とかでぐぐれ。

0441デフォルトの名無しさん

2005/08/08(月) 07:23:45

>>437
これいいね

0442デフォルトの名無しさん

2005/08/08(月) 10:26:27

>>441
うん、裏でああだこうだやるより
ユーザインタフェースって言葉に合ってると思う。

0443デフォルトの名無しさん

2005/08/08(月) 22:36:53

ManagedBeanって画面単位でつくってる？
それともユースケース単位？

0444デフォルトの名無しさん

2005/08/08(月) 23:25:54

気分単位。
うれしいBean
たのしいBean
かなしいBean
むかつくBean

うれしいBeanとたのしいBeanで悩む。

0445デフォルトの名無しさん

2005/08/08(月) 23:29:08

EmotionalBeanか・・・・・・・・・・語感的にはアリな気がしないでもないから不思議だｗ

0446デフォルトの名無しさん

2005/08/15(月) 12:03:33

>>443
IBMのWSADやRationalは画面単位っぽいコードを吐く
結局IDE任せだな俺は

0447デフォルトの名無しさん

2005/08/15(月) 20:46:39

>446

そうするとStrutsで
Actionクラスつくってるのとあんまりかわらなくないですか？
POJOってだけでもメリットあるのかなぁ

0448デフォルトの名無しさん

2005/08/15(月) 22:00:45

>>447
＞ POJOってだけでもメリットあるのかなぁ
そゆこと。

0449デフォルトの名無しさん

2005/08/19(金) 19:38:43

携帯向けサイトにJSF使おうと思って調べてたら
h:formってPOSTしかないのね。
i-mode公式サイト作ってる人ってJSF諦め？

0450デフォルトの名無しさん

2005/08/20(土) 12:46:38

>>449
単純に実装を行っているのがWebブラウザ向けばかりというだけのことです
JSF自体はクライアントは何でもいい

どこかが作ったi-mode用カスタムコンポーネントがなければ
自分で作るしかない

0451449

2005/08/20(土) 13:21:15

>>450
そっか。
JSF的にPOSTで受け取らないと何か動作に問題があるので
POST固定ってなってるもんだと勝手に思ってたよ。
ありがと探してみる。

0452デフォルトの名無しさん

2005/08/20(土) 14:25:11

submitボタン二度押し対策で、
ttp://d.hatena.ne.jp/naoya/20050803/1123053496
の方法はうまく行きませんね。
この方法は、ASP.NETでもダメだったような記憶がある。

「LightWeightJava」の方法はうまく行くけど、
送信中にブラウザの中止ボタンを押すと、それ以降
submitできなくなる。

IE限定なら、document.readyStateが使えるんだけど。

0453デフォルトの名無しさん

2005/08/22(月) 08:48:02

submitボタン押せなくするよりもonsubmitイベントでfalse返すほうが確実っぽい

0454デフォルトの名無しさん

2005/08/24(水) 13:25:22

アクションリスナの存在意義がわかりません。
・処理分岐が不可能
・必ず後でアクションメソッドが呼ばれる
それでもなお、ここはアクションメソッドで実装せず、
アクションリスナを使うべきだ！
という具体例があれば教えてください。

0455デフォルトの名無しさん

2005/08/26(金) 00:27:57

何か勘違いしてる気がするけど、それはそれとして、ヒント：イベントドリブン、EoD

0456デフォルトの名無しさん

2005/08/26(金) 10:28:54

>>455
もっと詳しくお願い。
アクションリスナとアクションメソッドの使い分けが本当にわからん。
リスナメソッドがアクションメソッドより先に呼ばれると言うだけじゃないのか？
リスナメソッドの処理結果を画面上に反映させてユーザに通知することも出来ない。
画面を再描画させる契機はアクションメソッドしかないのだから。
Swingなどのスタンドアロンアプリだったらわかるが、Webアプリでは
どうやって使い分けるんだ？
マジ教えて。

0457デフォルトの名無しさん

2005/08/29(月) 22:23:41

>>455
俺もわからない。ヒントだけじゃなくて、具体的な使い分けを教えて欲しい。

0458デフォルトの名無しさん

2005/08/29(月) 23:20:25

僕もちゃんと理解してるわけではないんでアレなんだけど。

「アクションメソッド」と「アクションリスナ」があるって考えると確かにリスナの方はどうよって気にもなりますが、
基本的にはイベントドリブンなので、アクションを捕まえるのは常にアクションリスナの役割だってのが前提。
だけど、それをいちいち書くのもややこしいから、ラップして使いやすくしたのがアクションメソッド、
ってことなんじゃないでしょうかね？

0459デフォルトの名無しさん

2005/08/29(月) 23:44:09

>>458
ご見解ありがとう。
でもさ・・・
大義名分とか、本来の意味での存在意義はその通りなんだろうけど、
JSFのアクションリスナは、例外を投げて処理を中断することはできるけど
画面の遷移先を変えたりができないってのが何とも中途半端に感じる。
ボタンが押されたら→DB検索→検索結果表示画面へ遷移（またはエラー画面へ遷移）
なんて動きはリスナではできないんだよね・・・・

書籍やWebの情報を見ても「イベントをハンドリングできます」とは書いてあるけど
リスナで実装するべき処理の具体例をなかなか見つけられない・・・

0460デフォルトの名無しさん

2005/08/30(火) 00:02:35

無理して使う必要ないんじゃない？
JSFに依存せずにコントローラを作れるという点からも、普段はアクションメソッドを使っていればいいんじゃないだろうか

0461デフォルトの名無しさん

2005/08/30(火) 02:17:23

AjaxFaces とか既製品使わないでちょっと、簡単なサンプルを
JSF＋AJAXで作りたいのですが、どこかにサンプルはないでしょうか？
いまいましいことにﾄﾞﾄﾈﾄのやつはあるのですがどうにかならないものでしょうか？

0462デフォルトの名無しさん

2005/08/31(水) 19:26:54

>>461
.Netを使う。

0463デフォルトの名無しさん

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って使えねぇ。

0464デフォルトの名無しさん

2005/09/01(木) 20:53:02

>>463
それはJSFが使えねえんじゃなくて、MyFacesが使えないだけだ。
さすがWin/.NET厨。問題の切り分けもできないDQNだな。

0465463

2005/09/01(木) 20:56:56

>>464
JSFの機能 ”だけ” じゃ.NETの足元には及ばない。
そこで、拡張されていてApacheで開発されているMyFacesと比べるのが相応と判断しただけだ。

JSFだけじゃ.NETと比べる価値も無い。

0466463

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と連携させる。
まったくもって無駄なサーバ構成である。

0467デフォルトの名無しさん

2005/09/01(木) 21:29:25

>>465
＞そこで、拡張されていてApacheで開発されているMyFacesと比べるのが相応と判断しただけだ。
その判断がDQNだな。
本業を別に持っている人たちが片手間に作ったモノとなぜ比べる？
せいぜいIBMの実装と比べてから言えよな。
そんな判断もつかないのか。M$厨は。

0468デフォルトの名無しさん

2005/09/01(木) 21:30:52

＞なぜApacheのHTTPServerと
＞ TomcatなどのApplicationServerを連携させてる構成が多いのだろう？
てめえがそう思うのならしなければいいだけの話し。
誰も連携させることを強制なんかしていない。
勝手に思いこむお前が糞。

0469463

2005/09/01(木) 21:43:26

>>467
＞その判断がDQNだな。
＞本業を別に持っている人たちが片手間に作ったモノとなぜ比べる？

これは無知ゆえの発言ですね。
Apacheは非営利目的の団体だけど、開発者は普通の企業に勤めてる人間が多い。
しかし、だからといって本業の片手間と決め付けるのは無知そのもの。
実際は、勤め先の会社から給料を貰いつつ、その会社での”仕事”として
Apacheプロジェクトの開発をする事が認められている。
つまり、本業。

＞せいぜいIBMの実装と比べてから言えよな。
＞そんな判断もつかないのか。M$厨は。

IBMの実装？
それに金払うのか？
ならば、金払わないでもつかえる.NETと比べる土台にすら上がってないよ。

＞てめえがそう思うのならしなければいいだけの話し。
＞誰も連携させることを強制なんかしていない。
＞勝手に思いこむお前が糞。

俺がサーバを立てるなら連携させることは無いだろうな。
だけど、Javaなどをメインに仕事してる会社とかが構築してる場合とかでも
ほぼデフォルトでそういった構成になってる。
正直言って不思議だよ。

ちなみに、思い込みじゃなくて実際に見てみた結果で言ってる。

0470デフォルトの名無しさん

2005/09/01(木) 21:51:35

>>469
Apacheは非営利目的の団体だけど、開発者は普通の企業に勤めてる人間が多い。
しかし、だからといって本業の片手間と決め付けるのは無知そのもの。
実際は、勤め先の会社から給料を貰いつつ、その会社での”仕事”として
Apacheプロジェクトの開発をする事が認められている。
つまり、本業。

その辺はプロジェクトによって全く扱いが違うぞ。
MyFacesのコミッタが誰だかわかってて言ってる？
例えば、コミッタのうちのひとり、
Oかもと氏はみかかでーたの仕事としてMyFacesの開発なんかしてないぞ。

0471デフォルトの名無しさん

2005/09/01(木) 21:52:13

＞俺がサーバを立てるなら連携させることは無いだろうな。
じゃあそうすればいいだろ。文句たれるな。

0472デフォルトの名無しさん

2005/09/01(木) 22:00:52

俺も某Apache関連プロジェクトのコミッタだけど会社の業務中はコッソリ・・・
業務として給料もらってできたらいいなー

0473デフォルトの名無しさん

2005/09/01(木) 22:01:10

わざわざJSFのスレにきて.NETの足元にも及ばないとか言ってる時点でお察し

0474463

2005/09/01(木) 22:22:58

>>470、>>472
それは、日本と欧米の違いじゃない？
まぁ、プロジェクトによって変わるというより、どこの国の奴って方が大きい気がする。
考え方の違いだな。

>>471
単純な文句ではない。
たとえばMyFacesの日付関連に関してもそう。
日付表示は国によって違うことも分かる。
だからこそinputCalendarとかではyyyyMMDDなど書式を指定できる。
にも関わらず書いたような事が起こる。
つまり、考えが足らない。
つうか、inputCalendarでyyyymmddの指定してもう一度ポップアップさせると
月を認識しないなんて、バグだろ・・・
それにMyFacesのコミッタに日本人がいるのに、日・月・年の並びになってて不思議に思わないのも変。
日付の表示方法ってのは何通りもあるから、大抵の言語とかでも日付の書式設定てのがある。
書式設定にあわせて入力欄も変わらないと意味が無いよな。

はっきり言って、コミッタの設計能力って新卒の新入社員並だよな・・・

HTTPServerに関してもそう。
書籍やインターネットなどで連携についてよく掛かれている。
確かに静的コンテンツを表示させるのには効率は良いだろう。
しかし静的コンテンツが殆ど無いにも関わらず、なんでも連携してる感があるのは否めない。

>>473
理論的に反論できない時点でお察し。

俺は実例もあげて言ってるわけだが、反論するなら例などあげて理論的に反論しないと、
負け犬の遠吠えにしか聞こえない。

0475デフォルトの名無しさん

2005/09/01(木) 22:34:48

先の見えない＆路線変更しまくりの.NETよりはJavaのほうがコミュニティーや各ベンダの
相互チェック体制がしっかりしている分いいかな。

0476463

2005/09/01(木) 22:38:01

>>475
Javaは路線変更していないと言えるのだろうか・・・

コミュニティーや各ベンダの相互チェック体制がしっかりしてるというが、
実装を行うコミュニティやベンダが多く、同じ仕様なはずなのに
多少なりとも独自仕様が入り、互換性がない。
つうかSunのJDK自体も独自仕様がはいってるし、正直終わってる。

0477デフォルトの名無しさん

2005/09/01(木) 22:42:43

また、本屋が儲かるな・・

0478デフォルトの名無しさん

2005/09/01(木) 22:43:55

まあ、糞.NETには糞MyFacesが相応な比較対象ということなんだな。
まともな実装にはかなわないのがわかってるから勝てそうな相手を選んだってことか。

0479デフォルトの名無しさん

2005/09/01(木) 22:45:40

>>474
MyFacesに関しては同意できるんだが、ApacheHTTPServerと同TOMCATの連携は
ロードバランスやクラスタリングの様な便利な使い方もあるわけで、なぜ否定的に見
られるのか分からん。
それに、TOMCATがガチでAPサーバとWEBサーバを兼ねてたら、IISとの混成なん
かで無駄な工夫が必要になる。

0480463

2005/09/01(木) 22:46:30

>>478
なら、そのまともな実装とやらを教えてくれよ。
俺のJavaの知識は1週間しかないんだよ。

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

0481デフォルトの名無しさん

2005/09/01(木) 22:49:00

いやホント　.Net 案件無いんですわ
たのんますよ

0482463

2005/09/01(木) 22:53:24

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

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

0483デフォルトの名無しさん

2005/09/01(木) 23:06:03

>>480
IBMの実装でも試してみろよ。
期間限定（30日だったかな？）なら無料で使えるから。

0484デフォルトの名無しさん

2005/09/01(木) 23:08:54

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

0485デフォルトの名無しさん

2005/09/01(木) 23:44:31

糞実装のMyFacesでも、少し前に新人に作らせた.NETプログラム（C#）よりはまともだ
だから、Javaの勝ちだな

0486デフォルトの名無しさん

2005/09/01(木) 23:54:22

>>474
> しかし静的コンテンツが殆ど無いにも関わらず、なんでも連携してる感があるのは否めない。

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

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

0487デフォルトの名無しさん

2005/09/02(金) 00:08:01

>>486
> ちょっと変わったことしようとしたら、ハマったが、それは経験不足だったからかもしれない。
俺もそこにギャップを感じた。
ありきたりの、おきまりのことをやるだけなら簡単なのだが、想定外の要件に対応しづらい。

0488デフォルトの名無しさん

2005/09/02(金) 00:14:06

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

0489デフォルトの名無しさん

2005/09/02(金) 00:17:32

2chで議論するまでもなく、.NETとJavaのどちらが優れているかなんて市場（経済）が証明している。
.NETなんて「そのうちJavaを追い越す」なんて5年前から言われていて、いつまでたってもてんで普及しない。
Java＞＞＞＞＞.NETなのは某255が暴れていた5年前から変わらなかったし、これからもそう簡単には変わらないよ。

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

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

0490デフォルトの名無しさん

2005/09/02(金) 00:18:56

流れを読まずに低レベルな質問。

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

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

0491デフォルトの名無しさん

2005/09/02(金) 00:23:32

>>489
＞これはJSFがいまだ流行らず従来のJ2EE仕様で現場が満足しているという状況にも同じことがいえるが。
これは来年が勝負だな。Java EEの標準仕様としてJSFが組み込まれるから、各ベンダーや開発環境の対応が充実してくると思われる。

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

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

0492デフォルトの名無しさん

2005/09/02(金) 00:24:13

>>488
大多数のドトネト厨はそんなところをキャッチアップできないDQNだからな。

0493デフォルトの名無しさん

2005/09/02(金) 00:29:02

>>489
市場経済で何かが主流になっている＝優れている？
俺的には断然否だな。

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

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

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

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

0494デフォルトの名無しさん

2005/09/02(金) 00:30:50

MSの技術はすぐに廃れるから信用できない。
かつてWindowsアプリ開発のスタンダードだったMFCでさえ、
今ではC++と共にすいたいしてしまった。
.NETだって1.0と1.1じゃえらい違いだ。

0495デフォルトの名無しさん

2005/09/02(金) 00:32:32

>>494
MFCは十分長生きしたと思うけどね
それにC++もそうだが、別に全然消え去ったワケじゃないよ

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

0496デフォルトの名無しさん

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死亡？！！！】
http://pc8.2ch.net/test/read.cgi/tech/1059208396/

0497デフォルトの名無しさん

2005/09/02(金) 00:35:17

ｽﾏｿ。俺がスレ間違えてた・・・

0498デフォルトの名無しさん

2005/09/02(金) 00:37:12

＞市場経済で何かが主流になっている＝優れている？
＞俺的には断然否だな。

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

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

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

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

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

0499デフォルトの名無しさん

2005/09/02(金) 00:38:44

Javaは1995年登場で5年後の2000年にはサーバサイドをかっさらっていったよなあ。
.NETは2000年夏に登場で5年後の今年もぜんぜんぱっとしないなあ。

0500デフォルトの名無しさん

2005/09/02(金) 00:42:40

>>498
いや、俺的には勝ち＝優れているとは全然思ってないだけ。
WindowsのC++フレームワークのデファクトになったMFCなんぞ
まさに糞の塊だし。まさに、「勝っただけ」の典型。

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

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

0501デフォルトの名無しさん

2005/09/02(金) 00:43:10

ｶﾞﾋﾞ━━(ﾟДﾟ;)━━━ﾝ!!!!! load-on-startupでホゲフガガって
今時はやらないんだな＿|￣|○||| 何時の間にやら時代遅れ……

0502デフォルトの名無しさん

2005/09/02(金) 00:44:38

>>496
回答トンクス。
>>501
別にやってもいいんじゃないの？
今時はダッセーとか言われるのかもしれないけれど。

0503デフォルトの名無しさん

2005/09/02(金) 01:22:22

>>491
サーバーサイドと言ってもいろいろなので。
以前ASPでやってたようなイントラ系の案件なら、ASP.NETに移行するのに何ら
問題はない気がする。

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

0504デフォルトの名無しさん

2005/09/02(金) 02:54:19

なんとなくLight Weight Javaという本を買ってﾁｮｺﾁｮｺいじり始めたんですが、あんまり理解できておりません。
サンプルを見ながら作ってまず思ったのは「セッション管理はどうすんの？」
で、次に思ったのは「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

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

0507デフォルトの名無しさん

2005/09/02(金) 19:41:20

>>470
Oかもと氏はContributerであって、Comitterではない。

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

0508デフォルトの名無しさん

2005/09/02(金) 19:42:35

あ・・・Committerね。タイポスマソ。

0509デフォルトの名無しさん

2005/09/02(金) 20:36:48

>>504
直接的なセッション管理についてはあまり気にすることはない、という感じかしら。
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

>>510
ログインページからsessionスコープのManagedBeanを呼び、そこにログイン状態を保持
ログインチェックはFilterで行い、Sessionからログインで使ったManagedBeanをチェックする。
ただし、ログインページから飛ぶときだけはチェックの対象外とする。

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

0512デフォルトの名無しさん

2005/09/03(土) 10:11:33

＞ただ、Strutsのときはログイン時のsubmit先のURLがすぐわかったけど、JSFではどうなるんだっけ？
JSFを使ったフォームの場合は、送信先URLは自ページだよ。
送信元はわかるから、送信元がログインページかどうかを判断すればいいんじゃね？

0513デフォルトの名無しさん

2005/09/03(土) 10:37:56

>>510
JSFではExternalContext経由で比較的低レベルの機能にアクセスできるよ。
もちろんSessionも触れるしRedirectもできる。

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

0514デフォルトの名無しさん

2005/09/03(土) 12:00:34

で、いつになったら具体的なサンプルコードなど出てきますか？

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

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

0515デフォルトの名無しさん

2005/09/03(土) 13:48:16

>>514
一冊、本買ってこいよ。

■ このスレッドは過去ログ倉庫に格納されています