【質問】ASP.NETスレ Part5【議論】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2009/01/23(金) 09:46:51ID:???Part1 - 【質問】 ASP.NETスレ 【議論】
http://pc5.2ch.net/php/kako/1040/10406/1040698263.html
【質問】ASP.NETスレ Part2【議論】
http://pc8.2ch.net/test/read.cgi/php/1111480331/
【質問】ASP.NETスレ Part3【議論】
http://pc11.2ch.net/test/read.cgi/php/1160355849/
【質問】ASP.NETスレ Part4【議論】
http://pc11.2ch.net/test/read.cgi/php/1184683786/ （dat落ち？）
あんまり需要ないのかもしれませんが。。。
0697nobodyさん
2009/07/28(火) 00:30:07ID:???そこらへんまで行くと、完全に実装にかかるコストやなんやらとのトレードオフ
ISDNとか56kモデム全盛の時代は帯域が狭いから、
トラフィックも考慮されてたけど、今じゃよほど特殊な環境やページでなければ
トラフィックを気にして設計することなんかほとんどない
その証拠に、画面を描画するcssも、よくあるライブラリを記述するjsも、
必要な部分だけincludeしてるわけじゃなく、サーバに対して１つだけを設定してるだけでしょ
さらに言えば、今時、JavaScriptで入力チェックしてるサイトも少数派になってる
どうせ両方に実装するのならJavaScriptのほうは不必要という考えもできるからね
0698nobodyさん
2009/07/28(火) 02:26:18ID:FCPdlHYK自力でScriptをゴリゴリ実装するのは後で他人が多大なる被害を被るのでやめてくれ。
んなもんサーバ側でやればいいだろーが。
0699nobodyさん
2009/07/28(火) 08:13:31ID:???自前の関数から呼んでるのとかあったな
0700nobodyさん
2009/07/28(火) 09:19:48ID:???そんなの、いくらでもエンドユーザが改変可能じゃん。
原則は、全部のデータをサーバに丸投げして、あとはサーバ側でチェック。
仮にclient側のjavascriptでチェックしてても、全く同じチェックをサーバ
側でも再実施。だったら実装の手間隙考えて、微々たるトラヒックの事なん
か気にしない。（＝clientではチェックしない）
0701nobodyさん
2009/07/28(火) 11:02:01ID:???ってまあ言いたいことは分かってるんだけどな
0702Appri童貞
2009/07/28(火) 17:08:04ID:sYPKb5BWエラー発生モジュール kernel32.dll、バージョン 5.2.3790.4480、
エラー発生アドレス 0x0000bef7
こんなログ出た人いますか？
0703nobodyさん
2009/07/28(火) 17:20:27ID:???聞く前にぐぐれ
kernel32.dll 0x0000bef7 5.2.3790.4480
でぐぐったら、1つ目のリンクにSystem.OutOfMemoryExceptionがどうとか書いてあるぞ。
0704Appri童貞
2009/07/28(火) 17:33:53ID:sYPKb5BW0705nobodyさん
2009/07/28(火) 19:06:55ID:???0706nobodyさん
2009/07/28(火) 19:48:08ID:???0707nobodyさん
2009/07/29(水) 03:14:53ID:S6cUwBjXゴメン、今のプロジェクトで __doPostBack 書いてる。
0708nobodyさん
2009/07/29(水) 03:30:54ID:???別に問題ないと思うけど
0709nobodyさん
2009/07/29(水) 07:38:21ID:???しかしだからって、__doPostbackを自前で呼ぶことが許容できるかというと微妙。
十中八九、代替する方法があるだろうしな。
0710nobodyさん
2009/07/29(水) 19:40:32ID:???ClientScriptで動作させることが前提の非ビジュアルコンポを作ったら楽かもしれない
つか、ICallBackEventHandler試したことないから、やってみようかな
0711nobodyさん
2009/07/29(水) 20:30:18ID:???<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
<ajaxToolkit:MaskedEditExtender
ID="MaskedEditExtender1"
runat="server"
InputDirection="RightToLeft"
Mask="99,999"
MaskType="Number"
TargetControlID="TextBox1">
</ajaxToolkit:MaskedEditExtender>
と設定されたテキストボックスに、1を入力してポストバックなりすると
100,000と変換？されてしまします。
Mask="9,999" でもダメでした（1,000になってしまう）
しかし
Mask="999999" やMask="9,999,999"では問題ありませんでした。
これは何かの制限でしょうか？
0712nobodyさん
2009/07/30(木) 01:45:47ID:6Jkou0XR0713nobodyさん
2009/07/30(木) 02:45:19ID:???0714nobodyさん
2009/07/30(木) 03:29:35ID:???コールバックとポストバックは似て非なるものだから
どうしてもポストバック使いたいときもあるだろう
つか1.1まではそれしかなかったしな
ダメな理由はない
まあ、見通しが悪くなることが問題といえば問題
だがそれはコールバックでも同様
0715nobodyさん
2009/07/30(木) 06:36:24ID:???だから相関関係が無くなる
0716nobodyさん
2009/07/30(木) 07:36:36ID:???0717nobodyさん
2009/07/30(木) 08:11:07ID:???もちろん最終的には開発者の自由なんで、あくまで俺の見解として。
まず、前にも書いたがそんなことをしなくても
十中八九、正攻法で解決できると予想される。
また、他に方法がなかったとしても、
果たして裏道を使ってまで解決する要件か疑問が残る。
次に、そのような組み方は「らしくない」と感じる。
極端な例えだが、Responce.WriteでHTML出力してたり、
GridViewに仕込まれた無数のhiddenを見ている気になる。
最後に、フレームワークを使っていて、
ハッキング(裏道の利用)に手を染めたら負けかなと思ってる。
0718nobodyさん
2009/07/30(木) 14:41:52ID:???違う
最初は正しかったが、IDEでaspxの何かを変更をすることで、
結果的に間違ったものになったということ
基本的にIDEの機能や本来のやり方と無縁だからこうなる
0719nobodyさん
2009/07/30(木) 18:15:21ID:???それはスクリプトでIDなんかをハードコーティングするから悪い
スクリプトをサーバコントロールで動的に生成して出力するようにすれば
サーバコントロールとの関係は崩れない。これがAPS.NET流じゃないかな
まあ、__doPostback直接書くのはお勧めじゃない。GetPostBackEventReference使えと
.aspx側(html側)にスクリプト書いたとしても、動的に変更する必要があるところは
実行時バインド式で書いとくのが通常
0720nobodyさん
2009/07/30(木) 21:07:58ID:???これが読みにくくて判読しにくいんだよな
そもそもサーバサイドスクリプトがcsに書かれてるのも違和感だし
うまく解決できないものか
0721nobodyさん
2009/07/30(木) 21:46:45ID:???0722nobodyさん
2009/07/30(木) 22:11:19ID:???GridViewによるマスタメンテを実装しているのですが、GridViewはEnableViewStateをfalseにしないと更新が出来ないそうですね。
現在、ロジック側でConnectionStringを設定するつくりになっているので、EnableViewStateがtrueでないと動かないのです。
ということで%一行目%しかないかと思ったのですが、どこか参考になるURLなどご存知の方がいらっしゃれば、ご教授いただければ幸いです。
よろしくお願いします。
0723nobodyさん
2009/07/30(木) 22:18:30ID:???そうなの？初めて聞いた。
>ロジック側でConnectionStringを設定するつくりになっているので、EnableViewStateがtrueでないと動かないのです。
そうなの？これも初めて聞いた。
0724nobodyさん
2009/07/30(木) 22:21:01ID:???同じ環境でGridViewから更新処理してるが、EnableViewstateはTrueのままだぞ。
あと編集処理は通常CommandNameがEditであって、
更新はUpdateだから同じものでも無いはずなんだが。
まぁイベントハンドラならOnCommand辺りでフックすればいいんじゃないか。
と、ここまで書いて思い付いたが、
もしかしてObjectDataSource等をかまさずに
直接DataSourceにオブジェクトを割り当ててるとか？
0725nobodyさん
2009/07/30(木) 22:26:48ID:???VS2008+MSSQL2005
0726nobodyさん
2009/07/30(木) 22:41:33ID:???IsPostBackがtrueの時にDataBindするとイベントが発生しないということと、
ポストバックしてEnableViewStateがtrueの時だと、
取得時のデータと異なる可能性があるというデータの整合性や楽観的ロックの
関係とごっちゃになってるような気がする。
0727722
2009/07/30(木) 23:43:56ID:???というと、これはガゼ？
ttp://bbs.wankuma.com/index.cgi?mode=al2&namber=6830&KLOG=17
ttp://yaplog.jp/iamcat/archive/23
(1)削除は出来る
(2)更新も、少なくともSQLは流れてる
※UpdateCommandのSQL文弄るとエラーになるので
から、画面から入力した内容がUPDATE文に流れていないのだと判断したのですが・・・。
>>723
>>ロジック側でConnectionStringを設定するつくりになっているので、EnableViewStateがtrueでないと動かないのです。
>そうなの？これも初めて聞いた
初回は動くんですが、ポストバックするとConnectionStringが元に戻ってしまうらしいんですよ。
Page_loadで毎回代入してるはずなんですけどね・・・。
0728nobodyさん
2009/07/30(木) 23:58:28ID:???>というと、これはガゼ？
それは、GridViewにデータをバインドした後に、誰かがデータを変更した場合の話
初回アクセス時にデータを取得し、それ以降はサーバとブラウザの間でポストバックして、
データを持ち回りしているので、その間にデータベースのデータが変更されても、
変更されたデータとして反映されないということ。
>初回は動くんですが、ポストバックするとConnectionStringが元に戻ってしまうらしいんですよ。
そう考えるとConnectionStringが元に戻るんじゃなくて、表示されるデータが戻ってるだけでは？
ConnectionStringをLabelなどに表示してみて、本当に変わっているかどうかチェックしてみたほうがいい
0729728
2009/07/31(金) 00:08:52ID:???System.ArgumentException: 無効なポストバックまたはコールバック引数です。
の理由にはならないね
ただ、ポストバックで特殊なことをしてなければそんなエラーはでないから普通は関係ないはず
0730nobodyさん
2009/07/31(金) 00:14:03ID:dsR5PDEAC#でウインドウアプリ作るときはプロジェクトの設定して
Conditional属性つければ、デバッグ時のみコードを実行させることが
できますが、同じようなことをASPでできないものでしょうか？
#if DEBUGでの切り分けはあんまり使いたくないなぁということで・・・
属性じゃなくても、似たようなことができる方法教えてもらえると助かります。
0731730
2009/07/31(金) 00:16:46ID:dsR5PDEAASP.NETです
言語はC#です
0732nobodyさん
2009/07/31(金) 02:18:59ID:???>そもそもサーバサイドスクリプトがcsに書かれてるのも違和感だし
クライアントサイドの間違いじゃないのか？
サーバサイドのスクリプト（プログラム）が.csに書いてあるのは普通だろう
そのために.aspxと.aspx.csに分離してあるんだから
まあ、サーバサイドとクライアントサイドのコードが混在すると
読みにくくて判読しにくいのは同意するが、これはWEBアプリの宿命的な部分もあるしな
ASP.NETな開発で考えると、そこはコントロールの作成者が苦労すれば、
その利用者は何も考えなくてよい、ってことなんだが．．．最大の成功例はAjaxToolkitか
実際はカスタムコントロールなんて作らんとページロジックに書く場合がほとんどだろうし
作ってもコントロール利用者＝コントロール作成者な場合が多いからなｗ
0733nobodyさん
2009/07/31(金) 19:40:32ID:???WindowsUpdateはクソだな
0734nobodyさん
2009/08/01(土) 09:06:35ID:7MJE4N/Jhttp://www.microsoft.com/downloads/details.aspx?FamilyID=d34f9eaa-fcbe-4e20-b2fd-a9a03de7d6dd&DisplayLang=en
0735nobodyさん
2009/08/01(土) 11:34:44ID:???0736nobodyさん
2009/08/01(土) 11:58:07ID:???携帯向けのことも考えるとMVC以外あり得ん
0737nobodyさん
2009/08/01(土) 13:47:25ID:???0738nobodyさん
2009/08/01(土) 15:10:04ID:???って俺は思ったんだが。
他のフレームワークでのMVC開発全くやったことなかったし。
0739nobodyさん
2009/08/01(土) 15:45:55ID:???MVCならResponse.Writeで全部はき出すのとそんなに変わらん
0740nobodyさん
2009/08/01(土) 15:56:50ID:???0741nobodyさん
2009/08/01(土) 16:01:59ID:???それ以上でもそれ以下でもない。
0742nobodyさん
2009/08/01(土) 16:07:10ID:???0743nobodyさん
2009/08/01(土) 16:12:12ID:???0744nobodyさん
2009/08/01(土) 22:28:24ID:Xxdx6Cb4今までのASP.NETでは、まともに単体テストやろうとしたらかなり面倒だよね。
0745nobodyさん
2009/08/01(土) 23:07:40ID:???0746nobodyさん
2009/08/02(日) 16:46:34ID:Ql7mD23J0747nobodyさん
2009/08/02(日) 21:54:48ID:???これは便利だね
0748nobodyさん
2009/08/02(日) 22:00:36ID:???0749nobodyさん
2009/08/03(月) 00:39:33ID:???0750nobodyさん
2009/08/04(火) 10:35:52ID:???当然だろ常考。こっちは設計書に忠実に実装してるだけですが何か。
ページ切り替えとかの実装を要求されるンかなぁ。
更新系の画面でページ切り替えとか、考えることが増えてマジウザイんだけど。
0752nobodyさん
2009/08/04(火) 14:09:01ID:???0753nobodyさん
2009/08/04(火) 19:43:51ID:???横方向にTextBoxが40×Repeaterで500ﾙｰﾌﾟ、なので入力チェックの実装はそれほど大変では
ないのですが、、、
実際に運用した際の入力の手間については考えていません。
0754nobodyさん
2009/08/04(火) 20:38:23ID:???0755nobodyさん
2009/08/04(火) 20:45:22ID:???でも設計に口出ししなかったんだから仕方ないな
0756nobodyさん
2009/08/04(火) 21:24:45ID:???それがわからないと最適解はわからんよね
NDAとかで具体的に話せないなら、似たような事例で
0757nobodyさん
2009/08/04(火) 22:30:19ID:???ｸﾞﾘｰﾄﾞってGridView？あんまりGridViewを用いるメリットが思いつかない・・・
ちなみに、サンプルに良くある「行毎にある編集ボタンを押して編集モード、編集が終ったら行ごとの更新ボタ
ン押下で再び参照モード」 って挙動は駄目なんで。
ユーザはあくまでExcelへの入力のごときフィーリングを求めてるみたい。
>>755
詳細設計から参加だから、もうどうしようもなかった。
ポストは、xmlに定義した内容を見て、Request.Paramsを分解してDataSetに突っ込むっていう部品を作っ
たんであまり気にしてません。VIEWSTATEは・・・Sessionに突っ込んでるけど、恐ろしいサイズになってそう。
>>756
顧客情報。
1営業担当あたり500人程度を想定してるんで。
0758nobodyさん
2009/08/04(火) 22:36:00ID:???repeater全体にlinkbuttonつけたんですが、
そのどこかの行をクリックするとその行だけ詳細パネルが開いて、他の行もそのまま表示ってしようとしたところ、
パネルは開いたのですが元々あった一覧行が消えてしまいます
何が原因だと思いますか？
0759nobodyさん
2009/08/04(火) 23:01:36ID:???Excelでいいじゃんって言ったらしばかれそうだなｗ
0760nobodyさん
2009/08/04(火) 23:02:09ID:???どういう契約関係かわからんが仕様書段階で忠告があってしかるべき仕様だよな
仕様通りつくって運用上の問題が発生したのなら、当然、別料金で作り直しでしょ
仕様の設計者が社内の人間なら、泣く泣く作り直すしかないね。
設計者に飯でもおごってもらえｗ
それはともかく、初めからマトリクス状に500行あるってこと？
それともユーザを追加していくうちに最大で500行まで増えそうってこと？
前者なら設計が最悪、後者なら20行ごとにページングするしかないね。
各行ごとに編集や削除ボタンを設置しておけば、表全体に対して入力チェック
する必要ないし、PostBackの容量も少なくて済むし。
0761nobodyさん
2009/08/04(火) 23:07:32ID:???>repeater全体にlinkbuttonつけたんですが、
各行に1個のボタンを付けて、それをクリックすると行の詳細が、
パネル（パネルってなに？）に表示されるってことかな？
んで、クリックするとなぜかそのクリックした行のデータだけ
repeaterから削除されてるってこと？
いまいちどういう動作をしてるからわからんので、
記述したプログラムをどこかにupもしくは
操作している最中の動きをスクショでとってどこかにup
0762nobodyさん
2009/08/05(水) 00:32:56ID:???大抵が、パフォーマンスが出ないのは作りがしょぼいだけ。それを仕方ないと言い訳する屑。
googlemapみたいにアジャックスつかって、見えてる部分だけデータを拾ってくるようにして、スク
ロールインした部分は随時データを拾ってくるようにすればいい。
これなら、画面上に見えてるコントロールの数はずっと少なく出来るし、レスポンスも工場する。
0763nobodyさん
2009/08/05(水) 01:14:20ID:???0764nobodyさん
2009/08/05(水) 01:27:35ID:???0765nobodyさん
2009/08/05(水) 01:41:38ID:???0767nobodyさん
2009/08/05(水) 01:49:29ID:???0768nobodyさん
2009/08/05(水) 02:01:41ID:???ASP.NET AJAXを使って実装した
ポストバックして一覧再描画してないって落ちじゃね？
0771nobodyさん
2009/08/05(水) 11:29:00ID:???Excel Services...
0772nobodyさん
2009/08/05(水) 13:09:46ID:???普通、OWC考えないか？
0773nobodyさん
2009/08/05(水) 21:03:42ID:???つ jqGrid(JQuery Grid Plugin)
つ UltraWebGrid(NetAdvantage)
0775nobodyさん
2009/08/06(木) 01:01:32ID:???って書いてなければ、勝手にそんな機能を実装してるわけで要件は変わってる
0776762
2009/08/06(木) 01:16:17ID:???0777nobodyさん
2009/08/06(木) 01:23:02ID:???まあそれはおいといて早く作って見せてくれよ。
実装イメージでもいいぞ。
0778nobodyさん
2009/08/06(木) 01:34:52ID:???>>757は
「詳細設計から参加だから、もうどうしようもなかった。」って記述してるんだから、
すでに詳細設計書が存在してるわけで、この場合の「要件」とは、
その詳細設計書を実現するのに必要な条件のことでしょうよ。
>よう‐けん〔エウ‐〕【要件】
>１ 大切な用事。「―のみ記す」
>２ 必要な条件。「教育者としての―を満たす」
0779nobodyさん
2009/08/06(木) 01:47:15ID:???仮に出来たとしても、cssで非表示させてるだけならhtmlのファイルサイズの削減にはならないから軽くならないし、
ポストするデータサイズも同じだし、むしろスクロールする度にJavaScriptのイベントが発生するから、
ベタに表示させるより重くなるんじゃね？
ASP.NET AJAXでスクロールするたびに動的にコントロールを生成するのなら、
初期に表示されるコントロールが少ないからhtmlのファイルサイズの削減にはなるけど、
スクロールさせるたびにサーバに問合わせてコントロールを表示させてデータを表示させるなんて、
物凄く遅くなるんでないかな。
さらにデータが変更されたテキストボックスが表示エリアから消えた場合、
それを復元する術がないから、非表示になったテキストボックスのデータも
いちいちサーバにポストバックして保存しないといけない。
そんなことするなら、ベタに5万個のテキストボックスを表示させたほうが軽くないか？
0780nobodyさん
2009/08/06(木) 02:03:42ID:???お前にも作れるよ。
0781nobodyさん
2009/08/06(木) 02:16:18ID:???0782nobodyさん
2009/08/06(木) 02:21:31ID:???0783nobodyさん
2009/08/06(木) 02:30:15ID:???遅くなる理由が見つからない。
0784nobodyさん
2009/08/06(木) 02:31:02ID:???どのコントロールが表示状態になったかは取得できないな
従って、絵に描いた餅
Flashかsilverlightなら可能だと思うが
0786nobodyさん
2009/08/06(木) 02:43:39ID:???１つのページに複数のページが表示されるのは機能的に問題
データはいつ削除されるか追加されるかわからないんだから、
最悪の場合、50ページすべての行に同じデータが表示される可能性がある
そして後からデータが追加されて51ページ目が発生した場合にも対応できない。
0787nobodyさん
2009/08/06(木) 05:47:17ID:???後はAJAXなりで適当にスクロールしてるように見せかければいい
>>786
そういったことを防ぐために排他制御って考え方があるんだが
機能的に問題かどうかは、ロックがどうなってるかによる
普通のWEBアプリに見られるような楽観的ロックなら問題かもしれないが
適切なロックがあれば問題ない
そう考えると元の設計は、もしかするとロックするから
全項目を１画面に表示したいのかも知れない．．．と思ってみたがたぶん違うなｗ
0788nobodyさん
2009/08/06(木) 08:19:08ID:???まずはセッションとかでどうにかならないか考えるだろ。
あと数を絞れば速くなるに決まってるなんて言ってるのがいるが、
ホントに試してみたのかい？
0789nobodyさん
2009/08/06(木) 08:21:18ID:???実は最初から全部読んだ方がスムーズだったなんてことはないのか。
0791nobodyさん
2009/08/06(木) 13:11:14ID:???配置して、画面上には常に固定のコントロールを配置。
で、スクーロル下をボタンをクリックしたら
txtbox2の内容をtxtbox1に
txtbox3の内容をtxtbox2に
txtbox4の内容をtxtbox3に
txtbox5には新規にDBから取得した内容を新規にセット
ってやれば、画面上には常に一定数のコントロールしか表示されないし、PostBackerの処理
も簡単で一石二鳥じゃね？
0792nobodyさん
2009/08/06(木) 14:01:14ID:???突っ込まれると思ったｗ
詳細設計時に存在するには内部設計書だな。すまんかった。
つーかいちいちプログラムと関係ないところのツッコミしかできないのかよ？
吐いた唾を飲み込むの？死ぬの？
唾飲み込むぐらいじゃしなねーけどｗｗｗ
0793nobodyさん
2009/08/06(木) 14:14:19ID:???Webアプリで1画面表示する間、ずっとデータベースをロックしろとでも？
この場合、いつ最下部のページを表示する画面にスクロールかわからないから、
ページをみてる間はずっとロックかけてる必要がでてくるわけだが。
他人が使う可能性や、ブラウザのページの切り替わりの
可能性なんて考えたら、そんなロックは実用上不可能だろ。
結局、重複させない、または表示途中で削除されたデータに対応するには
クライアント側（ポストバックかクッキー）かサーバ（セッション）でデータを持ち続け、
最終的に楽観的ロックで確認するしかない。
>>791
2万行あったら最下部までたどり付くのに2万回クリックすんの？ｗｗ
そうなると100行単位とかのページ単位で切り替わるほうがいいんじゃね？
それでも200回クリックじゃつらいから、10ページ前に戻る、10ページ後に進む的な
ページングのボタンを設置したほうがいいんじゃね？
そうなると>>768で答えは既にでてる。
Ajax、XBAP、Silverlight、Flashなんでもいいから
ユーザビリティーの良いのに作り直す事だね。
0795nobodyさん
2009/08/06(木) 15:40:39ID:???ああ、読んでるよ。
設計書通りに作ったんだろ。
設計書見た段階でこりゃ動かんわってわかってたんなら
その段階で何かするべきなんだよ。
ちゃんとせんから余計な後戻りが発生するんだ。
■ このスレッドは過去ログ倉庫に格納されています