JSF(JavaServer Faces)2 - 暇つぶし2ch

JSF(JavaServer Faces ..

464:452
07/11/24 11:22:08
>>458
>あなたはJSFを使う事も出来れば、使わない事もできる。
使うと決めた人しか質問しちゃいけないわけじゃないよね。JSFを勉強している中での質問なので、使う使わないの判断は関係ないと思う。

>>459
すでに>>457に書いてるけど、前の入力データが自動的に今のページに含まれることがセキュリティ的にまずいと思う。
登録完了ページにアカウントやパスワードのデータが残っていたらまずくない？

>>460
>RESTとJSFは絶望的に合わないと思う
>HTTPを基礎とする志向に対し、HTTPを隠蔽するFWだから
そうなのかな。HTTPを隠蔽するしないは関係あるんだろうか。

>>462
>そのcgiってのは入力項目の変更があった場所とかに応じて自動的にバリデータとかイベントでのプログラミングできるの?
462がどういうのを想像しているのか分かんないけど、自動的にバリデータがかかることと今回の質問とは関係があるの？
自動的にバリデータかかったりイベントベースでのプログラムが書けることと、URLやセキュリティのこととは関係なくない？

>>463
>JSFを使う様な場面でブックマーク使うなんて事ない思うが。
>ログインページやトップページ以外でブックマークされても困るケースの方が
>ほとんどだろうし。
だったら、URLをかえないか、ランダムなURLにすればいいと思う。
今のJSFの挙動だと、ユーザに大きな誤解を与えるだけにしか見えない。
とりあえずブックマークを許したいならJSF使ったらダメということでFA？

>そしてURLと画面が一致しないのはあんま気にならないと言うか
>誰が気にするんだ？って思う。
気にしない開発者がいることにびっくりだ。世の中はひろい。

465:デフォルトの名無しさん
07/11/24 11:42:55
>>464
>そうなのかな。HTTPを隠蔽するしないは関係あるんだろうか。
あくまで私見だが、とても関係あると思っている。
たとえば、JSFで作った画面のHTMLソースを見ても、
サーバのどのManagedBeanメソッドが呼び出されるかはなかなかわからない
その時点で、URLとHTTPメソッドで呼び出し先が決定されるREST的Webアプリとは
根本的に違うし、当然ブックマークの常識も通用しない
だから通常のWebアプリの常識で考えるとありえないって結論になる。
個人的にはJSFのこの仕組みは嫌いだが、仕事で使っている以上一通り勉強している。

466:デフォルトの名無しさん
07/11/24 13:51:47
>気にしない開発者がいることにびっくりだ。世の中はひろい。

このスレじゃないしJSFでもないけど、
「それじゃユーザーが混乱するのでは？」みたいな書き込みしたら
そもそもなんでそんなこと気にするのかわからないっていうレスばかりで
自分もビックリしたことがある。

とにかく「自分の責務の範囲外のとこは関与しない」っていう文化が浸透してるみたい。

467:デフォルトの名無しさん
07/11/24 14:25:21
関東はその傾向が強いね

468:デフォルトの名無しさん
07/11/24 14:29:32
>>464は>>461を無視かよ
解決方法のポインタしめしてるのに

469:デフォルトの名無しさん
07/11/24 14:33:51
＞だったら、URLをかえないか、ランダムなURLにすればいいと思う。

どっちも出来るはずだから喪前が好きに実装すればいいのでは？

＞今のJSFの挙動だと、ユーザに大きな誤解を与えるだけにしか見えない。
＞とりあえずブックマークを許したいならJSF使ったらダメということでFA？

なぜにそんな極論になるのか知らんが、ユーザーに文句言われて
喪前の技量ではどうしようもないなら、そうすれば？

＞たとえば、JSFで作った画面のHTMLソースを見ても、
＞サーバのどのManagedBeanメソッドが呼び出されるかはなかなかわからない

ソース見て、どのBeanが呼び出される方が解る方が大問題だろ。

仕事で使っているとか言いながら、持論は壮絶にアマチュア精神丸出しだな。

470:デフォルトの名無しさん
07/11/24 14:40:51
>そもそもなんでそんなこと気にするのかわからないっていうレスばかりで
>自分もビックリしたことがある。

そりゃ、底辺のマにありがちな「どーでもいい事は熱心クセに
実際の生産・成果物がショボイ」って上の方が辟易している状態だろ。

471:デフォルトの名無しさん
07/11/24 14:41:01
Railsだって勝手にブックマークされるとまずい・・・っていうか問題ある場所なら
セッションなかったら入り口に戻すとかするだろうと

472:デフォルトの名無しさん
07/11/24 14:42:06
>>452は全てにおいて勘違いしてるな

473:デフォルトの名無しさん
07/11/24 14:52:03
気になる奴はREST志向が強いだけで結論付いてるじゃん。
JSFにとってURLはイベントメッセージ、RESTにとってURLはコマンドライン引数。
普通のアプリケーションとなんら変わらないと思うんだが。

474:デフォルトの名無しさん
07/11/24 14:52:39
しかし、そんなに入力データ云々言うならセッションに入れとけよ、って思うんだが
なんで、病的にフレームワークの性にしているんだ？

475:デフォルトの名無しさん
07/11/24 14:55:54
>>473
しかもredirectいれとけばURLベースと動きがかわらんのにな

476:デフォルトの名無しさん
07/11/24 15:02:07
でもURLって重要だよね。
ブックマークや検索エンジンのインデクサに登録されたら
もう基本的に自分のところではコントロール不能で面倒だし。
半永久的にリダイレクトとかのフォローしないといけなくなる。

あとフィッシングサイト対策とかブラクラなんかの影響で、ユーザーも
ブラウザのアドレス欄に表示される文字列に気にするようになってると思うし。
できれば短ければ短いほうがいいよね。

477:デフォルトの名無しさん
07/11/24 15:11:02
servletでいうdomain/context/servletまでが分かれば、
それ以降に何が付こうがどうでもいいんだが。

478:デフォルトの名無しさん
07/11/24 16:58:38
>>476
自作自演乙

479:デフォルトの名無しさん
07/11/24 17:06:32
そんなにヤならJSF使わなきゃいいじゃん。

上司に2chのこのスレ見せて「漏れが452です！漏れの言っている事正しいですよね！」
って力説すれば、上司は快くオマエをプロジェクトから外してくれるだろうから、
嫌なJSFを使わなくてすむぞ。w

480:デフォルトの名無しさん
07/11/24 17:09:30
そおいや、検索エンジンって拡張子が.jspやらjsfは拾わない気がしたんだが、
どこぞのエンジンは拾うのか？

481:デフォルトの名無しさん
07/11/24 17:33:00
>>480

inurl:index.jsp - Google 検索
URLﾘﾝｸ(www.google.com)

inurl:index.jsf - Google 検索
URLﾘﾝｸ(www.google.com)

拾いまくり

482:デフォルトの名無しさん
07/11/24 18:40:08
googleの結果だと別にurlとられても問題ないケースに見えるんだが
452はナニが不満なんだ？

483:デフォルトの名無しさん
07/11/24 18:47:43
末端の仕事してる者同士仲良くしろ

484:デフォルトの名無しさん
07/11/24 19:07:26
>>482
それはindex.jsfだから。
.jsfで検索するとカッコ悪いURLたくさん出てくるよ。
そもそもJSFがあまり使われてないから探すの面倒くさいけど。

485:デフォルトの名無しさん
07/11/24 19:10:08
URLﾘﾝｸ(www.google.com)

なんかここ無茶なことやってるなあ・・・

486:デフォルトの名無しさん
07/11/24 19:14:12
まだ潜伏してんのかｗ

487:デフォルトの名無しさん
07/11/24 19:22:22
何が理由で工作してるんだろう・・・

488:デフォルトの名無しさん
07/11/24 19:30:19
Servlet自体はRESTのことちゃんと考えて規格を調整してきたし（HTTP METHODあたり）
各WebコンテナベンダもCometに対応できるようにコンテナを改造している。
JSFに粘着しないで他をあたればいいのだよ

489:デフォルトの名無しさん
07/11/24 20:01:19
URLがどうのって奴はフォワードを一切許容しないってこと？
JSFに限らずほぼすべてのservletアプリケーションがダメってことじゃん。

490:デフォルトの名無しさん
07/11/24 21:00:52
servletにすら限らないけどな
POST先をどこにするかだけの話だから

491:デフォルトの名無しさん
07/11/24 22:27:31
452は今までどんな環境でWebアプリ作っていたのか気になるな。
servletやRailsを知らんのは明白だし。

492:デフォルトの名無しさん
07/11/24 23:08:16
>>475
JSFのリクエスト保持データってredirectで引き継がれたっけ？
TeedaやRailsなら対応してるけど、素のJSFはforward前提のFWだという認識だったのだが

493:デフォルトの名無しさん
07/11/24 23:14:12
>>492
Servlet直、Struts、SpringMVC
ともに処理はRedirect前にやるからredirect後特殊な処理をしたいのなら普通にsessionからとりだすんでそ？
redirect先でリクエスト使うって処理はどのフレームワーク使ってもないよ

494:デフォルトの名無しさん
07/11/25 01:14:46
>>489
> JSFに限らずほぼすべてのservletアプリケーションがダメってことじゃん

どういう極論だよ。
redirect-after-postでやってるWebアプリなんて普通にあるじゃん。

495:デフォルトの名無しさん
07/11/25 01:54:42
常に一つ前の状態がほしければセッションビーンにリクエストビーンのセッターゲッター用意して上書きさせればいいだけ

496:デフォルトの名無しさん
07/11/25 07:47:56
>>493
ここ読んでると、みんな普通にJSFでredirect使ってるんだね。自分の勉強不足だったのか

普通のWebアプリだと、例えばPOSTで登録したあとそのデータを表示する為に
IDをパラメータ（かURL）で渡して詳細データを検索するURLにGETでredirect
みたいなことが普通に出来ると思うけど、JSFの場合どうやったらいいんだろう
session使えばいいのはわかるんだけど、
URL使うパターンでは手動での画面操作を介さない限りsessionって使わなくてもいいので
できるだけsessionには保持したくない

497:デフォルトの名無しさん
07/11/25 08:10:10
＞ここ読んでると、みんな普通にJSFでredirect使ってるんだね。自分の勉強不足だったのか

ナニがどうあっても個人の異端な思考を「普通」と思い込みたい病人みたいな台詞だな

498:デフォルトの名無しさん
07/11/25 08:37:25
だからURLに文句がある奴はJBossSeam使えよ。
JavaEE6で標準仕様になるんだし。

499:デフォルトの名無しさん
07/11/25 08:37:30
>>497
ん？なんでそんな敵意むき出しなの？
ちなみに>>452とは別人だぞ

500:デフォルトの名無しさん
07/11/25 08:39:52
>>498
素のJSFでは駄目ってこと？
SeamはステートフルSessionBean使いまくりってイメージがあったので敬遠していたのだが
そういや最近のバージョンはEJB3への依存が消えたんだっけ？

501:デフォルトの名無しさん
07/11/25 09:52:38
素のJSFってどこのJSF使ってんだよ。
仕事とかいいつつ趣味でやってんじゃねーのか？
このURL粘着君は。

仕事で商用鯖使ってんなら2chでなくてサポートに泣き付けよ。

502:デフォルトの名無しさん
07/11/25 10:20:41
>>501
MyFaces1.1系
自分が調べた限り、JSFのredirectはManagedBeanのメソッドを呼ぶような使い方が出来ないので
使い物にならないという結論を出していた。
でもこのスレでredirect使えばOKというレスが多かったのを見て
>>496の質問をしただけだよ
URL粘着って>>452あたりの話か？自分じゃないんだけど・・・

503:デフォルトの名無しさん
07/11/25 12:17:54
>>496
「普通のWEBアプリ」ってなんだよと思う
URLにパラメータをまったく乗せたくないからセッションに入れるという場合だってあるんだぜ？

504:デフォルトの名無しさん
07/11/25 12:48:10
ショッピングモールみたいなサンプルアプリ的なものは典型的だな。

505:デフォルトの名無しさん
07/11/25 13:38:24
まぁURLベースの典型ではあるが、用途によって最適解が違うというのも>>452は気がついてるんだろうか

506:デフォルトの名無しさん
07/11/25 14:53:03
なんかURL粘着が必死に他人のフリしているから話がややこしいよな。
やたら別人を強調しているし。

>>452の望む動作はJSFでも実装可能なのに、なんか必死に出来ない事にしたがって
「普通のWEBアプリ」って脳内理想をブチまかれてもな。

嫌なら使うなよ。

507:デフォルトの名無しさん
07/11/25 15:05:07
JSFのHTTPの使い方がRESTfulでないのもがいしゅつ。
とにかくMVCが偉かった時代の産物だからな。
頭を切り替えろと。

いまJSFが一番お勧めな用途ってのも思いつかない。

508:デフォルトの名無しさん
07/11/25 15:09:16
cgiの時代に戻っとけ、って事でFA

#漏れは戻りたくないが

509:デフォルトの名無しさん
07/11/25 17:07:38
>>507
JSFはJavaのフレームワークで一番イベントベースでの処理と入力検証が一番容易だから
開発効率と安定性を追求したい場合いいんじゃない？

510:デフォルトの名無しさん
07/11/25 18:55:57
>>509
その入力値検証が
>>411 >>417 >>420
という体たらくだからな。
JSFのバリデータをベースに作り込もうとしたら
保守不可能なシロモノができあがる。

NetBeansでポトペタできるのはメリットかな。

511:デフォルトの名無しさん
07/11/25 19:16:20
項目ごとにエラーメッセージを分ける必要があるなら
UIコンポーネントのIDかClientIDで分けるようにすればいいのでは？
エラーメッセージはResourceBundleから読み込むようにして
ResourceBundleのキーにUIコンポーネントのIDかClientIDを含ませるようにするとか。

512:デフォルトの名無しさん
07/11/25 19:34:59
>>510
今はJSF1.2の時代なのにいまさら1.1の話されても・・・
NetBeans使ってるならなおさらだろと

513:デフォルトの名無しさん
07/11/26 02:00:12
>>506

＞嫌なら使うなよ

Youは使ってるものに不満点って全然ないのかい？

514:デフォルトの名無しさん
07/11/26 02:17:58
JSFの特性からしてREST, POHP, c10kには向かないから、使い分けは必要だよ。
そういう方面は、Struts+Springとかになるんじゃないか？

515:デフォルトの名無しさん
07/11/26 08:38:52
>>513
所詮はJSPの上に成り立っているフレームワークなので
JSFで出来ない部分はJSP時代のノリに戻るだけ、って希ガスので、
不満があるなら、自分で作って解決するけど。

つか、URLでグダグダ言う「客」にはあった事ないんだが。

あと、NetBeansのJSFはそんなに使いにくいのか？
漏れはWebSphereのJSFなのだが、
バリデータの作りこみでそんなに苦痛に感じないが。

516:デフォルトの名無しさん
07/11/26 09:09:25
Rails見てると、JSFと完璧真逆なんだよな
あちらはREST志向、ステートレスで極力サーバにユーザステータスを持たない
ってのを強調してる
JSFはサーバサイドがフルコントロールするイベント志向というイメージ
どっちが古いかと言われたら正直JSFの方が古いと思うけど、
少人数対象アプリを素早く作りたい時はJSFの方が早いのではとも感じる

517:デフォルトの名無しさん
07/11/26 12:29:06
>>515
>つか、URLでグダグダ言う「客」にはあった事ないんだが。
お前の偏ったキャリアを一般論に摩り替えるなよｗ

518:デフォルトの名無しさん
07/11/26 14:51:28
>>515
使いにくくはない
アンチががんばってるだけ

519:デフォルトの名無しさん
07/11/26 14:56:28
>>516
Restful指向っていわゆる昔のPerl全盛期の時代とかわらんぞ

IDE側でのサポートを前提としない場合、URLがすべてのソース参照の起点だから
そういう方法がベストだというだけ

それにユーザーステータスをできるだけ持たないといってもロジックが絡まない参照だけでしょ?

Railsがいいという人は初期のServlet/JSPのシンプルさに戻ればいいだけだと思うのだが

520:デフォルトの名無しさん
07/11/26 19:43:42
> 初期のServlet/JSPのシンプルさ

ポトペタできないしー。

JSFはポトペタ対応でああいう設計になってると理解してるんだが。
ポトペタしない、ポトペタが無意味なくらい作りこむなら
JSFを使う意味はないんでは？

521:デフォルトの名無しさん
07/11/26 19:55:55
ポトペタってなに？

522:デフォルトの名無しさん
07/11/26 21:06:11
しかし、ここまでアンチが必死になるのもよーわからんな。
んなに嫌ならStruts+SpringかRailsに行けよ、で話が終わるのに
しつこく粘着する精神がわからん。

まあ、そういう提案も出来ないくらい底辺のマなんだろうけど。

523:デフォルトの名無しさん
07/11/26 21:13:19
>>520
JSFとASP.NET以外でぽとぺたが機能してる例はまずないな

Railsがうけてるのはポトペタが出来るかどうかじゃないでしょと

524:デフォルトの名無しさん
07/11/26 21:24:06
>>523
＞JSFとASP.NET以外でぽとぺたが機能してる例はまずないな

europa + WTP2.0 をさわったこともないだろ。

525:デフォルトの名無しさん
07/11/26 21:47:38
>>524
JSF部分ではなくて通常のHTMLの話か?
それはポトペタとはいわないのだが

526:デフォルトの名無しさん
07/11/26 22:36:37
要するにJSFの方向性ってWeb標準から乖離してるってことでFA？

527:デフォルトの名無しさん
07/11/26 22:45:36
ポトペタの定義をよろしく。

528:デフォルトの名無しさん
07/11/26 23:13:59
ツールパレットからWidgetをドロップ
Widgetをダブルクリックしてハンドラーをごりごり
ってことじゃない？

529:デフォルトの名無しさん
07/11/26 23:18:02
＞要するにJSFの方向性ってWeb標準から乖離してるってことでFA？

アンチが必死だなｗ

530:デフォルトの名無しさん
07/11/26 23:21:56
JSFの理想はポトペタと言うか、デザイナとプログラマの分離なんだろうな。
現実的にはデザイナ＝プログラマなんだろうけど、なるたけ簡単に
ってのは感じる。

で、FWに沿わない事をやりだすとﾏﾝﾄﾞｸｾになる。
しかし、そりゃStrutsやRailsも同様だけどなー。

531:デフォルトの名無しさん
07/11/26 23:29:52
なんで最近急にアンチがあらわれたの？
過疎がすさまじいスレだったのに

532:デフォルトの名無しさん
07/11/27 02:56:21
自分の意見に賛同が得られなかった事による逆恨みでしょ
ガキすぎる

533:デフォルトの名無しさん
07/11/27 05:36:59
負け組ＰＧ同士なんだから仲良くしろ

534:デフォルトの名無しさん
07/11/27 06:55:32
スレを眺めていると負け組PGなのアンチJSFのURL君に感じるが。
しかも一方的に逆恨みモードだし。

535:デフォルトの名無しさん
07/11/27 09:22:17
まー言われてみれば、JSFの一番根本的な設計思想

・RESTとかｼﾗﾈｰﾖ、静的ページやJSPでの常識は全部捨てろ
・WebブラウザとJSPをハックして、MVCを強引に載っけてる

をきちんと説明した記事って見たことない。
いきなりコンポーネントツリーとライフサイクルで始まる
記事ばっかりじゃないか？

正直、2までのEJBみたいになると思うよ。作り込みすぎてて、
馬鹿にはついてけないフレームワークだ。

536:デフォルトの名無しさん
07/11/27 09:38:02
利口なやつしか使えないんじゃうちでは採用できねえなぁ
バカだろうがある程度のレベルで使えないと意味無いし

537:デフォルトの名無しさん
07/11/27 11:45:39
なんかアンチが必死で笑えるんだが、逆にバカでも使えるのがJSFだと思うけど。
CRUD程度ならservletやSQLの知識ゼロでマウスでポトペタで成果物ができる
のがJSFだろうに。

自分が利口だと思い込んでいるヴァカには不満のあるフレームワークだろうな。

538:デフォルトの名無しさん
07/11/27 13:54:33
JSFはポトペタ開発をするのに我慢しないといけないことが多すぎるんじゃね？

539:デフォルトの名無しさん
07/11/27 14:56:38
>>538
具体的に

540:デフォルトの名無しさん
07/11/27 17:58:06
バカな俺にポトペタがなんだか教えてくれ

541:デフォルトの名無しさん
07/11/27 19:26:38
>>537
> CRUD程度ならservletやSQLの知識ゼロでマウスでポトペタで成果物ができる
> のがJSFだろうに。

困猿みてーなこと言ってんな。
その手の話は全部嘘くせえってか嘘だと見抜けない人は（ｒｙ
専門学校でトイアプリ書いてんじゃねーんだからよ。

542:デフォルトの名無しさん
07/11/27 20:31:09
>>541
できるじゃん

543:デフォルトの名無しさん
07/11/27 20:39:10
>>541
普通にできるんだが。

544:デフォルトの名無しさん
07/11/27 21:11:15
トイアプリならな。

顧客に成果物を見せる→「ここをこうしてよ」→ハマる、
ってパターンが目に見えてる。

545:デフォルトの名無しさん
07/11/27 21:30:29
>544
嘘じゃねーじゃん。
しかも目に見えてるだけかよ。実際にやってから嘘だとか言え。

546:デフォルトの名無しさん
07/11/27 21:40:39
アンチが涙目な反論を始めたな。

547:デフォルトの名無しさん
07/11/27 21:46:27
>>545
やってみたよ。トイアプリ＋αみたいなシチュエーションで。
まさか仕事でぶっつけで使う奴はいないだろ。
「成果物」はお笑いだよ。

548:デフォルトの名無しさん
07/11/27 21:52:34
さすがにJSFでサーブレットやSQLの知識ゼロってありえんだろ

RowSet使おうがO/Rマッパ使おうが楽をするためのものであって
知らなくて言い訳ではない

そもそもViewとDB層の違いもあるし

549:デフォルトの名無しさん
07/11/27 21:57:43
アンチはいったいナニしたいんだろうな。

都合の悪いツッコミはスルーするわ
どうでもいいことに勝利宣言勝手にしてるし。ｗ

喪前は賢い人間なんだろうからservlet+JSPで
ゴリゴリとコード書いてりゃいいじゃん。

550:デフォルトの名無しさん
07/11/28 00:49:33
いまJSFマンセーしてる人はEJBもマンセーしてたタイプ？

551:デフォルトの名無しさん
07/11/28 00:52:52
JSFを使い続けて2年になる俺が着ましたよ。
俺的にJSFはNGっていう結論なんだけど、
OKって言ってる人たちは、どういうドメインで使ってるの？

社内ツールとか作るなら、別にJSFでなくていいし、
インターネットのポータル系だと（俺はこのドメインだったけど）、
状態保持周りで困ることが多い。

JSFが使える（有効な）ドメインを教えて欲しい。

552:デフォルトの名無しさん
07/11/28 01:10:53
>>551
とりあえず一般的なアプリである販売管理ソフトとか作ってみる場合、
JSFが一番まともっぽい

JSFがよくなったのはこの1年くらい
それ以前はほんときつかった

553:デフォルトの名無しさん
07/11/28 01:23:52
社内ツールみたいなイントラネットアプリ作るならJSFの方が良いと思うんだが。
逆にインターネットのアプリならJSFよりもServletに近い方がやりやすいと思う。

つまり551は肉マン

ちゃう、551はドＭ

554:デフォルトの名無しさん
07/11/28 01:52:36
ふと思ったんだけどJavaでのWebアプリ開発って
社内業務ツール：一般向けWebサイト
ってどっちの利用実績が多いの？

JSFは標準技術だけどブックマーク対策とかSEOでいまいち上手くないってことは
社内ツール開発を主眼に置いているってことなのかね？

555:デフォルトの名無しさん
07/11/28 11:08:35
一般に公開されててjavaで作られたまともに動くサイトってどこ？一つか二つ教えて。
駄目なのは遅い上にすぐ利用不能になるビックカメラと無印良品、両方java。

556:デフォルトの名無しさん
07/11/28 11:24:54
>>555
楽天トラベル

557:デフォルトの名無しさん
07/11/28 11:37:51
>>555
ネットバンキング・ネット株式全般。

アンチが必死にブックマーク、ブックマークと叫んでいるが
それらのサイトはURLは意識しない作りになっている。

ちなみにJavaだから遅いのではなくて、大抵はDB鯖を含め全体のチューニング不足がほとんど。
PHPだろうとperlだろうと落ちる時は落ちる。

JSFがNGでRailsがOKと言う意見ならともかく、
代替案もなしに「使えない」と言うヤツは仕事でも「使えない人材」だな。

558:デフォルトの名無しさん
07/11/28 12:32:52
>JSFは標準技術だけどブックマーク対策とかSEOでいまいち上手くないってことは
>社内ツール開発を主眼に置いているってことなのかね？

URL粘着はなにがなんでも上手くないって思い込んでいるらすぃ。

559:デフォルトの名無しさん
07/11/28 13:22:15
シマンテックとかビックカメラ.comとかルーヴル美術館とか
ジュンク堂とか富士通とかNECとかナビタイムとか

まぁいくらでもあるな

560:デフォルトの名無しさん
07/11/28 13:25:02
社内アプリならSwingのほうがいいんじゃないかな

561:デフォルトの名無しさん
07/11/28 13:31:58
>>560
状況次第かな
クライアントを把握できるようなところならそれでいいと思う

562:デフォルトの名無しさん
07/11/28 16:13:02
ビックカメラが使えるってハードルがえらく低くないか
びっくりするくらい遅いぞ。

563:デフォルトの名無しさん
07/11/28 16:20:01
SwingのGUIエディタはNetBeans以外壊滅と思ってたが
そんな話はスレ違い棚。

MyFacesはどうなるんだろうね。迷走してるってか
死の一歩手前って感じだが。

564:デフォルトの名無しさん
07/11/28 16:58:43
>>562
実装次第
あそこはネットの対応も悪いから実店舗にいけ

565:デフォルトの名無しさん
07/11/28 16:59:33
IDEAもがんばってないかい？Eclipseが壊滅してるだけかと。

566:デフォルトの名無しさん
07/11/28 17:02:49
JSF実装は結局RIできまりくさい

567:デフォルトの名無しさん
07/11/28 19:19:26
RI使っている人もいるとは思うが、仕事で使うなら
商用JSF(AP鯖)使うんじゃないのか？
WebLogicなりWebSphereなり。

漏れはIBM関連の鯖で開発するからRIやMyFacesは選択肢に上がらないワケだけど
RIなんかは使いにくいと言うか足りない印象があるが。

568:デフォルトの名無しさん
07/11/28 19:43:01
そういえば将来的にはWebページ以外にも適用させるみたいな話ってどうなった？
JSFの話じゃなかったかも知れないけど。

569:デフォルトの名無しさん
07/11/28 21:34:48
>>567
sunとredhatがRI使ってるよ
ユーザーが多いおかげでかれやすいのが特徴だね

woodstockだけ取り出して使えるようにする予定もあるようだね
他の実装でもweb.uiコンポーネント使えるように

でも、1.2ベースな時点で使うのはツリーとファイルアップロードに制限されるかな
web.uiのファイルアップロードは楽だね
フォームのエンコード方法自動で切り替わる

570:567
07/11/28 21:53:34
>>569
ああ、そりゃSUNはRIだわな。

漏れはWebSphereでJ2EE1.4ベースなIBM拡張JSFだけど、
SDOってO/Rﾏｯﾊﾟｰと一緒くたなパッケージなんで、
ファイルのアップロードとかも昔(1.1以前)から対応していてスゲー楽してた。
しかし移植性は最悪な希ガス。

まあ、逆に商用のダメってところでもないがまだJ2EE5正式版が
ないところかな？
企業はむやみやたらとVerUPしないのでそれはそれでもいいんだろうけど
J2EE1.4が出てからずいぶん経つからなぁ・・・。

571:デフォルトの名無しさん
07/11/28 22:23:50
J2EE1.4とJavaEE5じゃまったく別物だよなぁ
JavaEE5でやっとJSFがはいってUIからロジック、パーシスタンスとオールインワンになったのが大きいかな
あとXMLもほとんど書かないですむし

572:デフォルトの名無しさん
07/11/28 22:52:25
J2SDKとJDKの使い分けもそうだが、Java屋って結構律儀だなって思う。

573:デフォルトの名無しさん
07/11/28 23:26:33
表記をあいまいにしたところでいいことないでしょ
それくらい技術屋はみんなやってるよ
Javaに限らず

574:デフォルトの名無しさん
07/11/29 00:05:32
strutsってなくなるの？

575:デフォルトの名無しさん
07/11/29 00:11:39
無くならないよ。View層だけ変えたいとかいう場合も素直に付け替えられるし、超現役。

576:デフォルトの名無しさん
07/11/29 00:39:12
ちゃんとViewとロジック分離して作っていれば
フロントエンドは何を選択してもいい、となるんだが
EJBとかWEBサービスのように物理的に分かれてないと
なかなかきれいにいかなかったり

Railsはこんなにカンタン！という宣伝にTodoリストの作成あるけど
正直IDEサポートがあればJSF+JPAだともっとカンタンにできあがるよね

577:デフォルトの名無しさん
07/12/03 02:16:37
あ～あ、JSF無条件マンセー派がファビョりだしたから
また過疎スレになっちゃった。

578:デフォルトの名無しさん
07/12/03 11:50:56
またアンチの勝利宣言か。

579:デフォルトの名無しさん
07/12/03 13:44:07
Java関連スレに出てくるアンチ君だとおもう

中学生くらいはそういうお年頃だから仕方ない

580:デフォルトの名無しさん
07/12/04 00:35:03
Ajax使うときのベストな手法って固まってるの？
jMakiとか気になるんだけど、基本的にタグライブラリの中でやりくりするのかな？

581:デフォルトの名無しさん
07/12/04 01:21:07
タグライブラリが全て面倒見るタイプならぽとぺたとプロパティの設定だけでいい
webuiはこっち

でもボタン押したらJavaのこのメソッドをコールとかならDWRとかいわゆる別の入り口作ればいい

582:デフォルトの名無しさん
07/12/07 01:10:15
★FAQ

Q：
RESTがやりにくそうなんだけど？

A：
現在のJSFはいわゆるログイン必須のブックマークを取らないシステムしか考慮されていません。
次のバージョンである2.0でRESTがサポートされる見込みです。

現在の1.2では自前でアクション時にリダイレクト処理をしていくしかありません。
結果、他のアクションベースの開発のようにURLを意識しての開発は生産性がかなり落ちます。

583:デフォルトの名無しさん
07/12/07 06:44:07
釣れますか？

584:デフォルトの名無しさん
07/12/08 21:42:53
>>582
>次のバージョンである2.0でRESTがサポートされる見込みです。

ごめん、これ知らなかったので、ソース教えて。

585:デフォルトの名無しさん
07/12/08 21:55:18
>>584
RESTの仕様であるJSR311サポートするとある
それに伴ってGETも対応させるようだ

数値文字参照がなくなれば標準コンポーネントに関しては携帯電話も動きそうな予感
今の状態だとフルブラウザ使えとかスマートフォンつかえとかになっちまうからね

586:デフォルトの名無しさん
07/12/12 02:23:26
URLﾘﾝｸ(www.itmedia.co.jp)

587:デフォルトの名無しさん
07/12/12 02:38:46
>>586
貼り付けるスレ間違えてるぞ

588:デフォルトの名無しさん
07/12/12 15:51:19
Railsは世の中の流れをうまくとらえてるよなあ。
それに比べてJSFは・・・

589:デフォルトの名無しさん
07/12/12 16:56:17
またアンチ君復活か

590:デフォルトの名無しさん
07/12/12 17:21:54
信者vsアンチか
どっちも頑張れ

591:デフォルトの名無しさん
08/01/25 22:13:11
なんか世界ではJSF+Faceletsが中心になってってるみたいだな。
Web Beans、JSF2.0の乗っかるJavaEE6が、EoDのとりあえずのゴールになりそうだ。
EE5でも十分All-In-Oneで行けるし、今からJavaに来る子は幸せだな。

592:デフォルトの名無しさん
08/01/26 00:30:08
Faceletsだとぽとぺたじゃないから手間が増えるのがガンだよね
JSFはコンポーネントバインディングして何ぼだと思うし

今からさわる子は幸せというのは同意

でも、今でも新規作成でstruts1やってるところも結構見るから運次第か

593:デフォルトの名無しさん
08/01/30 00:49:53
今現在チャットのようなものを作ろうとしてるんですけれど……
普通、form中にinput でsubmitボタンを作れば、他の入力部品にフォーカスが入ってる場合でもエンターでsubmitされますよね？
が、JSFのh:form内でtype=submitのcommandbuttonを作ってもenterじゃsubmitされないようなのです。
これって、なんかプロパティなり設定を変えれば済む話なんでしょうかね。
なんか初歩的なことを尋ねるようで申し訳ない。

594:デフォルトの名無しさん
08/01/30 02:16:44
submitされるかどうかはブラウザ依存だが、
通常リターン押すだけでsubmitボタンがなくてもされるよ

595:デフォルトの名無しさん
08/03/17 01:48:55
Update Model Values の後にValidationしたいんだがどうすればいいんでしょうか？

どうやってコンポーネントのIDとればいいんでしょうか？
Update Model Values の後にValidationするタグとかってどうつくれば・・・

596:デフォルトの名無しさん
08/03/17 01:54:37
なぜそういうことを考えるの?

597:デフォルトの名無しさん
08/03/17 02:24:11
基本的に単体項目による検証ではなく、その他の項目と合わせて判断する必要があるのと
モデルのValidationは作成済みで、その機能をそのまま利用したいからです。

Validationでは基本的に各属性のみの値を使って検証することになりますが、
モデルのその他の設定されている値(プロパティ)も見たいのです。

598:デフォルトの名無しさん
08/03/17 17:34:31
JSFのバリデータは個々の値の検証のみを行うものだよ

複数の検証なら当たり前だけどinvokeApplicationフェーズで行うしかない
ロジック呼ばなければいいだけでしょ？

599:デフォルトの名無しさん
08/03/17 20:47:24
カスタムバリデータ作ればいいじゃない。

600:デフォルトの名無しさん
08/03/18 23:40:31
>>599のいうことは>>597のやりたいことに対してなんにも解決方法になってないんだが

601:デフォルトの名無しさん
08/03/23 02:27:52
>>597の「やりたいこと」が分かってしまう>>600はエスパーか同じ穴の狢

602:デフォルトの名無しさん
08/03/23 06:06:36
ここってGWT-Ext2.0のスレで良かったけか？

603:デフォルトの名無しさん
08/03/23 14:39:19
>>601
エスパーじゃなくても分かるくらいの情報は書いてあるが。
人によって理解度に差があるのは仕方の無いことか。

604:デフォルトの名無しさん
08/03/23 14:50:53
カスタムバリデータ作ればいいじゃん

って俺も思うけどな。

バリデータの階層的呼び出しができないとか
モデル値の参照ができないと思い込んでないか？

605:デフォルトの名無しさん
08/03/23 15:37:28
単に>>597はバリデータの理解度が足りてないだけだと思う
もちろん理解度に個人差があるのは仕方ないことであるｗ

606:デフォルトの名無しさん
08/03/23 16:35:52
メソッドバリデータでいいんじゃね？
どっちにしろ>>597のほしいものとは違ってくるけど

607:デフォルトの名無しさん
08/03/23 20:40:02
モデル値の参照ってどうやるの？

608:デフォルトの名無しさん
08/04/09 03:03:39
結局だれもまともな解答付けられずw

609:デフォルトの名無しさん
08/04/09 13:08:04
だってJSFのライフサイクルにあわないもん

610:デフォルトの名無しさん
08/04/15 00:39:22
UIComponent#getParent()/getChildren()使えば他のUIComponentの値を
参照できるんだからカスタムバリデータで頑張れば解決で終了

611:デフォルトの名無しさん
08/04/15 00:43:19
>>610
モデルでほしいといってるからそれは解決方法にならないだろ
それでいいのなら何をしてもいいことになる

612:デフォルトの名無しさん
08/04/15 01:02:40
>>611
モデルでほしいなんてC/C++のポインタが自動的に割り当てられた
アドレスを指してるってくらい無茶な願望だってことに気づくべき

613:デフォルトの名無しさん
08/04/15 01:49:10
>>612
いや、だからみんなむちゃだといってるんでしょ
そのものの解決は無理だと

614:デフォルトの名無しさん
08/04/15 02:06:11
>>613
だからカスタムバリデータで終了だと言ってるのになんでループ？

615:デフォルトの名無しさん
08/04/15 02:21:09
>595=597の問題をどう定義するかで解決が変わるんだな
>599,604,610は↓が問題で
> 基本的に単体項目による検証ではなく、その他の項目と合わせて判断する必要があるのと
↓は問題ではなく単なる(願望としての)解法だと捉えてるからカスタムバリデータで解決
> Update Model Values の後にValidationしたいんだがどうすればいいんでしょうか？
> モデルのValidationは作成済みで、その機能をそのまま利用したいからです。
>600,611,613は↑が問題だと捉えてるから解決しない

616:デフォルトの名無しさん
08/04/15 08:32:16
immediate=true を組み合わせればmodel値取れるじゃん

617:デフォルトの名無しさん
08/04/15 13:22:52
>>616