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

JSF(JavaServer Faces ..

355:デフォルトの名無しさん
07/04/10 01:00:49
Strutsは難しいけど動きにはクセがない。
JSFは易しいけど動きにクセがありまくり。

356:デフォルトの名無しさん
07/04/10 07:27:58
クセがあるなんて言ってる奴は
新しいものについて行けないか視野の狭いJava厨だけw
.NET厨には普通の動きに見えるだろうな。

357:デフォルトの名無しさん
07/04/10 08:13:04
クセというのは、>>353で書かれてあるように、JSFの上に更にVisualWebPack用の
仕組みが組み込まれていることだと思う。
そういうのは既存のJavaフレームワークではあまり無い。
あくまでソースをゴリゴリ書くのが今までのJava開発だったからな
たしかにASP.NET方向に近づく進化だが、一方でRails的な進化とは別方向なので
気になる開発者も多いと思う

358:デフォルトの名無しさん
07/04/10 08:52:44
Visual Web Pack は結構やっかいだ。

359:デフォルトの名無しさん
07/04/10 11:51:36
>>357
お前、日本語読めないだろ

360:デフォルトの名無しさん
07/04/10 12:37:01
まねじどびーんがPOJOなのがいいのにそうじゃなくなるよね

361:デフォルトの名無しさん
07/04/12 01:41:53
>>356
ブックマーク不可とかクエリーパラメータが使えないとか、視野が狭いどころの騒ぎじゃありませんが。

362:デフォルトの名無しさん
07/04/12 09:21:40
ブックマーク不可ってときどき聞くけどどっか例になるサイトある？
クエリーパラメタ使用不可っていうのはGETでパラメタ受けてくんないってことだよね？

363:デフォルトの名無しさん
07/04/12 10:19:07
>>362
デマだから気にするな。

364:デフォルトの名無しさん
07/04/14 14:53:54
MyFacesのJSF1.2対応っていつ頃出るのかな？
JBossはMyFacesからGlassFish実装に乗り換えたらしいが

365:デフォルトの名無しさん
07/04/14 16:21:22
1.1.3あたりからすでに1.2対応。

366:デフォルトの名無しさん
07/04/14 21:31:56
>>365
おーそうなのか？と思って1.1.5をDLしたら
APIには1.1が入っていたよ・・・

367:デフォルトの名無しさん
07/05/06 16:23:14
やっとJSFなおれ

368:デフォルトの名無しさん
07/05/08 01:13:09
JSFってSEOを考えるとどーかと思う。
例えばURLパラメータをスラッシュで区切って受けるってことができないだろ

369:デフォルトの名無しさん
07/05/08 01:48:33
質問か。

370:デフォルトの名無しさん
07/05/08 03:24:21
瀬を早み岩にせかるる滝川のわれても末に逢はむとぞ思ふ

371:デフォルトの名無しさん
07/05/08 22:51:48
>>368
できる

372:デフォルトの名無しさん
07/05/10 11:24:55
時刻がずれて表示されてしまう問題についてご存知の方がいれば教えてください。

問題:ブラウザ上で時刻データDateやTimestamp形を表示すると時刻がずれしまう。
　　　ちょうど9時間ずれている(GMT時刻で表示される)ことから、Localeの設定だとは思っています。

・表示する前のアクションクラスでtoStringでログに出力すると正しく表示されるため、表示するデータは正しいと思います
・faces-config.xmlで<default-locale>ja</default-locale>と<supported-locale>ja</supported-locale>を設定しています
・開発環境はseam-1.2.1GA,java1.5.0_11,jboss4.0.5.GAです
・ブラウザは、IE,firefox,Operaで確認しました。

もし、何か心当たりがありましたら、教えてください。よろしくお願いします。

373:デフォルトの名無しさん
07/05/10 23:08:15
>>372
ろけーるをしていしてしゅつりょく

374:デフォルトの名無しさん
07/05/11 12:16:30
>>373
一度試してうまくいかなかったのですが、改めて試してみました。

<h:outputText value="#{Date型の変数}">
<f:convertDateTime pattern="yyyy/MM/dd HH:mm:ss" locale="Locale.JAPAN"/>
</h:outputText>

という形で試してみましたが、だめでした。
そこで、Locale.JAPANをLocale.GERMAN等いろいろな国で試してみたのですが、
同じ値（GMT)が出力され、localeの設定が生かされていないようです。
うーん何でだか、わかる方がいらしたらお願いします。

375:デフォルトの名無しさん
07/05/11 12:54:44
timeZone="Asia/Tokyo"

376:デフォルトの名無しさん
07/05/11 14:32:26
あ、そうかLocaleは時差じゃなくて書式に作用ということ・・・なのかな？
timeZoneの設定で確かに、解決することができました。

一個一個書いていくのはめんどくさいので、何かまとめて設定するところが
あるとは思うのですが、問題点がはっきりしたので、以降は自分で探したいと思います。

ご協力ありがとうございました。

377:デフォルトの名無しさん
07/06/24 11:10:44
JSFはレンダラーのカスタマイズとかがややこしいな。
直接ＪＳＰとかインクルードできないし。

簡単に使うだけならいいけど、カスタマイズしようとかすると
急に敷居が高くなる

378:デフォルトの名無しさん
07/06/25 23:30:57
フレームワークというのはそういうモノと思うしかないと思うが。

379:デフォルトの名無しさん
07/06/26 23:28:03
getAsObjectでFooを返すカスタムコンバータを作って、
下記のようにbean.fooでFooを受け取れないかと思ってるんですが
bean.setFoo(Foo foo)が呼び出されていないようです。

class Foo{
...
}

class bean{
　Foo foo;
...
}

<f:SelectOneMenu value="#{bean.foo}" >
...

なにやらJSFのgetConvertedValueあたりでバリデータのエラーが
起こっているようなワーニングがでていました。(JSF RI 1.2。
ソースコードは権限がないといわれて落とせませんでした。)

SelectOneMenuで自作クラスは使えないのでしょうか?

380:デフォルトの名無しさん
07/06/26 23:52:23
JSFつかってて、どういうときに痒いところに手がとどかないって感じますか？

381:デフォルトの名無しさん
07/06/27 10:50:23
ネットに資料が少ないところ

382:デフォルトの名無しさん
07/07/07 20:48:47
ざっと試した感じ、

VB以下だな

383:デフォルトの名無しさん
07/07/07 22:07:29
釣れますか？

384:デフォルトの名無しさん
07/07/08 15:45:10
ざっと何を試したのかな？

385:デフォルトの名無しさん
07/07/09 09:29:01
fとhだけじゃかなり自由度がなくね？

386:デフォルトの名無しさん
07/07/09 17:48:14
JSF ちょこっと勉強したが、使わなくても Servlet + JSP で十分だと感じた。

387:デフォルトの名無しさん
07/07/09 20:00:35
学生は暇つぶせるからそうかも知れんな。

388:デフォルトの名無しさん
07/07/09 21:23:50
JSFは、ツール使ってナンボだな。

389:デフォルトの名無しさん
07/07/09 21:25:14
>>385
MyFacesかwoodstockか、コンポーネントの追加したら結構いいけどな。

390:デフォルトの名無しさん
07/07/09 21:30:19
Strutsをツール使わずにやるのとJSFをツール使わずにやるのとでは、絶対にJSFの方が生産性は高い

391:デフォルトの名無しさん
07/07/09 21:40:17
フロントエンドをツール使って適当に作る分にはいいのかも
と、思ってたけど、Seamってのがあるくらいだから、ビジネスロジックもぐちゃぐちゃになるん？

392:デフォルトの名無しさん
07/07/09 21:51:05
ビジネスロジックはまた別の話でしょ
ちゃんとIF切ってれば問題ないと思うが。
それはStrutsも同じでしょ。

393:デフォルトの名無しさん
07/07/10 01:26:36
まあStrusは好みだしな。
HTML書きが苦でない香具師には効果無し。

394:デフォルトの名無しさん
07/07/10 14:49:47
>>390
Strutsをツール使ってやるのとJSFをツール使ってやるのとでは、絶対にJSFの方が生産性は高い

395:デフォルトの名無しさん
07/07/10 15:24:11
JSFだろうがStrutsだろうが、なんでもセッションに入れるクソ設計はやめろと言いたい

396:デフォルトの名無しさん
07/07/10 19:22:04
それはもう、あきらめたほうがいい

397:デフォルトの名無しさん
07/07/11 17:34:55
Seamではセッションより短いスコープのものが用意されてたような。

398:デフォルトの名無しさん
07/07/12 00:33:49
実装としてはセッションを使うかhidden埋め込みになるわけで

399:デフォルトの名無しさん
07/07/13 10:11:24
俺はtomahawk追加してるんだが、おまいらは何追加してる？
業界的に何が標準？

400:デフォルトの名無しさん
07/07/13 10:29:19
JSF

401:デフォルトの名無しさん
07/07/16 12:41:05
JSFの案件て実際にあるか？

402:デフォルトの名無しさん
07/07/16 12:44:23
どこの営業が「JSFの案件とってきました」とか言うのだろうか・・・。

403:デフォルトの名無しさん
07/07/16 18:32:20
>401
あるよ

404:デフォルトの名無しさん
07/07/17 09:19:00
>>401
客に頼まれて、どこぞのバカ会社の作ったJSF使ったやつのメンテを引き受けた
JSFだけじゃなくJavaもServletも分かってない感じのソースで、ダメダメだった

405:デフォルトの名無しさん
07/07/17 19:53:44
＞JSFだけじゃなくJavaもServletも分かってない感じのソースで、ダメダメだった
つか、知らんかったらビルドすら出来んと思うが。

406:デフォルトの名無しさん
07/07/17 22:27:10
>>405
いまはIDEが便利

407:デフォルトの名無しさん
07/07/17 23:11:38
ところでわかっていないソースってどんなのよ？

正直バカ会社ってaspとかを使ってそうなんだが。

408:デフォルトの名無しさん
07/07/17 23:52:28
ASPを選択できないところがバカなんだろ。

409:デフォルトの名無しさん
07/07/18 06:37:42
釣れますか？

410:デフォルトの名無しさん
07/07/18 13:48:57
>>407
マネージドビーンのコンストラクタでコンフィグクラス、ユーティリティクラスを初期化(newする)
なお、マネージドビーンは全部セッション
セッションに入れておく必要のないListをマネージドビーンのフィールドとして持ってる
バリデータは独自実装で、項目ごとにバリデータクラスがある
バリデータクラスは使うたびにnewしないとならない
ログインしてるかどうかの判定がマネージドビーンのコンストラクタにあるが、ログインしてなくても関係なく動く
ログインは各機能ごとにしなくてはならない(マネージドビーン単位？)

童貞だってもっとマシなコード書くわ
しかもセッションタイムアウトの設定を24時間に
すごい勢いでOutOfMemoryです・・・

411:デフォルトの名無しさん
07/07/18 19:22:56
>>410
> 項目ごとにバリデータクラスがある

JSF 1.1だよな？
項目ごとにバリデーションエラーのメッセージを変える必要があるなら、
それ以外にうまい方法はなさそうだぞ。

> しかもセッションタイムアウトの設定を24時間に
> すごい勢いでOutOfMemoryです・・・

それくらいでメモリ不足になるかね？
1万セッション×100KBでも1GB。
AP鯖ならそれくらい積めよと思う。

しかしJSFはログイン処理が標準化されてないのが
嫌だね。
include-preludeでsession変数とクッキー見るのが
一番？

412:デフォルトの名無しさん
07/07/18 19:49:52
まぁマネージドビーンになんでもかんでもデータ突っ込んでたら
すぐ何十MBにもなってしまうわな。
sessionにどういうデータをどのようにぶら下げるかあまり意識
しなくてもいいというのがJSFの利点でもあるわけだが。

413:デフォルトの名無しさん
07/07/18 21:23:47
メモリ不足は無いと思うけど、問題はGCじゃない？
無駄にオブジェクトの寿命を長くしたら、
Old GCが頻発して、あまりよくないような気がするなぁ。
ハードウェアのスペックを上げれば、要求性能は満たせるかもしれないが、
糞設計のためにハードウェアコストが上がる、というのが納得がいかない。
ハードウェアに金掛けた分、開発で手を抜いて開発費押さえて元を取る、
というのが近年の流れというのは分かるけど、
同じ工数で負荷の低い設計ができる、というのが分かるだけに、
タコな技術者のせいで顧客に余計なコストを背負わせていると思えてくる。

JSFは使ってないが、なんでもかんでもセッションに入れる設計のWebアプリの開発に関わった時にそう思った。
高価なPCサーバ（はっきり言ってイントラ向けにはオーバスペック）を使ってて、
その有り余る性能がこんな糞設計を吸収するために使われるのかと考えると、
正直お客さんに悪いような気がした。

414:デフォルトの名無しさん
07/07/18 22:29:50
クラスタしなくてもセッション情報のディスクI/Oってあるんだっけ？
少なくともセッションレプリケーションのコストで、全然スケールしなさそう。

415:デフォルトの名無しさん
07/07/18 23:34:49
漏れもよく理解してJSF使っているワケではない素人だけど

>バリデータは独自実装で、項目ごとにバリデータクラスがある
>バリデータクラスは使うたびにnewしないとならない

独自実装する必要がたぶんあったんだと好意的解釈をしたとしても
なんちゃら.xmlに記述すればソースでnewとかしなくても、タグに
そのクラス記述しとけば使えなかったか？

managedBeanってあんましコンストラクタでどーこーしようとは思わんけど
ログイン判定をコンストラクタでやろうとする発想が凄いな。

とか言いつつもどこでやるのが適切か？と言われるとうまく答えられんけど。
漏れはmanagedBeanにフィールドで持たせていて、
判定はDB鯖にアクセスする時に例外が発生したら・・・、とかやってるけど。

416:デフォルトの名無しさん
07/07/18 23:47:44
ログイン判定ってFilterでやるもんじゃないの？

417:デフォルトの名無しさん
07/07/20 10:03:51
>>411
項目ごとにメッセージ変えるからって個別にクラス作るなんてどんだけアホな設計だよ
しかも一分間に7セッション弱ってかなり小さすぎだろ、システム的に

418:デフォルトの名無しさん
07/07/20 13:16:45
メッセージが指定できるクラスを作るでござる

419:デフォルトの名無しさん
07/07/20 13:23:56
>>413
逆に考えるんだ、「高コストの技術者を長期に使うよりは安い」と考えるんだ

420:デフォルトの名無しさん
07/07/22 02:06:10
>>417
> 項目ごとにメッセージ変えるからって個別にクラス作るなんてどんだけアホな設計だよ

JSFの設計者に言えよ。
1.2では微妙に直ってる。
それでもまだ、エラーの原因ごとにメッセージを変えるには個別にクラスが
必要。

> しかも一分間に7セッション弱ってかなり小さすぎだろ、システム的に

ユニークビジターが毎日1万人くるサイトなら真面目にやれ、としか。
ひょいと「お前これやれ」と投げて引き継ぎ終了、そんなんで
まともなコードが出てくるわけがない。

421:デフォルトの名無しさん
07/07/22 18:14:04
>>410
>なお、マネージドビーンは全部セッション

JSC開発したら，デフォルトでマネージドビーンのスコープはセッションになるからな．
JSFってそういうもんだと思ってしまう．

422:デフォルトの名無しさん
07/07/22 18:28:10
セッションは 24 時間でもいいが、
5 分でディスクに永続化されるようにすればいい。
Tomcat とかデフォルトで永続化されると
思ってるバカが多いからな。

423:デフォルトの名無しさん
07/07/28 17:12:33
ここで聞くこっちゃないけど、Click Frameworkのスレってないよね？WebProg板にも。
今までずっとJSF使ってきたけど、最近Clickを試してみたらperlでcgi書くみたいに
サクサク書けるんで感激した。

424:デフォルトの名無しさん
07/07/28 23:04:07
Wicket とどっちがいい？

425:デフォルトの名無しさん
07/07/30 16:19:38
Wicket、いつのまにかApacheのプロジェクトになってる…

426:デフォルトの名無しさん
07/08/03 07:34:34
Wicket こそ正解。

所詮、設定ファイルなど無力よ。

427:デフォルトの名無しさん
07/08/05 11:49:47
Ymir いいぜ。

Seasar 系で初めていいと思った。
JSF や Wicket 見てもなんだかなー、俺様フレームワークを
作りたい衝動を抑えてきたが、Ymir は思想的に完璧だ。
完全に俺様の考えとオーバーラップする。
動かしてねーけど。

428:デフォルトの名無しさん
07/09/12 13:38:43
427見たいな自己中なやつの作る

429:デフォルトの名無しさん
07/09/12 13:40:09
427見たいな自己中なやつの作るフレームワークで開発するやつらかわいそうだな。
こーゆーやつの作るフレームワークって大概思想押し付けのオナニーフレームワークだし

430:デフォルトの名無しさん
07/09/13 02:37:23
どうした？嫌なことでもあったのか？

431:デフォルトの名無しさん
07/09/13 03:34:40
ああ。思想押し付けのオナニーフレームワークを作る奴がいてだな

432:デフォルトの名無しさん
07/09/13 06:41:21
それを言い出すとStrutsもオナニーから始まったと思ったが。

433:デフォルトの名無しさん
07/09/13 15:53:34
独善的でない設計は総花的。

総花的な設計はみんなが「いーんじゃね？」と言ってくれる。
そして誰も使わない。

独善的な設計は信者が使う。
そして信者以外の奴も使わされるようになる。

434:デフォルトの名無しさん
07/09/15 03:24:43
そもそも思想押し付けんのがフレームワーク。

435:デフォルトの名無しさん
07/10/18 01:28:26
<h:inputText id="hoge1" value="#{bean.foo}" />
<h:inputText id="hoge2" value="#{bean.foo}" />

inputTextのidに上記の様に連番をつけたいのですが、
何か方法はないでしょうか？

<h:inputText id="hoge"<%= i %> ... />
とか、式を書くと怒られます。

436:デフォルトの名無しさん
07/11/04 19:28:07
NetBeans6はVisualWebが独立したプロジェクトじゃなくて
strutsやJSFのようにフレームワークを選択するようになったね

Tomcatが標準で６になってJSFも1.2が使いやすくなったし
地味ーによくなりつつあるか

437:デフォルトの名無しさん
07/11/08 03:35:18
MyFaces もJSFもまぁ使えるようになってきたわ。
彼らの努力じゃなくて、各現場の努力だけどね

438:デフォルトの名無しさん
07/11/08 06:42:39
なんか使わせてもらってる立場のクセに妙に偉ぶるヤツいるよなｗ

439:デフォルトの名無しさん
07/11/09 01:27:13
>>438
お前のことか？ｗｗｗ

440:デフォルトの名無しさん
07/11/09 08:37:40
どう読んでも>>437のことだろ

441:デフォルトの名無しさん
07/11/09 09:22:22
皮肉を理解できないのか、空気を読めないのか、あるいは本人なのか。

442:デフォルトの名無しさん
07/11/09 21:38:35
>>435
ID属性を動的に設定できないのは仕様なのかな？
自分は、どうしようか悩んだ挙句、classに動的に設定した後、
onloadで呼び出したJavaScriptでclassからIDに振り替えるように実装したが・・・

443:442
07/11/09 21:42:12
すまん、>>435の例はformのタグだから、IDを自分のやり方で変えちゃまずいかも
formのタグってJSFが勝手にID振ってた気がするし

444:デフォルトの名無しさん
07/11/09 23:37:14
自分でcomponent作ってbindingしてやるとか？
試してないからsetId()したのがちゃんと有効になるかどうかは知らん。

445:デフォルトの名無しさん
07/11/10 01:36:04
>>442
IDは開発時にわかるからそれを使ってscript組むしかない
かってにIDいじっちゃうとデコードとかで問題になるはず

setIdはhtmlのIDとイコールではないよ
でも連番は可能
というか、テーブルはRowで連番ふってる

446:デフォルトの名無しさん
07/11/11 13:42:02
JSFだとテーブルつくるとき、columnspanつかえないんですけど、
方法あるのでしょうか？

あまりにしょぼくて困っています

447:デフォルトの名無しさん
07/11/11 13:49:26
静的なテーブルで良いなら、htmLib.jarが重宝する

448:デフォルトの名無しさん
07/11/11 15:01:14
>>446
セルは１つにしてグリッドレイアウトとかやるのがいいと思う

449:デフォルトの名無しさん
07/11/23 02:32:56
質問です。
<h:dataTable>ってヘッダのスタイルをカラム毎に指定できないじゃないですか。
で、行（表示するデータ用）のスタイルはカラム毎に指定できるから、
それぞれのカラムに最適な幅を指定するんだけど、
１行も表示してない状態（ヘッダのみの状態）だとカラムの幅が適当な幅に
なっちゃいますよね。（当たり前だけど行のスタイルが適用されない）
コレが「行あり」→「行なし」とページを切り替えるとズレるのがモロバレなんで
なんとかしたいんですが、いい方法はないでしょうか？

450:デフォルトの名無しさん
07/11/23 12:43:37
>>449
ヘッダにグリッドパネルをセットするといい
テキストはその中へ入れたり

そうすると1つのセルに複数のコンポーネント入れたり画像入れたり自由に出来る

451:449
07/11/23 18:49:35
>>450
なるほど。ちょっとやってみます。ありがとう。

452:デフォルトの名無しさん
07/11/23 19:04:33
JSF初心者の素朴な疑問：

1. なんかブラウザで表示されるURLと、実際に表示されるjspが違うんだけど、これってなんで同期できないの？もし仕様ならすごく不自然だと思うんだが。
2. HTMLのソースを見ると、入力したデータがシリアライズ(?)されてhiddenタグに埋め込まれてるみたいなんだけど、これってセキュリティ的にまずくない？そもそもなんでそんなことする必要があるの？

453:デフォルトの名無しさん
07/11/23 22:15:36
>>452
１と２に共通するものとして・・・
URLベース（アクションベース）のHTTPとHTMLを抽象化していないものと
イベントベースとは考え方が違う

URLに機能があるのではなくあくまでもWEBの上で動かしたからURLがついてきたと思えばいい

もしURLに機能を割り当てたいという旧世代の開発者ならPost後RedirectするようにJSFのconfigにタグを入れるといい
その代わりなんでもかんでもセッションにいれないとだめでそれを取り出すロジックとか作りこんでいくとバグが増えたり
メモリを圧迫することになるかもしれない

JSFはコンポーネントを復元する機能がある
この機能のおかげで前の画面で入力したものにミスがあった場合それを使って戻したり変更を検地できる
入力項目を反映させつつ、セッションを使わないで値を保存しておくことが可能

ちなみにデフォはsessionだったと思うけど、NetBeansVisualWebとかCreatorとかはデフォをclientで上書きしてるね
web.xmlをみるといいよ
「javax.faces.STATE_SAVING_METHOD」とかあるはずだから

454:デフォルトの名無しさん
07/11/23 22:32:38
>>453
それを補完するためにJBoss Seam（WebBeans）などもあるよ。
.NETはデフォでそうしているね。

455:452
07/11/23 23:07:12
>>453
>URLベース（アクションベース）のHTTPとHTMLを抽象化していないものと
>イベントベースとは考え方が違う
>URLに機能があるのではなくあくまでもWEBの上で動かしたからURLがついてきたと思えばいい

どうなんだろう。少なくともJSFでは表示画面とURLとが一致しなくても構わないというスタンスということ？
そうだとすると、ブックマークするときに困ると思うんだけど。ブックマークを許さないアプリしか作れない？そんなはずはないと思いたい。
それから、イベントベースのフレームワークだと、どれもJSFのようにURLと画面が一致しないものなの？イベントベースかどうかはあんまり関係ないと思うんだけど。

>もしURLに機能を割り当てたいという旧世代の開発者ならPost後RedirectするようにJSFのconfigにタグを入れるといい

別に「URLに機能を割り当てる」とか考える必要あるのかな？おれは、URLはリソースを表すものだと思うんだけど。
URLと機能とを結びつけてるわけじゃなくて、画面に表示されているリソース（HTML）とURLとが一致していないことが問題なんじゃないかな。

>その代わりなんでもかんでもセッションにいれないとだめでそれを取り出すロジックとか作りこんでいくとバグが増えたり
>メモリを圧迫することになるかもしれない

それをかわりにやってくれるのがフレームワークじゃないか。

456:デフォルトの名無しさん
07/11/23 23:11:47
MyFacesなんかの実装だとForwardベースでやるとブックマークできないね。だからRedirectで実現することもある。

Formの送信なんかを考えると機能という呼び方もおかしいとは思わない。

なんか455がすげームカつく。

457:452
07/11/23 23:16:31
>>453
>JSFはコンポーネントを復元する機能がある
>この機能のおかげで前の画面で入力したものにミスがあった場合それを使って戻したり変更を検地できる
>入力項目を反映させつつ、セッションを使わないで値を保存しておくことが可能

だから、これだとセキュリティ的にまずくない？
HTTPヘッダーでCacheをオフにさせても、HTMLページに前の入力結果が勝手に残っているわけでしょ？
シリアライズされているからパッと見ただけではわからないけど、すごく気持ち悪い気がするのは俺だけ？

なんかさ、「前の画面で入力したものにミスがあった場合それを使って戻したり変更を検地できる」っていうの、この方法じゃないとできないのかな。
こんなの、普通のCGIアプリケーションでもできるよね。

458:デフォルトの名無しさん
07/11/23 23:18:29
REST志向か強すぎることによるギャップでしょ。
あなたはJSFを使う事も出来れば、使わない事もできる。
よくある回答だがそういうことさね。

459:デフォルトの名無しさん
07/11/23 23:24:22
>>457
私はセキュリティ的にまずくないと考えますが、あなたはどうまずいと思いますか？

460:デフォルトの名無しさん
07/11/23 23:29:06
RESTとJSFは絶望的に合わないと思う
HTTPを基礎とする志向に対し、HTTPを隠蔽するFWだから
REST志向で作りたいならRails等を検討した方がいい

461:デフォルトの名無しさん
07/11/24 00:00:48
>>457
文章は最後まで読めよ

462:デフォルトの名無しさん
07/11/24 00:02:40
>>457
そのcgiってのは入力項目の変更があった場所とかに応じて自動的にバリデータとかイベントでのプログラミングできるの?
なんか生臭いコードかいてそうだけど

463:デフォルトの名無しさん
07/11/24 08:19:43
JSFを使う様な場面でブックマーク使うなんて事ない思うが。
ログインページやトップページ以外でブックマークされても困るケースの方が
ほとんどだろうし。

そしてURLと画面が一致しないのはあんま気にならないと言うか
誰が気にするんだ？って思う。

とりあえずユーザーはまったく気にしていなかったが。

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でいまいち上手くないってことは
社内ツール開発を主眼に置いているってことなのかね？

次ページ