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

JSF(JavaServer Faces ..

855:デフォルトの名無しさん
05/12/28 00:22:42
>>854
どういう意味だ？

856:デフォルトの名無しさん
05/12/28 01:00:43
家にも会社にもPCが無いんだろ。
2ちゃんは携帯からか？

857:デフォルトの名無しさん
05/12/31 11:04:18
>>856
すごいなｗ

858:デフォルトの名無しさん
06/01/03 03:33:41
JSFって、実際のところどうですか？

859:デフォルトの名無しさん
06/01/03 22:34:23
悪くないよ。
でも基本的にグラフィカルIDEが必要。
コードで書くもんじゃない。

860:デフォルトの名無しさん
06/01/03 23:08:36
テキストベースのコードを直書きしても、Strutsよりはるかにマシ。
GUIベースのIDEは、下記の点を割りきればOK。
・ベンダ依存のコードになる（他のツールでの編集は考えてはいけない）
・ソースを直接編集することは一切考えない（上に同じ）
・自動生成されたコードがキモい

861:デフォルトの名無しさん
06/01/04 00:56:06
>>859
JSFを信じない人のために: JSFに関するFUDをクリアーする
URLﾘﾝｸ(www-06.ibm.com)

これによると

>JSFに関しては3つの大きな誤解がありますが、その第1は、作業のためにWYSIWYGツールが必要だというものです。

だってさ。
詳しくは読んでないから知らんが。

862:デフォルトの名無しさん
06/01/04 01:20:14
>>861
>『WYSIWYGツールを使わなくても、JSF開発はStrutsよりもずっと簡単なのです！』

あくまでもStrutsに対する相対評価だね。

863:デフォルトの名無しさん
06/01/04 03:16:51
Java初心者なんですが、できるだけお手軽にWebアプリを作りたいので、
JSFに注目してます。
Javaっていろんなフレームワークがあって、何から手をつけてよいのか迷い
ます。
JSFでWebアプリを作れるようになるには、どういう順序で勉強すればいいの
でしょうか。
Javaの基礎（文法）⇒JSPとサーブレット⇒JSF
こんな感じでいいでしょうか。

864:デフォルトの名無しさん
06/01/04 08:08:46
順番はそれでいいと思うけど、単にお手軽につくりたいだけならPHPの方がいいような･･･

865:デフォルトの名無しさん
06/01/04 11:31:15
>>863
sun java studio creator を使え。
それでもだめならあきらめろ。

866:デフォルトの名無しさん
06/01/04 16:49:33
863です。レスありがとうございます。

>>864
PHPとASP.netは使えます。これらに慣れすぎたせいでJavaでもお手軽に
作れないかなという気持ちになってしまいました。

>>865
早速ゲットしました。これが無料って、すごいですね。

867:デフォルトの名無しさん
06/01/04 19:36:08
sun java studio creatorを使いこなせれば、
たいていのWEBアプリはOKだと思う。

868:デフォルトの名無しさん
06/01/04 19:42:52
>JSFに関しては3つの大きな誤解がありますが、その第1は、作業のためにWYSIWYGツールが必要だというものです。
必要なんじゃなくて、ツールと一緒に使うことも視野に入っているだけ

869:デフォルトの名無しさん
06/01/04 20:04:06
はいどうぞ。
URLﾘﾝｸ(pcweb.mycom.co.jp)

870:デフォルトの名無しさん
06/01/17 00:07:12
JSFにはバリデーションマスクみたいな機能ってないんでつか？
わざわざActionListenerでコンポーネントツリーつかってシコシコ
processValidators呼んでやんないとだめなんすか？

それともこんな質問してる俺が馬鹿なだけですか？

871:デフォルトの名無しさん
06/01/17 16:33:55
JSPから引数があるメソッド呼ぶ方法ってないの？

こんなのを呼びたい
public String getLabel(int state) {
return (state == 0 ? "０" : "１");
}
エンティティに表示文字列を意識させたくない

872:デフォルトの名無しさん
06/01/17 16:41:54
普通に呼び出せばいいと思うが。
しかし、選択肢はJSPかエンティティしかないのか？

873:デフォルトの名無しさん
06/01/17 17:07:51
具体的にどうすれば良いのだ？

#{hoge.label}
の形式では無理なのか？

874:デフォルトの名無しさん
06/01/17 17:50:40
スクリプトレット使えばよかろう。

875:デフォルトの名無しさん
06/01/17 18:22:50
<t:dataTable value="#{aaa.hogeList}" var="hoge">
　<h:column>
　　<f:facet name="header">
　　</f:facet>
　　<%= hoge.getLabel() %>
　</h:column>
</t:dataTable>

せんせーできません

876:デフォルトの名無しさん
06/01/17 19:04:37
page.getAttributeじゃねぇの？

877:デフォルトの名無しさん
06/01/17 19:48:54
そもそもdataTableタグの中でスクリプトレット使えないから・・

878:デフォルトの名無しさん
06/01/17 19:50:38
>>877
JSF1.1まではね。

879:デフォルトの名無しさん
06/01/17 20:20:55
俺らみたいな低民族がまともに開発できるバージョンで教えてくれ

880:デフォルトの名無しさん
06/01/18 01:39:20
JSFってどんなものか試しにSun Java Studio Creator使ってみたけど、
凝ったことやろうとするとなんか面倒じゃね？

881:デフォルトの名無しさん
06/01/18 07:36:45
>>880
それはCreatorが面倒なだけ。

882:デフォルトの名無しさん
06/01/18 07:49:08
>>878
便乗だけど、JSF1.2で動かそうと思ったら、今はGlassFishしかないの？
そもそもTomcat6が作られてないからServlet2.5、JSP2.1も（GlassFish以外に）今は無い？

883:デフォルトの名無しさん
06/01/18 11:28:49
>880
Eclipse＆JSP手書きで充分

884:デフォルトの名無しさん
06/01/18 12:26:05

俺もポトペタ要らん派だけど、beanやproperty/methodの
存在チェックくらいして欲しいと思わないかい？

885:デフォルトの名無しさん
06/01/18 21:05:18
バッキングBeanって基本的に1つのサービスに対してしか必要ない？

886:デフォルトの名無しさん
06/01/18 22:10:03
どういうこと？

887:デフォルトの名無しさん
06/01/18 22:13:19
>>884
NetBeans5の、タグをポトペタする機能は便利だよ。
h:dataTableなんかをパレットからD&Dしてデータを指定したら、適当なh:columnなんかが入ってくれる。
新しいアイテムの自作も難しくないし。
JSFではWYSIWYGではない環境でのポトペタが便利だと思う。

888:デフォルトの名無しさん
06/01/18 22:18:46
なんか１画面で１つのバッキング・ビーンを定義するっていう風潮があるじゃんか
無駄なんだよな。

本当にバッキング・ビーンとして扱うべきものは、状態が変化するモノなんじゃないかと。
そうなると必然的にサービスと紐付いてくるわけさ

889:デフォルトの名無しさん
06/01/19 00:36:10
そうするメリットってどんなものがあるの？
個人的にはどっちでもいいけど、画面項目設計書から余計な事を
考えなくとも、機械的にソース吐けるから大した手間でもないし、
Beanは画面から送られる使い捨てキャリアとしてしかみてない、
且つ、1画面=1Beanでシンプルでよいし・・ということで、気にせず
作ってしまってるんだけど。。

890:デフォルトの名無しさん
06/01/19 01:24:07
・メリット
コード量が圧倒的に少なくて済む

・デメリット
画面開発者がどのBeanを使うかを理解しないといけない

逆に１つの画面で１つのBeanにすると
・メリット
画面中心で単純

・デメリット
同じ処理を複数回書く必要がでてくる
コードが増える
うざい
くさい
画面が増えたとき面倒
メモリ使用量が増える
設定ファイルの記述が増えるのも面倒
画面間の値の受け渡しに気を遣う必要がある

とりあえず、
定型ソースと言えど、人間が触る部分のコード量が多いのはシステムの見透しが悪くなるからうざいのと、
同じことを何度も書くのはあほらしい

891:デフォルトの名無しさん
06/01/19 02:22:42
>・デメリット
>画面開発者がどのBeanを使うかを理解しないといけない
これはメリットのわりにはかなり痛いデメリット。
自分ならやっぱ1画面=1Beanを選択するよ。
（多数の初心者のような開発者抱え込む場合ならなおさら）

対して1画面=1Beanのデメリットはどれも小さいものばかり。
その中では実際デメリットにもなりえないものも、いくつかあると思う。

892:デフォルトの名無しさん
06/01/19 05:20:43
>>891
>画面開発者がどのBeanを使うかを理解しないといけない

これは実際には、画面開発者がどの機能を実装しているかを理解しないといけないということ。
画面ごとにBeanを作ると、持ちまわるべきデータを分断してしまうことになって、そのためのロジックが必要になったりする。

大きな機能ごとの幹になるBeanを作って、細かい画面制御的なBeanが必要なときは画面ごとに用意するというような、ハイブリッドな考え方。
どちらかにこだわると失敗する。

893:デフォルトの名無しさん
06/01/19 09:52:29
>891
どこが小さいデメリットばかりなんだよ

>画面開発者がどのBeanを使うかを理解しないといけない
これは設計者がちゃんと指示すれば済む問題

894:デフォルトの名無しさん
06/01/19 18:08:01
ちょっともどるが>>871みたいなのはコンバータ作るべきなんじゃね？

895:デフォルトの名無しさん
06/01/19 19:00:16
>894
目からうろこ
ﾏｼﾞｻﾝｸﾇ！

896:デフォルトの名無しさん
06/01/19 23:50:32
>同じ処理を複数回書く必要がでてくる
>コードが増える
>画面が増えたとき面倒
>設定ファイルの記述が増えるのも面倒
これらは工数として見たとき、どちらを採用しても大した違いはないと
思うんだけどな。
仮に差があったとしてもシステム全体で考えても数人日程度だと思う。
（どっちが工数大きくなるかは置いておいて）

>メモリ使用量が増える
これは逆じゃない？ごった煮Beanの方が状態管理する必要のないものまで
セション管理される可能性が高いと思う。
それでも微々たるもので、メモリを圧迫するレベルとはかけ離れた
レベルの話だと思うけど。

>画面間の値の受け渡しに気を遣う必要がある
ごった煮の1Beanだとある状況で扱う項目/扱わない項目がでてくるわけだから、
1画面=1Beanで気を使う部分とは別に、意識しなければならない要素がでてくると思う。
（このタイミングでこの項目は使うんだっけ？？みたいな感じで何度も設計書を
見直さなければならないとか）

897:デフォルトの名無しさん
06/01/19 23:56:59
>それでも微々たるもので、メモリを圧迫するレベルとはかけ離れた
>レベルの話だと思うけど。
自己レスだけど、これは仕様によるからなんともいえないね。
大きなデータ構造を何百件ももつ必要がある場合とかは考慮が必要だと思う。
そこまで大きなデータを持たなければならない状況もレアだと思うけど。

898:デフォルトの名無しさん
06/01/20 01:53:35
>896
項目数もアクセス数も画面数も少ないのなら1画面1Beanの場合でもリソースやそれの管理に伴う時間なんかは無視できるかもな
ただ聞きたいんだがManagedBeanってSessionからはいつ消えるの？

どこからごった煮という定義になったのか知らんが、ごった煮という定義は間違ってる。
おそらく1機能＝1Beanという理解をしているんだろうが、それも一つの手ではあるがあまり良い手ではない。

Managed-Bean（≒バッキング・ビーン）は、
1つのサービスを起動する際に関係のある状態が変化するオブジェクト
と位置づけてはどうだろうか？と。

>ごった煮の1Beanだとある状況で扱う項目/扱わない項目がでてくるわけだから、
サービスが必要とする最低限の項目のみで良いからそんなことにはならん

>1画面=1Beanで気を使う部分とは別に、意識しなければならない要素がでてくると思う。
画面間でオブジェクトを受け渡す場合、「えーっと、、、次の画面のBeanはなんだっけ？？」みたいになるだろ。
画面遷移を意識するはnavigation-ruleだけでお腹いっぱい

899:デフォルトの名無しさん
06/01/22 02:23:11
昨日からJSF始めたんだけど、Managed-Beanてのは、プレゼンテーション層用の
Beanて認識でいいの？
今まで自作フロントコントローラーからビジネスロジックのコマンド実行する
方法ばかりやってたせいかいまいちピンと来ない・・・

900:デフォルトの名無しさん
06/01/23 10:05:55
>899
正解。
ビューコントローラに相当します。

901:デフォルトの名無しさん
06/01/24 01:28:32
>899
ハッキリ言ってどうにでも使える。
上の方でもやってるが、ビューとしてもOKだし、ビジネスロジックへの橋渡しとだけ考えても良い
重要なのはどうやるかをキチンと決めて、一貫性のある開発方法を作ること

902:デフォルトの名無しさん
06/01/25 09:58:34
>>899

参考までにオレのやり方を露出

managed-bean(オレはp層と認識)
　　↓
facade(serviceLayer)
　　↓
facadeImple(ApplyTransactionPointByAOP)
　　↓
dao
　　↓
daoImple(dataStoreLayer)

こんな感じでやってる。

903:デフォルトの名無しさん
06/01/25 20:22:49
902に同じ。

904:デフォルトの名無しさん
06/01/25 23:27:36
もう行き止まりやな。

905:デフォルトの名無しさん
06/01/26 00:47:56
Sun Java Studio Creator 2 Early Access 第 2 版がリリースされました。
URLﾘﾝｸ(sdc.sun.co.jp)

906:デフォルトの名無しさん
06/01/27 00:41:23
JSF で CHTML を出力する方法なんてある？

907:デフォルトの名無しさん
06/01/27 05:40:33
>>906
RenderKitをカスタマイズ

908:デフォルトの名無しさん
06/01/28 09:50:44
>>905

Early Accessではなくて、正式版では？

909:デフォルトの名無しさん
06/01/28 11:26:36
ほんとだ！Sun Java Studio Creator 2 の正式版がきてる。
Early Access 第 2 版は３日間のためだけに存在したのか？
2004Q2 にくらべて１００Ｍも大きくなっている。

910:デフォルトの名無しさん
06/01/28 15:55:35
>>908
正式リリースは昨日。

911:デフォルトの名無しさん
06/01/29 00:35:12
だいたいみんな同じようなやり方だな。
ところで、facadeからmanaged-beanにドメイン層の
オブジェクトを直接返したりってする？
やっぱりDTO使った方がいいのかな？

912:デフォルトの名無しさん
06/01/30 13:14:20
1画面に1つのバッキング・ビーンを用意してた場合で、
ユーザが行った操作を記録したいっていう要件があった場合はどうするの？
やっぱりメソッド単位でログ吐かせるのか？

913:デフォルトの名無しさん
06/01/30 17:48:24
StrutsでいうGlobalExceptionみたいなことはできんの？

914:デフォルトの名無しさん
06/01/30 19:23:37
>>912
素直にfilterでやるとか、あるいはAOPでやるとかの方法の方が
ロジック分離できてｳﾏｧ・・・
と思うのだけど。

915:デフォルトの名無しさん
06/01/30 19:37:48
>914
Managed-BeanにAOPを適用する方法を教えてください

916:デフォルトの名無しさん
06/01/30 22:14:15
>>915
SpringとかAspectJとかを使う

917:デフォルトの名無しさん
06/01/31 00:15:04
>>912 リスナ

918:デフォルトの名無しさん
06/01/31 00:45:14
>916
画面と1対1になっているManaged-BeanにAOPを適用する方法を教えてください

919:デフォルトの名無しさん
06/01/31 07:22:09
>>918
SpringとかAspectJとかを使う

920:デフォルトの名無しさん
06/01/31 09:58:52
>919
springではできん

921:デフォルトの名無しさん
06/01/31 23:59:13
そうか？

922:デフォルトの名無しさん
06/02/01 00:17:17
こしがや

923:デフォルトの名無しさん
06/02/01 02:06:25
SpringってManaged-Bean兼Spring-Beanができなかったっけ？
つーか、Managed-Beanてよくわからん。
自身をDTO代わりにFacadeに渡したりするのはよくないのかな？

924:デフォルトの名無しさん
06/02/01 09:53:40
>>921-922
せんげんだい

925:デフォルトの名無しさん
06/02/01 10:53:03
いなかものには難しいスレです(´･ω･`)

926:デフォルトの名無しさん
06/02/01 16:29:04
>>920
できるだろ。DelegatingVariableResolver使え。

927:デフォルトの名無しさん
06/02/01 19:04:54
>921
>926
キミらDIと勘違いしてない？

928:デフォルトの名無しさん
06/02/01 19:37:35
#{jsfBean.aaa.name}

<managed-bean>
<managed-bean-name>jsfBean</managed-bean-name>
<managed-property id="aaa"><value>#{springBean}</value></managed-property>
</managed-bean>

↑これがしたいわけではなくて、

#{springBean.name}
でアスペクトが織り込まれたものを使用したいんだわ

929:デフォルトの名無しさん
06/02/01 21:16:15
あ、そういえば、どこぞのオプソ使えばSpring側から
JSFのBeanを取得することが出来るという話を
読んだことがある。

誰かソ－ス覚えてない？

930:デフォルトの名無しさん
06/02/01 22:36:14
>>927
なぜ勘違いだと思うのかまったくわからん。
Springで定義したBeanはSpringでAOPできるだろ。

>>928
だから、DelegatingVariableResolver使えばSpringで定義したBeanを
JSFから使えるんだってば。

あなたが言う
「↑これがしたいわけではなくて」
と
「#{springBean.name} 」がどう違うのかね？

きみら、VariableResolverが何をするモノなのかわかってるの？

931:デフォルトの名無しさん
06/02/02 00:15:26
変数解決さん

932:デフォルトの名無しさん
06/02/02 00:27:36
>>927
SpringでDIできた時点でAOP使えるだろ

933:デフォルトの名無しさん
06/02/02 01:41:08
なぁちなみにspringのBeanをmanaged-beanとして使う場合、scopeをsessionにする方法ってあるの？

934:デフォルトの名無しさん
06/02/02 09:59:00
>>933
Springでシングル㌧をfalseにしときゃ毎度newだから、
sessionScopeのmanaged-beanが生成される度に
新規SpringBeanインスタンスが生成され一連托生。

だよね？

935:デフォルトの名無しさん
06/02/02 11:46:33
>934
そんなことしたら意味が無い
managed-beanとしてspringのbeanを使いたいんだよね

936:デフォルトの名無しさん
06/02/02 14:36:26
>>935
URLﾘﾝｸ(jsf-spring.sourceforge.net)

オマイ人柱になって使って報告ｼﾙ

937:デフォルトの名無しさん
06/02/03 11:57:23
Creator2どうですか？

938:デフォルトの名無しさん
06/02/04 00:53:36
>>928
少数派かもしれんが、うちでは自前VariableResolver＋
Seasar2でAOPを適用してるぞ。
scopeはapplicationでもrequestでもsessionでも可だ。

Seasar2のcomponentをJSFのmanaged-beanとして使う
ためのVariableResolverはS2JSFのソースにずばり入っ
てる。

＃でも、うちではS2JSF自体は使ってない。
＃VariableResolverだけ真似してる。

939:デフォルトの名無しさん
06/02/04 10:23:44
行ヘッダと列ヘッダを持った2次元表をdataTableで作る際、複数カラムの
行ヘッダを作る場合は普通にcolumnを並べるだけでいいですが、列ヘッダを
複数行にするのになにかいい方法はないでしょうか？
headerの中にpanelGridを埋めても見た目がきれいじゃないですし。

bindingでUIDataを直接操作すればできるかとも考えたのですが、よく
わかりませんでした。

940:デフォルトの名無しさん
06/02/04 21:12:29
MyFacesのdataListで頑張るとか。

941:デフォルトの名無しさん
06/02/07 05:38:11
>>1
> スレがないので新しくたてました
> URLﾘﾝｸ(www.atmarkit.co.jp)
> URLﾘﾝｸ(java.sun.com)

942:デフォルトの名無しさん
06/02/19 09:30:21
MyFacesを利用したJBossなんかの実装だと
org.apache.myfaces.webapp.StartupServletContextListener
をリスナーに登録する必要があるけど
SunのRIをつかってるGlassfishなんかだと必要ないよね？

両方のアプリケーションサーバに対応したウェブアプリケーションをつくりたいときって
どうしたらいいの？

web.xmlのレベルでMyFacesに依存しちゃうのを避けたいんだけど……

943:デフォルトの名無しさん
06/02/19 10:12:14
>>942
MyFacesのコンテキストリスナが見つかったらそれをインスタンス化して実行する
コンテキストリスナを自作するってのはどうよ？

944:デフォルトの名無しさん
06/02/19 16:14:45
>>942
MyFacesの最新バージョンではStartupServletContextListenerは必須ではないみたいだから、
そのうちJBossでも変わるんじゃないの？

945:デフォルトの名無しさん
06/02/20 11:23:11
>>943-944
MyFacesの最新版で試してみます
ありがとん

946:デフォルトの名無しさん
06/02/23 18:01:46
サン、ウェブアプリ開発ツール「Sun Java Studio Creator 2」を無償公開
URLﾘﾝｸ(japan.zdnet.com)

947:デフォルトの名無しさん
06/02/26 04:05:35
JSFのリスト系のコンポーネントで、各データ行ごとにHTMLタグを混ぜ込んで
出力したくて、h:dataTableとかx:dataList使ってみたらHTMLタグが全部
スルーされちまったんだが、こういうケースだとJSTL使うしかないの？

それと、h:outputText使ったら、文字が全部コードとして出力されたんだが
これは標準仕様なの？

環境はMyFacesです。

948:デフォルトの名無しさん
06/02/26 04:16:57
＞こういうケースだとJSTL使うしかないの？
現状ではh:outputText等を使って、escape="false"を使うしかない。
この問題は、次バージョン1.2で${・・・}も使えるようにすることで解決される。

＞それと、h:outputText使ったら、文字が全部コードとして出力されたんだが
＞これは標準仕様なの？

Yes.

949:947
06/02/26 22:30:42
>948
サンクス

やっと楽しくプログラミングかと思ったらブラウザのリロードを押すと
1回おきに例外が発生する現象が・・・
cannot add component with id '_id5' andとかって出てくるんだが、これの
原因がサパーリわからん。
これのせいで今日1日つぶれてしまいますたorz

950:デフォルトの名無しさん
06/02/28 13:06:53
>>949
JSF実装のバグかもよ。
正しいIDが生成されないでエラーになるバグがいくつかあるから。

951:デフォルトの名無しさん
06/03/05 09:01:46
>>949
アプリケーションを起動したままJSPのみ書き換えてリロード、というやりかたを
している場合、保持されているステート情報との不一致でそういうエラーが発生
することがあったような。

952:デフォルトの名無しさん
06/03/11 15:33:58
JSF のパフォーマンスってどうなの。Strutsを使ったことが無いんでテストするにも時間かかりすぎちゃうので
貴殿らの経験談を聞かせてくれ。

953:デフォルトの名無しさん
06/03/11 15:48:47
実装による。
それと、Strutsを使ったことがなかったらどうしてテストする時間がかかるのか知りたい。
ぜんぜん関係ないのに。

954:デフォルトの名無しさん
06/03/12 00:54:34
EclipseでAmaterasのFacesIDEプラグインを使っているんですが、MyFacesのタグを使おうして以下の現象で困っています。
EclipseHtmlEditor、FacesIDE共にバージョンは2.0です。

JSPファイルの先頭に

<%@ taglib uri="URLﾘﾝｸ(myfaces.apache.org)" prefix="x" %>

を入れているにも関わらず、
「"x"に対応するtaglibディレクティブが存在しないかTLDファイルが見つかりません。」
と表示されてしまいます。
設定でTLDのところにローカルのtldファイルは指定しているんですが・・・。

どなたかFacesIDEのJSPエディタでMyFacesのタグの補完を出来るようにする方法を知っている方いたら教えて下さい。

955:デフォルトの名無しさん
06/03/12 01:14:37
JSFとStrutsは同じものじゃないのか。誰か易しい説明ｷｳﾞｫﾝ

956:デフォルトの名無しさん
06/03/12 01:36:20
>>955
よし、易しく説明しちゃうよん。
「ま　っ　た　く　ち　が　う」

957:955
06/03/12 01:59:36
>>956
ありが㌧。でもそれは説明とは言えない希ガスwww
StrutsはWebアプリを開発するためのフレームワーク、
JSFもWebアプリを開発するためのフレームワーク。
同じフィールドにあるもの、とみても良いわけ？
たとえば旅費精算システムなんてのをつくりたい場合、
JSFとStrutsの片方を知っていればもう片方を知る必要は無い？
両方知っていないとだめ？
そこらへんがわからん。上のレスをみるとStrutsつぶしだよね、この技術は。
とあるから、JSFはWebアプリ開発をするためのフレームワークであって
昔からあるStrutsと同等もしくはそれ以上の機能を有していると勝手に解釈しちゃってるが。
エンジニアさんが周りにいないので素人っぽい内容でｽﾏﾝｺ

958:デフォルトの名無しさん
06/03/12 02:13:52
>>957
基本的にはどっちかを知ってればいいが、
どちらもServlet/JSPという技術を根っこにもっているという
点では同じもの。

959:955
06/03/12 02:21:28
>>958
なるほど、ありがとう。

960:デフォルトの名無しさん
06/03/12 02:50:35
いまさらStrutsはないな。
JSFを体験したければ、Java Studio Creator 2でも使ってみれば？

961:デフォルトの名無しさん
06/03/12 02:57:48
あんなメモリ最低1GBとかほざくツールを勧めるなよｗ

962:デフォルトの名無しさん
06/03/12 04:02:39
開発なら1Gぐらいないと厳しくないか？

963:デフォルトの名無しさん
06/03/12 04:12:32
Javaの世界ってこういう部分がおかしい
例えば最近のノートPCなら256MBくらいだろ
だったらリソース占有してもいいから、ここを基準にすべき
ホームページビルダーを見習え

964:デフォルトの名無しさん
06/03/12 04:12:54
512Mくらいでも、体験だけならいいよ。

965:デフォルトの名無しさん
06/03/12 10:07:31
JSFは今後のWebApp開発のメインストリームになるもの？それともみんな様子見かまだStrutsなど？
Tapestory、RIFE、WebObjects、Teedaなどとイロイロあるけど、やはりJSFがSunがIDEで採用するだけあって情報量やノウハウの面で優位か？
微妙にスレ違いでｽﾏｿ

966:デフォルトの名無しさん
06/03/12 10:20:15
SunのCreatorでJSFを体験？
できないよ。
JSFなんか知らなくても裏でこっそりJSFが動いているアプリケーションを作れちゃうツールなんだから。

967:デフォルトの名無しさん
06/03/12 10:21:50
Javaの世界はベンダー勢力とオプソ勢力が相対しててどうなるかワカラン。
ベンダーはJSF担いで商売しようとしてるし、
オプソの人たちもJSFのフリー実装や関連ツールでがんばってるし、
また別のオプソは別のフレームワーク担いでるし。

金持ってるベンダーが担いでるJSFが主流になりそうだけど
糞EJBみたいに、オプソの人たちの主張を取り入れて軌道修正することもあるので
まだどうなることやら。
JSFも、業界の慣例にならって、3.0まで主流にならないんじゃね？

968:デフォルトの名無しさん
06/03/12 10:23:39
>>965
今後のメインストリームにはなると思う。
同じものをJSFとStrutsで作ってみれば、JSFの良さは実感する。

ただし、現時点ではまだ調査・研究・学習段階だと思う。
たとえば、来月から始まるプロジェクトだったら、俺ならまだStrutsを選ぶ。
JSFは実装の未熟さや開発者のノウハウ不足で苦労しそうな・・・・

969:デフォルトの名無しさん
06/03/12 11:12:18
>>966
だから体験にいいんだよ。

970:デフォルトの名無しさん
06/03/12 13:47:32
というかさ、素のJSFはあんまりつかわれないんじゃな？
上にもう一枚ラッパをかまさないと使いにくい気がする。

971:デフォルトの名無しさん
06/03/12 14:12:29
>>961
ぽとぺたやるなら1G未満の環境はstrutsでもありえないんだけど

972:デフォルトの名無しさん
06/03/13 00:10:16
>>970
ラッパばかりもういいよ。
ってかJSF仕様がそんなだめなの？
少しはバカ向けのMSを見習ったほうがいいのか。

973:デフォルトの名無しさん
06/03/13 05:13:14
そんなにラッパが必要だとは思わんけどな。

974:デフォルトの名無しさん
06/03/13 07:38:02
Struts時代も、汚いラッパを被せた独自フレームワーク利用を強制されたことあったな
使いやすくしてるつもりなんだろうけど、メンテナンス性が酷くてTaglibとかぐちゃぐちゃになってた

975:デフォルトの名無しさん
06/03/13 10:02:02
Strutsと比較するのであれば、JFSが上手くいくように思う。
だけど、Tapestoryのような全然考え方の違う物あって、どっちが正解なのかはまだ判らん。
ツールとの相性を考えると、イントラならJFS、コンシューマならTapestoryのような気もする。
967にほぼどーい。

976:デフォルトの名無しさん
06/03/13 23:11:25
いや、コンシューマでも少なくとも日本ではtapeは使えないよ。
JSFで、MayaとかFaceletとか、HTMLテンプレートエンジンを使うほうがいい。

977:デフォルトの名無しさん
06/03/13 23:43:46
>>975
英語を勉強しましょう。

978:デフォルトの名無しさん
06/03/14 10:23:17
そーいえば、ウィルコムストアはURLを見る限りJFSで実装されてる。
使っている所は既に使っているようで。

979:デフォルトの名無しさん
06/03/14 14:23:35
イントラとかコンシューマって何だ？
B2BとB2Cのことか？

980:デフォルトの名無しさん
06/03/14 22:57:29
>>978
JFSって何ですか？ｗ

981:デフォルトの名無しさん
06/03/15 02:37:16
>>980
URLﾘﾝｸ(www.hi-ho.ne.jp)

982:デフォルトの名無しさん
06/03/15 17:33:51
ブラクラかと思った。

983:デフォルトの名無しさん
06/03/16 12:42:26
>>982
結局何だったの？

984:デフォルトの名無しさん
06/03/16 12:47:18
>>980
URLﾘﾝｸ(images.google.co.jp)

985:デフォルトの名無しさん
06/03/16 12:48:38
↑間違えた。

986:デフォルトの名無しさん
06/03/16 23:27:40
JSFで画面の値を保持するManagedBeanのscopeって何にするのが一般的かな？
ValidatorでエラーになるとinputHiddenに持たせておいた値が消えるから、
その対策をいちいち書いてると全然楽じゃないんだけど・・・。

そもそもJSFではSession使うのをケチるな、って事なのかなぁ？

987:デフォルトの名無しさん
06/03/17 01:27:40
「用途による」

988:デフォルトの名無しさん
06/03/17 01:54:42
>>987
例えば？
なんかそーゆー判断の基準みたいなものあったら教えて。

989:デフォルトの名無しさん
06/03/17 14:22:12
987じゃないけど、単純に
　リクエストをまたいで保持するならsession
　それ以外ならrequest
じゃないの？

990:デフォルトの名無しさん
06/03/17 14:25:35
>>986
sessionスコープにいろいろ残り続けるのがいやなら、
VariableResolverを実装したクラスを作って、自前の
スコープを作ってあげても良いかも。
っていうか、自分はそうしてる。

991:デフォルトの名無しさん
06/03/17 14:36:18
次スレ
テンプレ張りはおまいらにまかせた

JSF(JavaServer　Faces)2
ｽﾚﾘﾝｸ(tech板)l50

992:デフォルトの名無しさん
06/03/17 14:41:49
埋めるか

993:デフォルトの名無しさん
06/03/17 14:53:32
埋め埋め

994:デフォルトの名無しさん
06/03/17 17:09:25
もっとしっかりうめろよ↓

995:デフォルトの名無しさん
06/03/17 20:43:15
うめー

996:デフォルトの名無しさん
06/03/18 15:17:19
うめ

997:デフォルトの名無しさん
06/03/18 15:19:00
うめ

998:デフォルトの名無しさん
06/03/18 15:26:23
うめ

999:デフォルトの名無しさん
06/03/18 15:28:13
うめ

1000:デフォルトの名無しさん
06/03/18 15:29:40
うめ

1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。