09/08/04 10:41:59
>>750
初心者乙
752:nobodyさん
09/08/04 14:09:01
5万項目も入力&入力チェックする人間も大変だな
753:nobodyさん
09/08/04 19:43:51
Label+Textbox合わせて最大5ﾏﾝｺ位なんで、Textboxだけなら2ﾏﾝｺ位です。
横方向にTextBoxが40×Repeaterで500ﾙｰﾌﾟ、なので入力チェックの実装はそれほど大変では
ないのですが、、、
実際に運用した際の入力の手間については考えていません。
754:nobodyさん
09/08/04 20:38:23
そういうのはグリッドで設計すべき
755:nobodyさん
09/08/04 20:45:22
text二万個分のViewStateやらポストやらとか考えたくもない
でも設計に口出ししなかったんだから仕方ないな
756:nobodyさん
09/08/04 21:24:45
ちなみに何を入力させてんの？
それがわからないと最適解はわからんよね
NDAとかで具体的に話せないなら、似たような事例で
757:nobodyさん
09/08/04 22:30:19
>>754
ｸﾞﾘｰﾄﾞってGridView？あんまりGridViewを用いるメリットが思いつかない・・・
ちなみに、サンプルに良くある「行毎にある編集ボタンを押して編集モード、編集が終ったら行ごとの更新ボタ
ン押下で再び参照モード」 って挙動は駄目なんで。
ユーザはあくまでExcelへの入力のごときフィーリングを求めてるみたい。
>>755
詳細設計から参加だから、もうどうしようもなかった。
ポストは、xmlに定義した内容を見て、Request.Paramsを分解してDataSetに突っ込むっていう部品を作っ
たんであまり気にしてません。VIEWSTATEは・・・Sessionに突っ込んでるけど、恐ろしいサイズになってそう。
>>756
顧客情報。
1営業担当あたり500人程度を想定してるんで。
758:nobodyさん
09/08/04 22:36:00
わかりにくかったらすみません
repeater全体にlinkbuttonつけたんですが、
そのどこかの行をクリックするとその行だけ詳細パネルが開いて、他の行もそのまま表示ってしようとしたところ、
パネルは開いたのですが元々あった一覧行が消えてしまいます
何が原因だと思いますか？
759:nobodyさん
09/08/04 23:01:36
Excelのごとき入力をしたい画面をWebでつくるという腐った提案ナイスだな。
Excelでいいじゃんって言ったらしばかれそうだなｗ
760:nobodyさん
09/08/04 23:02:09
>>757
どういう契約関係かわからんが仕様書段階で忠告があってしかるべき仕様だよな
仕様通りつくって運用上の問題が発生したのなら、当然、別料金で作り直しでしょ
仕様の設計者が社内の人間なら、泣く泣く作り直すしかないね。
設計者に飯でもおごってもらえｗ
それはともかく、初めからマトリクス状に500行あるってこと？
それともユーザを追加していくうちに最大で500行まで増えそうってこと？
前者なら設計が最悪、後者なら20行ごとにページングするしかないね。
各行ごとに編集や削除ボタンを設置しておけば、表全体に対して入力チェック
する必要ないし、PostBackの容量も少なくて済むし。
761:nobodyさん
09/08/04 23:07:32
>>758
>repeater全体にlinkbuttonつけたんですが、
各行に1個のボタンを付けて、それをクリックすると行の詳細が、
パネル（パネルってなに？）に表示されるってことかな？
んで、クリックするとなぜかそのクリックした行のデータだけ
repeaterから削除されてるってこと？
いまいちどういう動作をしてるからわからんので、
記述したプログラムをどこかにupもしくは
操作している最中の動きをスクショでとってどこかにup
762:nobodyさん
09/08/05 00:32:56
能力の無い馬鹿ほど最初に予防線を張りたがるよねｗ
大抵が、パフォーマンスが出ないのは作りがしょぼいだけ。それを仕方ないと言い訳する屑。
googlemapみたいにアジャックスつかって、見えてる部分だけデータを拾ってくるようにして、スク
ロールインした部分は随時データを拾ってくるようにすればいい。
これなら、画面上に見えてるコントロールの数はずっと少なく出来るし、レスポンスも工場する。
763:nobodyさん
09/08/05 01:14:20
何いってんだか意味ワカンネ
764:nobodyさん
09/08/05 01:27:35
>アジャックス
765:nobodyさん
09/08/05 01:41:38
TextBox20000個より阿呆がいる
766:nobodyさん
09/08/05 01:44:50
>>762
やってみろよ。
見せてくれ。
作りがしょぼいだけってんだから簡単にできるんだろ。
767:nobodyさん
09/08/05 01:49:29
まもっとも、できるできないより問題はどんだけコストをかけるのかなんだけどな。
768:nobodyさん
09/08/05 02:01:41
一方ロシアはページング機能を搭載したRepeaterコントロールを
ASP.NET AJAXを使って実装した
769:nobodyさん
09/08/05 02:39:30
>>762
要件勝手に変えて何いってんだか
770: [―{}@{}@{}-] nobodyさん
09/08/05 09:24:53
>>758
ポストバックして一覧再描画してないって落ちじゃね？
771:nobodyさん
09/08/05 11:29:00
SharePoint Server
Excel Services...
772:nobodyさん
09/08/05 13:09:46
>757
普通、OWC考えないか？
773:nobodyさん
09/08/05 21:03:42
>>757
つ jqGrid(JQuery Grid Plugin)
つ UltraWebGrid(NetAdvantage)
774:762
09/08/06 00:52:33
>>769
ﾊｧ?
要件は全然変わってないだろ。馬鹿ですか？ｗ
775:nobodyさん
09/08/06 01:01:32
>見えてる部分だけデータを拾ってくるようにして、スクロールインした部分は随時データを拾ってくるように
って書いてなければ、勝手にそんな機能を実装してるわけで要件は変わってる
776:762
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
ああ、読んでるよ。
設計書通りに作ったんだろ。
設計書見た段階でこりゃ動かんわってわかってたんなら
その段階で何かするべきなんだよ。
ちゃんとせんから余計な後戻りが発生するんだ。