09/08/06 01:16:17
要件の定義と機能の設計の違いが分からない馬鹿しかいないの？
777:nobodyさん
09/08/06 01:23:02
検索した時のスナップショットってのが必要かも知れんがな。
まあそれはおいといて早く作って見せてくれよ。
実装イメージでもいいぞ。
778:nobodyさん
09/08/06 01:34:52
「要件」という言葉を、「（システム開発の）要件定義」のことだと、勝手に論理のすり替えして楽しい？
>>757は
「詳細設計から参加だから、もうどうしようもなかった。」って記述してるんだから、
すでに詳細設計書が存在してるわけで、この場合の「要件」とは、
その詳細設計書を実現するのに必要な条件のことでしょうよ。
>よう‐けん〔エウ‐〕【要件】
>１ 大切な用事。「―のみ記す」
>２ 必要な条件。「教育者としての―を満たす」
779:nobodyさん
09/08/06 01:47:15
そもそも、ブラウザの画面をスクロールさせて、コントロールが表示エリアに入ったことをフックできるイベントなんてあったっけ？
仮に出来たとしても、cssで非表示させてるだけならhtmlのファイルサイズの削減にはならないから軽くならないし、
ポストするデータサイズも同じだし、むしろスクロールする度にJavaScriptのイベントが発生するから、
ベタに表示させるより重くなるんじゃね？
ASP.NET AJAXでスクロールするたびに動的にコントロールを生成するのなら、
初期に表示されるコントロールが少ないからhtmlのファイルサイズの削減にはなるけど、
スクロールさせるたびにサーバに問合わせてコントロールを表示させてデータを表示させるなんて、
物凄く遅くなるんでないかな。
さらにデータが変更されたテキストボックスが表示エリアから消えた場合、
それを復元する術がないから、非表示になったテキストボックスのデータも
いちいちサーバにポストバックして保存しないといけない。
そんなことするなら、ベタに5万個のテキストボックスを表示させたほうが軽くないか？
780:nobodyさん
09/08/06 02:03:42
簡単に実装するなら <iframe> を縦に並べてスクロールインしたときにページ単位でロードするだけでいい。
お前にも作れるよ。
781:nobodyさん
09/08/06 02:16:18
複数行にまたがって変更する場合どうすんの？
782:nobodyさん
09/08/06 02:21:31
でそれはべたに作るより速いのかね？
783:nobodyさん
09/08/06 02:30:15
50ページに分割したら最初にロードするのは1000個だけですむ。
遅くなる理由が見つからない。
784:nobodyさん
09/08/06 02:31:02
onscrollでスクロールされたイベントは発生するが、
どのコントロールが表示状態になったかは取得できないな
従って、絵に描いた餅
Flashかsilverlightなら可能だと思うが
785:nobodyさん
09/08/06 02:35:15
>>783
単にページ分けでいいじゃん
786:nobodyさん
09/08/06 02:43:39
全件表示か、ページ分けしての表示なら問題ないが
１つのページに複数のページが表示されるのは機能的に問題
データはいつ削除されるか追加されるかわからないんだから、
最悪の場合、50ページすべての行に同じデータが表示される可能性がある
そして後からデータが追加されて51ページ目が発生した場合にも対応できない。
787:nobodyさん
09/08/06 05:47:17
ページ分割というか、まあ１画面に表示する項目を絞れば早くはなるだろうな
後はAJAXなりで適当にスクロールしてるように見せかければいい
>>786
そういったことを防ぐために排他制御って考え方があるんだが
機能的に問題かどうかは、ロックがどうなってるかによる
普通のWEBアプリに見られるような楽観的ロックなら問題かもしれないが
適切なロックがあれば問題ない
そう考えると元の設計は、もしかするとロックするから
全項目を１画面に表示したいのかも知れない．．．と思ってみたがたぶん違うなｗ
788:nobodyさん
09/08/06 08:19:08
楽観的排他制御じゃないロックなんて普通は最後の手段に近いけどな。
まずはセッションとかでどうにかならないか考えるだろ。
あと数を絞れば速くなるに決まってるなんて言ってるのがいるが、
ホントに試してみたのかい？
789:nobodyさん
09/08/06 08:21:18
例えば一気に端から端までスクロールしてもまともに動くのか、
実は最初から全部読んだ方がスムーズだったなんてことはないのか。
790:762
09/08/06 09:46:36
>>778
詳細設計から参加、つーたら、普通は詳細設計書を書くところから参加という意味だろ。
馬鹿なの？死ぬの？
791:nobodyさん
09/08/06 13:11:14
いいこと思いついた。スクーロルバーは標準のスクーロルバーじゃなくて、ボタンか何かを
配置して、画面上には常に固定のコントロールを配置。
で、スクーロル下をボタンをクリックしたら
txtbox2の内容をtxtbox1に
txtbox3の内容をtxtbox2に
txtbox4の内容をtxtbox3に
txtbox5には新規にDBから取得した内容を新規にセット
ってやれば、画面上には常に一定数のコントロールしか表示されないし、PostBackerの処理
も簡単で一石二鳥じゃね？
792:nobodyさん
09/08/06 14:01:14
>>790
突っ込まれると思ったｗ
詳細設計時に存在するには内部設計書だな。すまんかった。
つーかいちいちプログラムと関係ないところのツッコミしかできないのかよ？
吐いた唾を飲み込むの？死ぬの？
唾飲み込むぐらいじゃしなねーけどｗｗｗ
793:nobodyさん
09/08/06 14:14:19
>>787
Webアプリで1画面表示する間、ずっとデータベースをロックしろとでも？
この場合、いつ最下部のページを表示する画面にスクロールかわからないから、
ページをみてる間はずっとロックかけてる必要がでてくるわけだが。
他人が使う可能性や、ブラウザのページの切り替わりの
可能性なんて考えたら、そんなロックは実用上不可能だろ。
結局、重複させない、または表示途中で削除されたデータに対応するには
クライアント側（ポストバックかクッキー）かサーバ（セッション）でデータを持ち続け、
最終的に楽観的ロックで確認するしかない。
>>791
2万行あったら最下部までたどり付くのに2万回クリックすんの？ｗｗ
そうなると100行単位とかのページ単位で切り替わるほうがいいんじゃね？
それでも200回クリックじゃつらいから、10ページ前に戻る、10ページ後に進む的な
ページングのボタンを設置したほうがいいんじゃね？
そうなると>>768で答えは既にでてる。
794: [―{}@{}@{}-] nobodyさん
09/08/06 15:33:22
ま、作る前にワーニング出さなかった君の負けだよ。
Ajax、XBAP、Silverlight、Flashなんでもいいから
ユーザビリティーの良いのに作り直す事だね。
795:nobodyさん
09/08/06 15:40:39
キミちゃんと最初から読んでる？
796: [―{}@{}@{}-] nobodyさん
09/08/06 15:51:43
>>795
ああ、読んでるよ。
設計書通りに作ったんだろ。
設計書見た段階でこりゃ動かんわってわかってたんなら
その段階で何かするべきなんだよ。
ちゃんとせんから余計な後戻りが発生するんだ。