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

JSF(JavaServer Faces ..

237:デフォルトの名無しさん
06/10/29 09:51:49
>>234
>理解不能な挙動
どんな?

238:デフォルトの名無しさん
06/10/29 10:35:57
>>235
どっちも鳴かず飛ばずの状態だだがなｗ

239:デフォルトの名無しさん
06/10/29 13:08:08
AjaxFacesやShaleなんてもってのほか。
あんなもんが「使える」って思う奴の気がしれん。
しかも、いまだにShale(Struts 2.x)って？
今のStruts2.xはShaleとはまったく関係アリマセンが？

240:234
06/10/29 13:17:37
>>236
Strutsの本を読んでこれはだめだと落胆した後、ＪＳＦの本を読んだら天国にいる気がしました。
今から勉強するならStrutsよりJSFだと思ったのです。
勉強するからには、JSFは糞というよりは、単なる黎明期で、
すばらしい未来があるのだと信じたいのです。

>>237

・ListDataModelを用いてクリックされたアイテムのインデックスを取得する仕組みが、
<t:dataList>を使った時だけ機能しません。
<t:newspaperTable>や<h:dataTable>では機能します。

・作業フォルダworkを削ったら、work直下に今までと違うtldCache.serができるようになり、
セッションビーンがコンストラクトさえされなくなり、正しく動作しません。
ウェブアプリのURLを変えるとたまにうまくいったりします。
また、古いtldCache.serを戻し上書きしてやると、正しく動作します。

環境は、Tomcat5.5 Eclipse3.2+FacesIDE+TomcatPlugin Java5 WindowsXP
JSFは、sunの1.1と、MyFace1.1.3（FacesIDEに同梱のもの）、が入っています。

241:デフォルトの名無しさん
06/10/29 13:27:50
Strutsよりは全然いいけど、JSPベースのViewという時点で・・・
RestやFlex、Ajaxという方向に行きそうなこのご時世。

242:デフォルトの名無しさん
06/10/29 13:32:18
もうVelocityでいいじゃない。
何か問題ある？

243:デフォルトの名無しさん
06/10/29 13:36:55
>>242
標準技術ではない。

244:デフォルトの名無しさん
06/10/29 14:19:28
JSFは、FacesServletがHttpServletを継承してない時点で終わってると思う
今後のWebアプリケーションはHTTPをフルに使いこなすことが求められてるのに
GET、POST、PUT、DELETEを使い分けることが出来るServletの特性を
自ら捨ててしまっているし
HTTPに依存しないというJSFのポリシーによって、JSFは滅びる運命にあるな

245:デフォルトの名無しさん
06/10/29 14:20:23
別にJSF一辺倒でがんばらなくてもいいということでは？

246:デフォルトの名無しさん
06/10/29 16:51:31
別にJSFからJSP+servletのページ呼び出せるからそんなに
困った記憶はないんだが…。

JSFで提供されている機能以上の事をやろうとすると途端に敷居が
上がるのはあるけど、それはフレームワークだからそういうものと
漏れは思っているけど。

不満があるならテメーでタグ書けよって世界だと思ってた。

247:デフォルトの名無しさん
06/10/29 19:28:47
タグ書けっていう思考がうんこ。

248:デフォルトの名無しさん
06/10/29 20:02:31
タグ書けってのはStrutsが出た当初の思想だな。

249:デフォルトの名無しさん
06/10/30 09:10:32
>>241
AjaxはJSFで結構いい感じにコンポーネント化できてると思うのだが。

>>242
Viewの話はJSFと層が違う

250:デフォルトの名無しさん
06/10/30 11:05:07
>>244
JSF自体、Web用フレームワークではないからな。もっと広い概念でのMVCフレームワーク。
まあ現実的にはWeb用なんだけど。
HTTPに特化したJSFとかがあれば、もうちっとマシかと。

251:デフォルトの名無しさん
06/10/30 12:13:21
そうやって無駄に広い分野をカバーしようとして失敗しつつある気がする。
EJBの二の舞。
きっと2年後に、Tapestry、WiketやClickの風味を取り入れた
もっと便利なJSF3.0が出るよ。それまでJSFはおあずけ。

252:デフォルトの名無しさん
06/10/30 23:49:59
>>250
元の作りがそうだから、AjaxやRESTに積極的に対応するには不適格なフレームワークだと言える
Ruby on RailsがRESTfulに突っ走ってるのとは対照的
JSFとは別の、今の時代に合ったフレームワークがJavaにも必要だと思うのだが

253:240
06/10/31 02:25:34
>>240
work削ったら動作がおかしくなった原因は、
libに、sun-RIのjarと、MyFaceのjarを両方入れていたのが原因だったようだ。
FacedIDEが自動で入れるものだけで十分なのが。

254:デフォルトの名無しさん
06/11/06 02:10:38
最近やっと色々うまく動かせるようになった。JSF最高！
tomahawk面白い。ただ情報が少なくてしんどい。

255:デフォルトの名無しさん
06/11/11 00:21:54
tomahawk-1.1.3のinputFileUploadって壊れてない？
サンプルのwarを探しても出てこないし。

256:デフォルトの名無しさん
06/11/11 00:24:27
物騒な名前だな

257:デフォルトの名無しさん
06/11/13 16:20:07
Faceletsて、どうなん？
HTMLベースでやっちゃうようだが。

258:デフォルトの名無しさん
06/11/20 04:19:02
>>255
動くよ

259:デフォルトの名無しさん
06/11/27 16:28:04
なんかスレが過疎ってるけど、JSFってまだあまり使われてないのかな

260:デフォルトの名無しさん
06/11/27 20:15:18
>>259
×まだ
○もう

261:デフォルトの名無しさん
06/11/27 22:11:51
じゃあみんなで何故JSFが廃れたかについて語ろうか。

262:デフォルトの名無しさん
06/11/27 22:53:15
JSFを好んで使っている漏れがきましたよ。

263:デフォルトの名無しさん
06/11/28 01:54:19
JSFってデザイナとの分業が絶望的じゃない？

264:デフォルトの名無しさん
06/11/28 20:28:20
実際に分業している人っているの？
JSP+servletよりはマシだから使っているんだけど。

265:デフォルトの名無しさん
06/11/28 22:11:54
素人なので、まじめに聞くが、
デザイナがJSFのタグを覚えて打つって分業は完璧だよな。

266:デフォルトの名無しさん
06/11/28 22:37:11
Velocityが一番好きだな
Writerを出力先にしてるから再利用しやすい
時点でWicketかな

267:デフォルトの名無しさん
06/11/28 22:57:16
>>265
今はどうか知らんがIDが自動生成なんでCSSとの連携がダメダメだろ
デザイナーが使ってくれるとは思えない
JSFはもう見捨てたから今後一切使わないけどな

268:デフォルトの名無しさん
06/11/28 23:12:33
>>267
CSSとの連携は、id使わないでclassだけじゃダメなの？

269:デフォルトの名無しさん
06/11/29 02:46:40
JSFってNetBeans前提な感じじゃない？

270:デフォルトの名無しさん
06/11/29 09:41:43
idはtomahawkでforceId属性使えば固定できるよ。

JSFしかしらない素人なので、JSFは最高と思っているんだが違うのか？
少なくともstrutsは気持ち悪いだろ。

271:デフォルトの名無しさん
06/11/29 22:14:56
>>268
getElementByIdを使わせない気か？

272:デフォルトの名無しさん
06/11/29 22:18:23
>>270
別に今後広まるとも思えないComponent前提のJSFの方が気持ち悪い

273:デフォルトの名無しさん
06/11/29 22:43:41
JSFはIDEから作るという特性を出したいらしいから
APIの美しさ云々ではなく、中間ファイル使ってでもいいから色んなIDEで
というのに主眼が置かれていると思う。
保守性より生産性を優先するならJSFもいいツールだよ。
社内の使い捨てアプリとか作る分には最高だ。RoRとか選択肢になけりゃ。

274:デフォルトの名無しさん
06/11/29 23:23:24
IBMのWebSphere(Rational)だとRoRが選択肢にないので、今のところWebアプリの
製作で一番生産性が高く初心者でも扱えるのはJSFだと思う。

確かに.NET並にまったくプログラムをせずにデータの照会・更新・削除・アップロード
ダウンロードくらいは簡単に出来る。

Javaの知識ゼロでもそこそこ出来るのはそこそこに感動したけど、
おそらく、楽に作れすぎてしまうので製作者がドキュメント作らなくなるのが
欠点だとは思う。
VB厨の気持ちが体感できる。（ｗ

275:デフォルトの名無しさん
06/11/30 23:36:52
自分はガリガリコードを書く派だけれども、O/Rマッパーと
DIコンテナとJSFを混ぜて使うと結構楽チンになる気がする。

276:デフォルトの名無しさん
06/12/01 00:33:02
EJB3+JBoss seam +JSFはかなり楽チンになりそうだね。

277:デフォルトの名無しさん
06/12/01 00:58:54
JBoss Seamイマイチ。

Conversation IDがアプリ全体で一意なのはいいけど、
なんで単純に1からインクリメントなんだ？カンタンに偽装オッケーじゃんか。

EventスコープでもConversation IDが振られる。
リダイレクトで画面遷移できても
「JSFはURLがブックマーカブルではない」という問題は全然解決できてない。

SFSB使いすぎ。リソース消費激し過ぎ。

JSFのSAVING_STATE_METHODがClient必須。
正気かよ？？？？

TeedaとかS2xx等、Seaser関連使ったほうが良さげ。

278:デフォルトの名無しさん
06/12/01 03:05:06
TeedaはS2Container使わないといけないからなあ

279:デフォルトの名無しさん
06/12/01 05:57:33
panelGridやpanelGroupタグを使ってcolspan属性を付ける方法が見当たりませんでした。
facetを使うと丸々一行にcolspanが張られるのですが、指定した列をまとめることができなくてorz
みなさんどうやって自在なtableタグをきってるのでしょうか・・

たとえば下の簡単な例でも、htmlタグをべた書きしないと作成することができませんでしたorz
<table border=1>
<tr>
<td>ラベル</td>
<td><input type="text" size="20" /></td>
<td>メッセージ</td>
</tr>
<tr>
<td colspan=2 align="right"><input type="button" value="ボタン" /></td>
</tr>
</table>

280:デフォルトの名無しさん
06/12/01 12:17:30
>>279
調べたら、tomahawkの<t:panelGroup>にcolspan属性が増設されたらしい。
tomahawk-1.1.3で使えなかったので、その後のバージョンのものか。
rowspanはないらしい。

手打ちJSFは楽しいな。

281:279
06/12/01 20:12:51
>>280
早速試してみます。ありがとうございますm(__)m

またまた質問で申し訳ないのですが、
Sun Java Studio Creator2でtomahawkやsandboxを使いたいのですが、JSC用の complibってないですよね？　
探してみたのですが見つからなくて。。
これだけメジャーなライブラリのcomplibファイルを自分で作成するのも変なはなしですよね。。

というのも、BluePrints AjaxComponentsのautocompleteを試してみたのですが
使い勝手が悪くて（自分が使いこなせてないだけかもしれませんが）
sandboxの方を使いたくて＾＾；

282:デフォルトの名無しさん
06/12/02 02:55:50
SunのCreatorってどうなの？
最近のマシン（C2D）とかなら余裕でサクサク？

283:デフォルトの名無しさん
06/12/02 03:59:10
C2D持ってないのですが
Pen4の2.6G、Mem1Gの自宅PCでは、
セキュリティソフト無し、余分なプロセスが動作してない状態でも
固まったかな？と思うことがあります＾＾；
起動時にかかる時間はめちゃ長いと思いました。

284:デフォルトの名無しさん
06/12/02 07:44:05
>>282
もう単体の製品じゃなくなる。

285:デフォルトの名無しさん
06/12/02 20:18:16
>>283
そんなんだと上司説得しづらいなｗ
重いもん入れるとしかられちゃう

286:デフォルトの名無しさん
06/12/04 23:21:31
>>277

> リダイレクトで画面遷移できても
> 「JSFはURLがブックマーカブルではない」という問題は全然解決できてない。

↓はダメなの？
URLﾘﾝｸ(www.jbug.jp)
URLﾘﾝｸ(www.jbug.jp)

287:デフォルトの名無しさん
06/12/04 23:35:49
>>286
試してみたことある？
SeamRedirectFilterを使ってRedirectによる画面遷移を行うと
URLに常にConversationIDがパラメータとして付加されるんだよ。

288:デフォルトの名無しさん
06/12/05 07:00:54
>>287
Seam付属のblogサンプルだとconversationIdが付くのって
ログイン周りだけみたいなのだが、対話セッション中のコン
テンツもブックマークしたいということか？

289:デフォルトの名無しさん
06/12/06 02:04:30
バッキングビーンのスコープのrequestとsessionてどう使い分けてる？
sessionスコープで複数のページで共有する方がhiddenに頼らなくて済むのはいいんだが、
データが残らなくていいところで残ったりと何かを気を使わなきゃならない感じで
やっぱりトレードオフなのかな・・・

290:デフォルトの名無しさん
06/12/06 04:59:43
tomahawkの<t:saveState>も面白い。
inputHiddenより簡単に特定ページ間でビーンの値を保持できる。

sessionビーンはグローバル変数ぐらい嫌なんだが。

291:デフォルトの名無しさん
06/12/06 07:21:34
>>289
まさにそういうときのためのJBossSeamにはConversationスコープがある。

292:デフォルトの名無しさん
06/12/06 15:14:58
そしてConversationIDの問題に話がループ

293:デフォルトの名無しさん
06/12/06 19:38:46
StrutsとJSFの中間的なものが欲しい

294:デフォルトの名無しさん
06/12/06 20:04:24
Wicket対応のフォームデザイナが一番幸せかも。
既存のHTMLにWicket属性を埋め込めるフォームデザイナでもいい。
あとValidaterとConvertorは仕様を統一してほしい。

295:デフォルトの名無しさん
06/12/06 21:38:24
SpringMVCとJSFだとどっちがいいかな？

296:デフォルトの名無しさん
06/12/06 21:57:57
>>289
私はセッションレベルで管理しているビーンは一つだけにしているが。

297:デフォルトの名無しさん
06/12/06 22:12:02
>>284
NETBEANSのプラグインになることか？
サーバーはサンのやつか。
これが重くてたまらんよ。

298:デフォルトの名無しさん
06/12/06 22:33:56
5.0だからTomcatバンドルだけど、正直それをプラグインにしてよって感じだね
バンドルサーバの更新をしこしこするのはやだなぁ

299:デフォルトの名無しさん
06/12/06 23:49:58
>>297
Tomcatで動かせばいい

300:デフォルトの名無しさん
06/12/07 08:58:38
>>299
今、JSC使ってるんだけど、サーバーをトム猫に変えられるということ？

301:デフォルトの名無しさん
06/12/07 10:24:13
コンテナ特有の機能を使ってなきゃ、試しに移行してみな。まんま行けるかもよ。

302:デフォルトの名無しさん
06/12/08 16:52:16
Netbeans に Visual Web Pack いれたら
トム猫ベースでＪＳＦが動きました．
というわけで，ＪＳＣとサンのサーバーとはおさらばします．

303:デフォルトの名無しさん
06/12/09 08:05:49
JSCでもTomcatで動かせるはずだが。

304:デフォルトの名無しさん
07/01/22 22:43:00
willcomのオンラインストアがJSFで作られてるっぽいけど、実装はなにか分かる人おらん？

305:デフォルトの名無しさん
07/02/15 17:10:59
JSFの実装の選択肢にMyFacesとTeedaがあったら、どっちを使うのがよい？

306:デフォルトの名無しさん
07/02/16 00:00:54
単体での使い勝手を考えたらTeeda。

「メジャーである」「『対応している』と明言している
コンポーネントライブラリが多い」という安心感が
欲しければMyFaces。

307:デフォルトの名無しさん
07/02/16 10:20:35
>単体での使い勝手を考えたらTeeda。

まだ開発中な感じにみえるからどうも踏み切れないなぁ

308:デフォルトの名無しさん
07/02/16 21:40:39
MyFacesは最近どうなの？そろそろ安定してきた？

309:デフォルトの名無しさん
07/02/17 21:39:28
バッキングビーンの仕様はいいね。

310:デフォルトの名無しさん
07/02/18 05:52:37
JSFいいね。
いまさらStrutsを選ぶやつの気がしれん。

311:デフォルトの名無しさん
07/02/18 15:43:50
JSF確かにいいんだけど、難点は、なにか記述を間違えてしまって
setterやactionが呼ばれなくなったときのデバッグが難しいこと。
IDEによるサポートが充実していればいいんだろうけどね。

312:デフォルトの名無しさん
07/02/18 15:56:34
JSFとは
ジェフ・桟原・藤川
今年の阪神の押さえかいのぉ？

313:デフォルトの名無しさん
07/02/18 16:14:16
俺はJSF好きじゃないなぁ。

URLﾘﾝｸ(www.eisbahn.jp)
>>UIInputが対象とする入力値はあくまで１つであり，よってバリューバインディングが行われる値も１つである

複数のinput要素と複数のBeanプロパティが対応するような、
コンポーネント作りが激しくだるい。

314:デフォルトの名無しさん
07/02/18 16:36:42
>>313
どうでもいいが、そのブロガー、役不足の使い方を間違えてるなｗ

315:デフォルトの名無しさん
07/02/18 17:01:26
>>314

揚げ足取り乙。

316:デフォルトの名無しさん
07/02/18 17:22:04
>>315
その程度で揚げ足取りなんて言われたら学校の先生の立場が危ないぜ

317:デフォルトの名無しさん
07/02/18 19:13:47
役不足という言葉は、そろそろ新しい意味で正式に認識されてもいい頃だ

318:デフォルトの名無しさん
07/02/18 19:17:30
正反対の意味が認知されちゃうのはｲﾔだなあ。

319:デフォルトの名無しさん
07/02/18 19:23:44
ある意味2chだからこそ、こういう言葉は正しく使うべきだとｵﾓ。

320:デフォルトの名無しさん
07/02/18 20:04:49
助長とか、逆の意味で浸透して、既に辞書にまで載るくらいだからな。

321:デフォルトの名無しさん
07/02/18 20:34:43
ただの揚げ足取りならスルーでいいのだが、
間違った日本語を平気で使うブログは、
・なんとなく、根拠のない思いこみ癖がある著者
・物事を正しく表現できない・正確に伝えられない著者
という可能性があって、信憑性が落ちることがある。

322:デフォルトの名無しさん
07/02/18 21:16:22
>>321
まぁな。
だが、『役不足』の間違いはよくある話。
多めに見てやってくれ。

323:デフォルトの名無しさん
07/02/18 21:24:29
でも「役不足」なんていうのは「勉強のできる子」なら大抵知ってることなんで。
「勉強のできない子」がまとめた文書を盲目的に信じろっていうのもねえ。
あんたも「多め」とか書いてるしｗ

324:デフォルトの名無しさん
07/02/18 21:50:59
多めが大目ってこと？

でもたぶん>>323より俺のほうが高学歴。
東大じゃぁないけど。

325:デフォルトの名無しさん
07/02/18 21:52:54
2chで学歴自慢とは・・・。

326:デフォルトの名無しさん
07/02/18 22:13:57
> でもたぶん>>323より俺のほうが高学歴。
> 東大じゃぁないけど。

327:デフォルトの名無しさん
07/02/18 22:24:55
そろそろやめないか？ｗ

328:デフォルトの名無しさん
07/02/18 22:38:49
言葉の意味は時代と共に変わるんだ。
おっさんは正しく、いとおかしとか言っとけ。

329:デフォルトの名無しさん
07/02/18 22:50:32
「役不足」の意味は変わったのか？

330:デフォルトの名無しさん
07/02/18 23:07:56
間違えてる使っている人口が増えているだけで、
「役不足」の意味は変わらない。
死語の様に使われなくなった言葉ならともかく。

そして「多めに見てやってくれ。」って言う奴の言葉は
さらに説得力がないな。ｗ

331:デフォルトの名無しさん
07/02/18 23:10:30
それを免罪符にするのそろそろやめないか？

332:デフォルトの名無しさん
07/02/18 23:11:13
すまん。
「それ」＝「言葉の意味が時代とともに変わる」

333:デフォルトの名無しさん
07/02/18 23:52:59
そういう奴に限って人が死んだ時に
平気で冥福を祈ったりするもんよ。

俺もなんかやらかしてるんだろうなあ・・・。

334:デフォルトの名無しさん
07/02/19 01:42:14
おまえら全員激しく板違いだ。アホか。
好きなだけ語ってこい。

言語学
URLﾘﾝｸ(academy5.2ch.net)

335:デフォルトの名無しさん
07/02/19 11:22:25
まぁ、このスレを見てる人が俺以外にもいることがわかった

336:デフォルトの名無しさん
07/02/20 01:21:57
冥福を神に祈って火葬で寺に埋め神社で穢れを禊ぐのだ

337:デフォルトの名無しさん
07/02/20 11:47:54
そろそろJSFの話にもどろうか．．．．

338:デフォルトの名無しさん
07/02/21 17:23:30
JSFの話にもどそうとしたら人が消えた

339:デフォルトの名無しさん
07/02/21 17:32:52
使ってる人少ないからね。

340:デフォルトの名無しさん
07/02/21 18:16:35
Strutsは飽きたがJSFはまだかいな。ちょいなちょいな。

341:デフォルトの名無しさん
07/02/24 19:04:06
URLﾘﾝｸ(www.eclipse.org)

WTP2.0のVisual Page Designerって使えそう？

342:デフォルトの名無しさん
07/02/24 20:20:19
>>341 感想よろしく。

343:デフォルトの名無しさん
07/02/27 00:18:51
JSF Tools として公開されてたやつかな？

344:デフォルトの名無しさん
07/03/12 12:51:28
JSP+Servletが一番いいな。

345:デフォルトの名無しさん
07/03/21 00:58:44
Tobagoってなんだよ
Tomahawkとは違うのかよ

346:デフォルトの名無しさん
07/03/21 01:12:29
ちがうだろ、そりゃ

347:デフォルトの名無しさん
07/03/21 01:27:58
>>346
OOスレの春厨か

348:デフォルトの名無しさん
07/03/21 04:53:41
Studio Creator/NetBeans Visual Web Packのコンポーネントが、woodstockコンポーネントとして独立するね。
URLﾘﾝｸ(woodstock.dev.java.net)

349:デフォルトの名無しさん
07/04/08 00:40:57
ﾔﾚﾔﾚだな・・・・

350:デフォルトの名無しさん
07/04/08 20:30:01
VisualWebPackで業務ｼｽﾃﾑ開発中･･･
毒を食らわば皿まで、やね。
そのくらいのほうがﾒﾘｯﾄ/ﾃﾞﾒﾘｯﾄはっきりして個人的には好きやね。

351:デフォルトの名無しさん
07/04/08 20:33:57
勇気あるな。

352:デフォルトの名無しさん
07/04/08 20:40:27
どこら辺が問題なの？
>ﾔﾚﾔﾚだな・・・・
>毒を食らわば皿まで、やね。

353:デフォルトの名無しさん
07/04/09 07:50:26
>>352
んーと、ただでさえクセのあるJSFにもう一個FWが被せられてる感じ。

354:デフォルトの名無しさん
07/04/09 22:11:45
レスどうも、軽く触ってみた感じではJSFはStrutsよか簡単に感じたのでクセのあるっていうのは意外でした。
@ASP.NETから入った人

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

次ページ