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

JSF(JavaServer Faces ..

751:デフォルトの名無しさん
05/10/13 16:14:28
>>749
×<servlet-class>javax.faces.webapp.FaceServlet</servlet-class>
○<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>

って感じか？

752:デフォルトの名無しさん
05/10/13 16:20:56
>>750
＞.jsp
そこはつっこまないで下さいｏｒｚ

JSFは
jsf-impl.jar・jsf-api.jar・commons-logging.jar・commons-digester.jar・commons-collections.jar
commons-beanutils.jar・demo-components.jar・standard.jar・jstl.jar
を動かすJSPフォルダ下のWEB-INF/libにいれております。

エクリプス上でTomcatを動かしてるのですが、起動した時に警告メッセージみたいなのが出てますね･･･

2005/10/13 16:21:59 org.apache.catalina.startup.ContextConfig applicationWebConfig
情報: アプリケーションのweb.xmlが見つかりません、デフォルトだけを使用します StandardEngine[Catalina].StandardHost[localhost].StandardContext[/test]

とか

致命的: Error loading WebappClassLoader
delegate: false
repositories:
/WEB-INF/classes/
----------> Parent Classloader:
org.apache.catalina.loader.StandardClassLoader@879860
javax.faces.webapp.FaceServlet

とか

2005/10/13 16:21:43 org.apache.catalina.core.StandardContext loadOnStartup
致命的: サーブレット /sampleJSPProj がload()例外を投げました
java.lang.ClassNotFoundException: javax.faces.webapp.FaceServlet

とか・・・
これが原因っぽいですね。。。

753:デフォルトの名無しさん
05/10/13 16:27:53
>>751
ﾜﾛﾀ。それも本のとおりか？
JSF以前に、普通にServletも動かせないんじゃないのか？こいつ。

754:デフォルトの名無しさん
05/10/13 23:43:39
JSFでCSSを利用したサンプルプログラムって無いですかね？
ネットとかで公開されているのがあれば、参考にしたいのですが･･･

755:デフォルトの名無しさん
05/10/13 23:58:07
>>754
何に困ってるの？
それだけだと特にJSFとは関連しないように思うけど。

756:デフォルトの名無しさん
05/10/14 00:17:31
<link href="css/hoge.css" rel="stylesheet" type="text/css">

HTMLと同じ用に↑をつけたらエラーではじかれてしまったんですが？
普通はそのまま使えるんですか？

757:735
05/10/14 01:42:24
誰か～、735で記載した件に答えてくれ～(泣)

>>756 エラーではじかれるってサーブレットエラー？
jsfタグを使っているページなのに <f:view> </f:view>がないとかいう落ちではないよね？

758:デフォルトの名無しさん
05/10/14 05:40:51
>>735
なにを言いたいのかがよくわからないが・・・
遷移前のManagedBeanで処理してから呼び出せばいいんでない？

759:デフォルトの名無しさん
05/10/14 06:03:59
>>756
JSFとは関係ないが、cssファイルがWEB-INF以下に配置されているって落ちではないよね？

760:デフォルトの名無しさん
05/10/14 07:54:11
>>756
＞エラーではじかれてしまったんですが？
そのエラーが何かを推測させるゲームかなんかですか？
それとも釣りですか？

761:デフォルトの名無しさん
05/10/14 07:55:45
>>735
俺も何を問題にしたいのかがわからない。>>758の言うとおり、
ManagedBeanで値を取得してから表示すればいいだけじゃないのか？

762:デフォルトの名無しさん
05/10/14 11:18:40
<INPUT TYPE="password" ISTYLE="4">
↑の感じのようなパスワードを半角入力にしたいのですが、
JSFのinputタグにあります？

763:デフォルトの名無しさん
05/10/15 00:25:16
>>762
inputSecretでパスワードのようになる
半角入力に変わるのは使った事無いなー
誰か補足よろー

764:デフォルトの名無しさん
05/10/15 19:38:36
/WEB-INF/の下が見えるという事に驚いている人は・・・

765:デフォルトの名無しさん
05/10/15 19:49:15
心やさしい人

766:デフォルトの名無しさん
05/10/16 02:32:15
>>729
アホか？xmlは仕様書から吐き出すもんだろ
その辺の事を考えずに上流工程に時間を取らないからxmlを書く事態になるんだろ
UI設計するメンバーにWebの知識がないとかもうアホかと

ってここはマ板だったな

767:デフォルトの名無しさん
05/10/16 10:27:47
>>766
おまえバカ？本質を分かってねーんじゃねーか？

XML はソースコードにでも書けるものの一部を移動しただけだ。
いわば XML もソースコードも仕様書の内容をコンピュータに分かる
形式で記述しただけのものだが、決定的に詳細度が異なる。
昔から設計書を元にしたコード生成はあるが、現状を見ればいい。

依存性の高い部分だけを XML にしてるからコードとは違うとか言うのだったら、
現時点では仕組みを作ってる奴のオナニーだ。プロジェクトをやってるんだったら
分かってるんだろーが、だいたい 9割の出来ない奴と 1割の出来る奴で構成される。
本当に再利用性、保守性、将来性を見越して依存性を切り分けれるのは
ほとんどいねーよ。おまえもひょっとしたら、その 1 割側でない可能性もあるな（w

だから、仕組み（フレームワーク）を作ってる奴は分かってねーって言ってんだ。

768:デフォルトの名無しさん
05/10/16 11:31:37
その1割の奴が手綱を握れるように、ソースコード中に散在させないで
設定ファイルで一括管理するんじゃないの？

769:デフォルトの名無しさん
05/10/16 13:32:07
>>768
一括管理のメリットより、増える手間のデメリットが莫大

770:デフォルトの名無しさん
05/10/16 14:15:06
>>768
最近の「XMLに何でも外だし」はもはや「設定ファイル」の範疇を
はるかに超えとる。「ユーザは絶対触っちゃだめ」な、事実上
実装の一部を外出しにしただけ、という状態だからな。

771:デフォルトの名無しさん
05/10/16 14:25:10
StrutsのActionとURLとJSPとFormの関係は、設定じゃないだろ、みたいな。

772:デフォルトの名無しさん
05/10/16 16:28:10
>>771
だったらコード中に書けばいいの？これって

773:デフォルトの名無しさん
05/10/16 17:40:41
>>772
そういう問題があったから、アノテーションという構文が拡張されたわけだ。

774:デフォルトの名無しさん
05/10/17 01:30:00
>>767
お前みたいな奴が一番邪魔だ。プログラムを多く書かないと良いシステムができないと考えてる奴
業務アプリケーションの理想はプログラムレスだろ

775:デフォルトの名無しさん
05/10/17 07:45:30
>>769
じゃあプログラマにJavaのソースコード中にハードコーディングさせて、
実装の方針は事前にドキュメント化して、サンプルとか作ってあげて、
それを周知徹底させて・・・を毎回のプロジェクトごとにやって、
いざ実装をはじめたらリーダーやアーキテクトはそれを管理したり
レビューしたり、修正させたりのほうが劇的にコストを減らせるってこと？

776:デフォルトの名無しさん
05/10/17 18:32:41
>>775
で、Strutsのあの定義ファイルでその問題は解決できてるとは思えんが

777:デフォルトの名無しさん
05/10/17 21:22:05
>>776
Struts使わないともっとひどいことになる。
またはStrutsに期待しすぎ。
またはおまえさんのいるプロジェクトのアーキテクトが糞。

778:デフォルトの名無しさん
05/10/17 21:42:20
>>777
Strutsの設定ファイルに書く内容を個別のファイルに書けるようになってたほうがいいってのとは別の話。
「設定外だし」がどうなのかって話題だ。

779:デフォルトの名無しさん
05/10/18 02:20:36
EJB3、Hibernate Annotations、Seasar2.3等を見てると
メタデータを目印として、今までXMLに定義していたような処理はフレームワーク側が自動的にやってくれるような
方向に進んでいくと思う。
JSFだと、ManagedBeanの設定記述などはいらなくなって、faces-configには画面の遷移だけを記述する、みたいな

780:デフォルトの名無しさん
05/10/18 07:52:12
>>778
そこが問題になるってことは、せっかく用意された仕組みを使えてないってだけだな。
やっぱりアーキテクトが糞だ。

781:デフォルトの名無しさん
05/10/18 12:37:08
>>780
は？おまえ全然話題についていけてないよ。

782:デフォルトの名無しさん
05/10/18 12:45:56
StrutsでもXDocletなりアノテーションなり、定義ファイルを気にしなくていい仕組みはあるわけだからな。

783:デフォルトの名無しさん
05/10/18 14:15:44
>>777
ところで、Struts使わないとほんとにひどいことになるか？

784:デフォルトの名無しさん
05/10/19 07:29:15
基礎的な質問ですみません。
JSFでたくさんの画面数、処理数があった場合、
face-config.xmlは処理分だけどんどん長くなるのでしょうか？

785:デフォルトの名無しさん
05/10/19 07:38:26
>>784
そりゃそうだ。
複数のファイルに分けて書くこともできるが、トータルの量は増えるに決まってる。

786:784
05/10/19 08:58:53
と言う事は、大規模プログラムに向かないと言う事？
かなり長くなり過ぎて、遷移に関してはかなり管理しにくくなってきたんですが・・・(´・ω・`)

787:デフォルトの名無しさん
05/10/19 09:29:18
長い=大規模に向かないってのがよくわからん

788:デフォルトの名無しさん
05/10/19 10:25:15
ストラッツよりかなり長くなる気がして・・・
そうなると管理、修正とかしにくくないですかね？

789:デフォルトの名無しさん
05/10/19 10:56:33
もしかして<navigation-case>の要素を全部指定してるとか？
記述ルール決めて省略できる所は省略しちゃえばいいんじゃない？

ちなみにちゃんと記述ルール決めておかないと、そのうち
「ルールのマージエラー」とか出てワケワカ状態に陥るからね。
（自戒込み）

ちなみにオレは<from-outcome>と<to-view-id>だけで管理を
するのが好き。規模小さいからこれだけで出来るのかもしれんが。

790:デフォルトの名無しさん
05/11/11 13:40:47
JavaOne行ってきて、聞いたんですがCreatorが無料になったみたいだね

791:デフォルトの名無しさん
05/11/11 15:04:00
JSFのUIコンポーネントってVBみたいに、コントロールのLostFocusとかのタイミングでリクエスト出せるの？

792:デフォルトの名無しさん
05/11/12 01:15:03
>>791
いやそもそもつかいにくくて、そんなことを考える余裕すらない

793:デフォルトの名無しさん
05/11/12 01:19:30
>>791
そういうUIコンポーネントを作ればできる。
どっかのベンダーが作ってるかもしれない。

794:デフォルトの名無しさん
05/11/17 00:58:52
実際の案件でオールJSFとか使った人いる？
もうそーゆーレベルで使われ出してたりするのかな？

795:デフォルトの名無しさん
05/11/17 10:33:56
>>794
使った。まだ時期尚早だと感じた。
Java EE5対応の開発環境が各社から出そろって
各製品がバージョンアップが一回ずつぐらい行われた頃になると
ほどよく成熟して足並みもそろうのだと思う。

796:デフォルトの名無しさん
05/11/17 11:19:38
Oracleが一番早く対応しそうだな。
WebSphereとWebLogicはもうちょっと先になるかな？

797:デフォルトの名無しさん
05/11/17 14:53:10
>>796
今使ってるOracleのAP鯖、ず～っと気に食わなかったけど、
今回初めてこれにしといて良かったなとオモータよ。
JSFもそうだけど、EJB3.0のRI向けにTopLinkを放出したのは
正直Oracleを賞賛したい。Hibernate対抗措置だったのだろうけどね。

早く来い来いEJB3

798:デフォルトの名無しさん
05/11/17 23:29:24
EJB3.0ってそんなに便利なの?

799:デフォルトの名無しさん
05/11/17 23:41:07
>>798
ふたを開けてみないとわからないのが正直なところ。
Hibernateで充分な気がするし。
というか、persistence API でコード書いておけば
EJB3かHibernateかなんてあまり関係ないしね。

EJB3がどうのというより、各ベンダの実装で性能や使い勝手が左右されると思うよ。

800:デフォルトの名無しさん
05/11/17 23:45:58
しかしEJB3.0にはとてつもないポテンシャルを感じさせるのは確かだ

801:デフォルトの名無しさん
05/11/17 23:56:41
ジェロニモはEJB3か？っつかジェロニモってあるのか？

802:デフォルトの名無しさん
05/11/18 00:02:51
DIコンテナってみんな独自だったのがEJB3という標準化によって
どこのアプリ鯖使っても動くようになるってのは割と大きいよ

803:デフォルトの名無しさん
05/11/18 00:09:42
EJB3って、HibernateとTopLinkにちょっとでも互換性を持たせるための仕様じゃないの？

804:デフォルトの名無しさん
05/11/18 00:51:41
EJB3はDIコンテナとしては中途半端だと思う。EJBをDIするぐらいしか出来ないし

>>803
その２者を使ってO/Rマッピングの標準を作ったということじゃないだろうか

805:デフォルトの名無しさん
05/11/18 00:56:08
>>795
レスありがとー。
やっぱまだ時期尚早かぁ。

URLﾘﾝｸ(file1.grp.yahoofs.jp)

↑こことか見るとサーバーリソースも現行のWebアプリより食いそうだし、
こなれてきてもWebアプリは全部JSF！みたいにはならないかもなぁ。

806:デフォルトの名無しさん
05/11/18 01:13:55
>>805
アーキテクチャや思想としてはStrutsよりもかなりいい感じなんだけどね。
もうちょっとこなれて欲しい。
これからの進化に期待。

807:デフォルトの名無しさん
05/11/18 12:54:20
Sun Java Studio Creatorで業務した人いる?
なんか使った感じ、かなり便利だった。

808:デフォルトの名無しさん
05/11/18 13:18:10
JDevelopperもSun Java Studio Creatorも
どっちも便利だな。
残念ながら、Eclipseには相当する機能は現時点ではないしな。

809:デフォルトの名無しさん
05/11/19 18:12:32
結論：Sun One >>>>>>>>> Eclipse

810:デフォルトの名無しさん
05/11/19 22:17:15
>>805
見れないんだけど、何が書いてあるの？

811:デフォルトの名無しさん
05/11/20 01:17:28
>>810
ごめん。家のPCでYahooにログインしっぱなしだったからそのまま貼っちゃった＾＾；

URLﾘﾝｸ(groups.yahoo.co.jp)

ここのブリーフケースの中にあるJSFTips.htmlってファイル。

よくわかるJavaServer Facesのしくみ
URLﾘﾝｸ(www.amazon.co.jp)

↑の本書いてる吉田裕之って人が書いたJSFのTIPS集。
結構詳しいからJSF使うなら読むといいんじゃないかな？

で、ここに「JSFはサーバーパワーが必要」って項目があったんで、そんなんで実際の現場で普及すんのかな？と。

812:デフォルトの名無しさん
05/11/20 01:36:39
>>811
さんきゅ！

813:デフォルトの名無しさん
05/11/20 04:28:42
>>811
サーバーパワーなんか、ヒューマンリソースに比べれば二束三文

814:デフォルトの名無しさん
05/11/20 04:31:56
実際の実行環境は、パワーあるマシン使うのが普通なので問題ない

815:デフォルトの名無しさん
05/11/20 13:47:52
何Wくらいのがお薦めですか？

816:デフォルトの名無しさん
05/11/20 13:50:19
1.21ジゴW

817:デフォルトの名無しさん
05/11/22 20:59:34
死亡したのは.netではなくstrutsだな。

818:デフォルトの名無しさん
05/11/22 21:42:24
>>817
struts現verの死滅は確実。（と、struts開発元も公言）

shaleがどうなるのか見ものだね。

個人的にはshaleは「出しゃばりすぎ」との予感してる。
shaleを『軸に』システム組むなんて発想は真っ平ゴメン!!
P層のフレームワークは純粋にviewを構築するパーツで
あって欲しい。

その点、JSFは、いいセンスしてると思う。実装がこなれて
いなくて使い辛いのは認めるけど。

勘違いだったらｽﾏｿ

819:デフォルトの名無しさん
05/11/22 22:34:29
>>818
全面的に同意。
（今の）Shaleは覚えることが大杉。使いこなすのが恐ろしく難しい。
JSFとChainとSpringとTilesと・・・と多数のフレームワークやライブラリの
使い方を全部マスターする必要があるんじゃないのか？と思うぐらい。

JSFそのものは思想・アーキテクチャとしては優れているね。
実装と開発環境がもう一皮むけるのを心待ちにしているよ。

820:デフォルトの名無しさん
05/11/23 12:32:42
>>802
実際はそうなるんだろうな。
純粋なスペック面ではDIやってる連中にはヌルすぎと批判されてるが。
こないだのJavaOneでSeasarの人とか。

821:デフォルトの名無しさん
05/11/23 14:04:45
>>820
Hibernate等のO-Rマッピング技術もまったく同じことだね。
Java Persisence APIによって標準化され、どこでも同じAPIで
どこでも同じように動くようになる。

822:デフォルトの名無しさん
05/11/23 14:22:30
JSP/servletとかと同じだよな
結局よほどじゃないかぎりライブラリやフレームワークに依存したコードは書きたくない

JSFに関してはもうちっとなんだろうけど
creater２見る限り開発は問題なさそうだが
運用環境が頭痛いか

823:デフォルトの名無しさん
05/11/24 02:27:49
creater２いいとかいうが
あの自動生成のソースが気持ち悪くて最悪なので
どうしても使う気になれない。

824:デフォルトの名無しさん
05/11/24 23:34:54
コンパイル後のバイナリが気にならないように、
自動生成のソースの中身を気にならなくなる時代が来るのかもな。

825:デフォルトの名無しさん
05/11/24 23:38:28
自動生成部分はいじらないのが普通だろ
GUIエディタでもそうだし

826:デフォルトの名無しさん
05/11/24 23:39:01
>>824
そう思う。
アセンブラなどをやっていた人間からするとJavaが既にそういう存在だと思うし。

827:デフォルトの名無しさん
05/11/24 23:48:53
つーか、コンパイラとかアセンブラ自体がすでに（ｒｙ

828:デフォルトの名無しさん
05/11/25 09:43:37
>>826
アセンブラやってた人間ならCの時点ですでに悲鳴上げたことあるだろｗ

829:デフォルトの名無しさん
05/11/25 15:12:41
開放感でうれしかったけど。

830:デフォルトの名無しさん
05/11/25 23:25:23
Cコンパイラが生成したアセンブラソースのことじゃね？

831:デフォルトの名無しさん
05/12/04 09:48:27
開発ツールSun Java Studio Enterprise 8、無償でリリース－＠IT
URLﾘﾝｸ(www.atmarkit.co.jp)

タダで使えるようになったみたいだけど、これのJSF機能ってどうなの？
楽チン？

832:デフォルトの名無しさん
05/12/04 11:49:07
>>831
JSFに特化するなら、Creatorのほうがいいかも

833:デフォルトの名無しさん
05/12/04 13:11:08
>>831
JSFに特化かどうかというよりも、その両製品は対象ユーザが違う。

JSFのAPIを隠蔽して、完全にグラフィカルな作業環境で開発したい
→Creator
APIなどをある程度把握して、自分で好きに実装したい
→Sun Java Studio Enterprise

どんなコードを生成してくれても気にしない。そのかわりにお手軽開発というのならCreator。
そのかわり、大規模アプリケーションを何人ものプログラマでコードを共有するのには向いていない。
システム開発屋が扱うというよりも、ユーザ企業の担当者がちょっとした
マスタメンテツールや情報検索ツールを作るのに向いているし、そういうユーザがターゲット。

834:831
05/12/04 13:59:46
>>832
>>833

レスありがとう。

だとすると、業務で使うとしたらメインはやっぱJava Studioの方になるのかな～。
Createrはちょっとしたツールとか書く時にはロジックに集中できて便利そうね。

ちなみにダウンロードサイトが英語だったりしてイマイチよく分かってないんだけど、
この2つの「無償」ってのは、商用利用も含めて「無償」で使っていいよ、ってこと？

それとも個人利用の制限あり？？

835:デフォルトの名無しさん
05/12/16 13:57:57
いつの間にか facelets1.0.4がreleaseされてますよ。
URLﾘﾝｸ(facelets.dev.java.net)
誰か人柱になってくれんかのぉ。

836:デフォルトの名無しさん
05/12/16 19:38:38
>>835 人柱よろｗ

837:デフォルトの名無しさん
05/12/18 02:29:30
Oracle、ApacheにJSF実装「ADF Faces」を寄贈へ
URLﾘﾝｸ(pcweb.mycom.co.jp)

838:デフォルトの名無しさん
05/12/18 21:19:55
通常のリンクで<to-view-id>にフォワードするのに<from-outcome>に指定した文字列を使いたくて
<f:view>
<h:form>
<h:commandLink action="link">
</h:form>
</f:view>
と書いてます。
これをもっと簡単に書く方法はありませんか？

839:デフォルトの名無しさん
05/12/18 22:55:32
充分に簡単だと思うけどな・・・・

840:デフォルトの名無しさん
05/12/18 23:04:59
JSFじゃなければ<a href="link.jsp">で済むので、簡単だとは思えません。

841:デフォルトの名無しさん
05/12/18 23:48:26
GET受け付けないから無理

842:デフォルトの名無しさん
05/12/19 01:09:04
f:viewは仕方ないにしても、h:formが必要ない書き方って標準でないんでしょうか？

843:デフォルトの名無しさん
05/12/19 07:45:39
ASP.NETのパクリ成功した？

844:デフォルトの名無しさん
05/12/19 11:51:21
もう一息です

845:デフォルトの名無しさん
05/12/19 12:40:11
JavaEE5出てから本格始動だろうな

846:デフォルトの名無しさん
05/12/19 13:00:46
>facelets

これ、素のHTMLのTableタグをdatatableとかpanlegridに置き換える方法が判んない。

847:デフォルトの名無しさん
05/12/19 19:32:55
>>840
じゃ、おまいには無理だ

848:デフォルトの名無しさん
05/12/20 23:56:04
>>837
これでJSFにも勢いつくといいね。

＞100を越えるJSFコンポーネントから構成されており

結構すごそう。
誰かもう触った人いる？

849:デフォルトの名無しさん
05/12/24 08:25:58
ちょっと試してみた。
tomahawkのように他のJSF実装と組み合わせて使う方式だから簡単に試せると
思ったが、子要素の解釈が結構違っていてかなりの書き換えが必要になりそう。
Sun RIだと子要素にHTMLタグを記述してもほぼそのまんま期待通りに動作
するけど、ADFはほとんど全滅。同等のJSFタグに置き換えるか、verbatimで
囲む必要があった。
一方でJSF標準はjstlとの併用がまったく考慮されていないのが不満だったけど、
ADFでは独自にforEachやswitcherなどを用意してくれているのがありがたい。
forEachはまだいろいろ制約があるみたいだけど。

850:デフォルトの名無しさん
05/12/24 11:49:00
JSFも1.2はJSTLと併用できるみたいね。

851:デフォルトの名無しさん
05/12/24 12:12:21
>>849
＞Sun RIだと子要素にHTMLタグを記述してもほぼそのまんま期待通りに動作
するけど

ものによる。

この問題を解決するために、JSF1.2/JSP2.1ではJSFタグに${...}を記述できるようになる。
${...}は即時解釈（通常のJSPと同じタイミング）され、
#{...}はレスポンス描画フェーズで解釈される

・・・だそうだ。JavaOneでCraigとYUTAさんがそう言ってた。

852:デフォルトの名無しさん
05/12/26 10:54:37
求む人柱
URLﾘﾝｸ(www.alphaworks.ibm.com)

853:デフォルトの名無しさん
05/12/27 01:40:08
人柱って、、、試したところで何のデメリットもないんだから手前で試せよ。

854:デフォルトの名無しさん
05/12/27 09:30:17
環境が無いんだよ

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と同等もしくはそれ以上の機能を有していると勝手に解釈しちゃってるが。
エンジニアさんが周りにいないので素人っぽい内容でｽﾏﾝｺ

次ページ