09/07/23 17:34:37
>>653
別に、あなたのやり方を否定してるわけでも、自分のやり方を推奨してるわけじゃなくて、
相反する考え方があるという事なんで、あくまで一般論の話ね。
どんな想定かわからないけど、複数のものを変更しなくちゃいけない場合、
その時点で変更し忘れ等のミスが発生する可能性が高まるということ。
例えばwebサーバが複数あるとか。
>上の B = D で、これはどちらも同じバージョンのDLLなのですが・・。
ASP.NETのプロジェクトの開発で何か変更になったとき、
サブプロジェクトDのDLLを変更するのはいいけど、
その時点でBに反映させなければ、異なるバージョンの物でそれぞれが動作している
という気持ち悪い状況になるでしょ。
そういうやり方をしてるなら、Dが変更されたら、変更されたDLLをBとして反映する
必要があるから、結果的に複数のものを変更する必要があるんじゃないの？という話。
BとDが異なるバージョンのDLLで動作しているのが気持ち悪くない人というのは
そういう意味。
655:627
09/07/23 18:10:04
>>654
ああ、なるほど。意味がわかりました。
> その時点でBに反映させなければ、異なるバージョンの物でそれぞれが動作している
> という気持ち悪い状況になるでしょ。
確かにそれはそうですね。
私はdeployの作業自体はスクリプトを書いて自動化してあるのですが、そこに書き忘れたら、
というのはありますね。
656:nobodyさん
09/07/23 18:33:32
というか、Linq To SQLは終了の方向だから、
EntityFrameworkのほうで頑張るしかないな
657:nobodyさん
09/07/23 21:15:25
>652
DBMSは導入先の環境・都合で変わりうるでしょ。開発言語に関してはそれはまず有り得ない。
大体、「開発言語を変更しろ」なんてのは事実上「１から作り直せ」と同義なんだから、
ストアド部分だけ流用できたって、たいして嬉しくないよ。
658:nobodyさん
09/07/23 21:33:24
DBMSが具体的に何を差してるかわからんが、
データベースのソフト（MySQLたのOracleだのMSSQLだの）を差してるなら、
導入先の環境、都合でこれらがそんな頻繁に変わるか？
データだって移行せにゃいかんし、
そもそもクエリだってデータベース間で関数名や、その引数なんかに違いがあるんだから、
言語が統一ならどんなDBであってもまったく変わらないなんて完全な錯誤だと思うんだけど。
あるシステムでデータベースを異なる製品に変更しろなんて要求があったら、
1から作り直すのと同じだと思うし、あまりの仕打ちにそれ以上に腹が立つわｗ
659:nobodyさん
09/07/23 22:08:49
いつだってフルスクラッチ大好きな俺は大歓迎だ！
ただし、金と時間はくれよな！
660:nobodyさん
09/07/24 12:02:04
ASP.NETで開発しています。
JavaScriptで使っているデータを1日1回、DBから生成して .js ファイルとして書き出しておくことを考えています。
その .js ファイルを IIS7でホスティングすることになるのですが、
「DBから生成して .js ファイルとして書き出しておく」ときに、テンポラリに書き出して、
.NET FrameworkのFile.Copy(src , dst, overwrite = true)で前のファイルに上書きしようと考えています。
ところが、このファイルの書き出し中にこのファイルをクライアントブラウザから要求されて
IIS7が読み込もうとしたとき、コピー中の中途半端なファイルがクライアントブラウザに渡されます。
この挙動は望むものではなくて、出来れば、コピー前の古いファイルか、コピー後の新しいファイルかの
どちらかをクライアントブラウザに渡して欲しいのです。
これはIIS7の設定で解決するのでしょうか？それとも、File.Copyを使うのが良くないのでしょうか？
661:nobodyさん
09/07/24 15:08:26
rename してからコピーして rename
コピー中はファイル存在せず
662:nobodyさん
09/07/24 15:10:12
いや、少し違うか
hoge.new で予め作っておく
hoge.js → hoge.bak にリネーム
hoge.new → hoge.js にリネーム
hoge.bak を削除
663:nobodyさん
09/07/24 17:35:30
>>660
javascriptって.jsしか無理なんだっけ？
自分なら.jsファイル（もしくは変更されるデータ）をデータベースから取得し、
アクセスがあるたびに動的に生成するな
ファイルを作成するプログラムが、バッチ処理の役割も果たしていて、
日に1回の集計処理を行ってるとすると、若干厄介かもしれないけど
664:660
09/07/24 18:02:37
>>661-662
それだと hoge.js → hoge.bakにrename中にアクセスされるとnot foundになるのが
嫌なのです。その2つのrenameは実際にはほぼatomicに行なわれるとは思うのですが。
>>663
確かにデータベースから流しても良いのですが、そのオーバーヘッドが嫌なのです。
(自己解決)
NTFSは次のようにtransactionをサポートしているらしいので
面倒ですが、これを使うことにします..。
Enhance Your Apps With File System Transactions
URLﾘﾝｸ(msdn.microsoft.com)
665:nobodyさん
09/07/24 18:24:53
おーNTFSでファイルのトランザクションができるのかｗ
同じ.jsだとIEでキャッシュ扱いされそうな気がするんだが、その辺はどうなんだろ
レポート頼む
666:660
09/07/24 19:23:06
>>665
> 同じ.jsだとIEでキャッシュ扱いされそうな気がするんだが、その辺はどうなんだろ
それはIISのファイルのexpireの設定次第だと思います。
667:nobodyさん
09/07/24 19:40:49
へーその都度、生成されるaspxでも？
668:660
09/07/24 20:25:23
>>667
URLﾘﾝｸ(forums.techarena.in)
にサンプルがありますがファイルの拡張子ごとにexpireする時間を設定できるようです。
このうちjsのexpireを1hourぐらいに設定しておけば、>>665 の問題は解決するのではないかと。
669:nobodyさん
09/07/24 22:19:14 1HXeI2xc
生成し終わったファイルをコピーして別のファイル上書きするだけなら
そんな問題おきなさそうだけどなぁ。
ファイルシステム書き換えるだけでしょ。
Windows の Copy コマンドとか使えないのかな。
670:660
09/07/24 23:37:28
>>669
> 生成し終わったファイルをコピーして別のファイル上書きするだけなら
> そんな問題おきなさそうだけどなぁ。
起きます。System.IO.File.Copyでコピーした場合、ファイルコピーが開始されると
同時に、クライアントブラウザへの古いほうのファイルの転送が中断され、
結果として中途半端なファイルがクライアントブラウザに渡されます。
WindowsのCopyコマンドというのが何を指しているのかわかりませんが、
DOSプロンプトのcopyコマンドのことでしたら、これと同じ挙動のようです。
671:nobodyさん
09/07/25 01:29:42 WtyVOn10
＞自分なら.jsファイル（もしくは変更されるデータ）をデータベースから取得し、
＞アクセスがあるたびに動的に生成するな
うわ、死んだ方がいいなこいつｗ
672:nobodyさん
09/07/25 02:03:30
>>671
なんで？
それが駄目ならデータベースからデータを取得して、
動的に中身を生成するasp.netの全否定になると思うけど？
673:nobodyさん
09/07/25 02:15:27
ASP.NETの動作にDB接続が必須だったとは初耳だ
674:nobodyさん
09/07/25 02:19:13
ストアドってよく使われるもんなの？
個人的には全部ソースで作ればいいじゃんと思うんだけども。
675:nobodyさん
09/07/25 02:27:23
>>673
データベースからデータを取得してhtmlを生成する仕組みで動作してる
aspx全般のことを言ってるのに、asp=db必須なんて言うのは論理のすり替え
676:nobodyさん
09/07/25 03:11:46
>>674
ストアドに限らず、viewやテーブル値関数、トリガーを含めてなら便利だし、結構使う
問題なく動作してるなら、別にソースからでもいいんじゃない？
メリットはデータベースを一つのオブジェクトとみた場合、データの操作はデータに近いところで行うという、
可能な操作や状態のみ閲覧でき、実装を隠蔽できるOOPのメリットと併せて考えればわかりやすいと思うけど
あとは複数クエリの実行なら、ストアドのほうが処理が速いということかな
ASP.NETとはいえ、DBとWEBサーバは別だろうから、DB-WEB間のネットワークトラフィックを最低現にできるメリットもある
677:nobodyさん
09/07/25 03:12:12
>>675
んじゃーお前は何でもかんでもDBに突っ込んで毎回取りに逝けばいいよ。
678:nobodyさん
09/07/25 08:21:37 BV/bwvMa
俺頭悪いから
>>675 からなんで >>677 な意見が出るのか理解できない…。
>>673 はまぁ極端ではあるけど
>>672 の文章自体誤解を受けかねない部分はあるからまぁ仕方ないのかなって気はするけど。
まぁでもなんかとにかくかみつきたくてかみついてるような印象はあるか。
679:nobodyさん
09/07/25 11:37:23
>>671はjs「ファイルを動的に生成」ってところに
突っ込みたかったんだと思ったが…
680:nobodyさん
09/07/27 09:33:53
>>664
どこまで極めないといけないのか知らんが
js ファイルを作成する都度、別ファイル名にして、
aspx 側で食わせる js ファイル名を動的に変更させたらどう？
681:sage
09/07/27 10:06:33
TextBoxにもLabelにもなるユーザコントロールって作れないんスかね？
ReadOnlyのﾌﾟﾛﾊﾟｰﾃｨをtrueにすればLabel、falseにすればTextBox、みたいな。
TextBoxを変更不可にするんじゃどうしても見た目的に駄目なケースがあるんで。
682:nobodyさん
09/07/27 10:34:22 lA2VJ4lQ
動的にコントロール追加すればいいんじゃないの
683:nobodyさん
09/07/27 14:43:15
Repeaterでテキストボックスを動的に生成しています。
ボタンが押されたら内容をチェックして、何らかのエラーがあればエラーのあったテキスト
ボックスの背景色を変えたいんですが、方法が分かりません。
テキストボックスは動的に生成しているので、 プロパティで変更することも出来ないみたいで。
684:nobodyさん
09/07/27 15:31:56
>>681
作れなくはないが、見た目だけならCSSで無理か？
>>683
FindControl
685:nobodyさん
09/07/27 15:33:45
>>681
TextBoxとLabelを配置したUserControl作って、ReadOnlyプロパティとTextプロパティを作って、
TextBox.Visible = !ReadOnly Labe.Visible = ReadOnlyすればいいじゃない
>>683
public List<TextBox> TextBoxList = new List<TextBox>();
protected void Page_Load(object sender, EventArgs e)
{
for (int i = 0; i < this.Repeater1.Items.Count; i++)
{
RepeaterItem ri1 = this.Repeater1.Items[i];
TextBox textBox = (TextBox)ri1.FindControl("TextBox1");
TextBoxList.Add(textBox);
}
}
あとはお好きにどぞ
686:nobodyさん
09/07/27 15:59:05
>>685
683は、validationをclient-sideで行なって、かつ、TextBoxとLabelとの切り替えもclient-sideで
行ないたいということなんじゃない？
まあJavaScriptで書くしかないわな・・。
ASP.NET、client-sideで処理するためのtool setが用意されていないので
何かとJavaScriptを書かないといけなくて面倒なんだな。
687:nobodyさん
09/07/27 17:02:42
このスレの>>200近辺にあるjQueryを使えば大丈夫
688:nobodyさん
09/07/27 17:09:31
>>687
何がjQueryで大丈夫なのかは知らないが、
あまりにjQueryとの親和性が悪いので
ASP.NET4.0ではjQueryを統合するとか何とか。
689:nobodyさん
09/07/27 17:42:49
×あまりにjQueryとの親和性が悪いので
○ASP.NET AJAXがあまりにjQueryとの親和性が悪いので
690:nobodyさん
09/07/27 20:19:11
>>686
UserControl、ReadOnlyプロパティから考えるにサーバコントロールじゃないの？
そもそもClientでValidationを行うのが間違いだし
超簡単にやるなら、こんなでいいんじゃない。
<%@ Control Language="C#" AutoEventWireup="true" CodeFile="WebUserControl.ascx.cs" Inherits="WebUserControl" %>
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
<asp:Label ID="Label1" runat="server" Text="Label" Visible="False"></asp:Label>
public partial class WebUserControl : System.Web.UI.UserControl
{
public bool ReadOnly
{
get { return this.Label1.Visible; }
set
{
this.Label1.Visible = value;
this.TextBox1.Visible = !value;
}
}
public string Text
{
get { return this.Label1.Text; }
set
{
this.Label1.Text = value;
this.TextBox1.Text = value;
}
}
}
691:nobodyさん
09/07/27 21:07:41
>>690
> そもそもClientでValidationを行うのが間違いだし
何故間違いなの？余計なトラフィック増やしたくないから、まずclient-sideで行なって、
サーバーはサーバーで再度validationを行なうのが常識でしょ。
692:nobodyさん
09/07/27 21:20:16
>>691
>何故間違いなの？
ああ正確にはClient「だけ」だな 言葉足らずですまんかった
>余計なトラフィック増やしたくないから、まずclient-sideで行なって、
>サーバーはサーバーで再度validationを行なうのが常識でしょ。
入力内容をポストしてValidateするのと、JavaScriptでチェックするのの、
どちらが容量が少ないかだけの観点なら、失敗される予想回数と、
Postされるデータの容量と、Validationに必要なJavaScriptの容量が関係するから、
一概にClientでチェック＝トラフィックが低いとは言えないけどね
693:nobodyさん
09/07/27 23:45:26
>>692
> 一概にClientでチェック＝トラフィックが低いとは言えないけどね
ああ、なるほど。トラフィックという観点ではそうだね。
実際は、ASP.NET ajaxでも、アクセスされるごとにサーバー側では
モデル等を再構築するのでアクセスごとのサーバーの負荷は並々ならぬものがあるので
なるべくならclient-sideで、というのは信念としてあるわけだけど。
694:nobodyさん
09/07/27 23:49:45
>>671
動的生成したjsの内容をいキャッシュしとけばいいよ。
ってか良くやる方法だよ。
あんまりキャッシュとか活用されないことが多かったりするけどね。
695:nobodyさん
09/07/27 23:52:13
クライアントサイドの検証コードなんてほとんどキャッシュされるから、
実質的にはクライアントでも検証を行う方が有利なことが多いんじゃないかと思うけどね。
696:nobodyさん
09/07/27 23:55:29
>>694の続き
jsファイルでやりたいなら、ashxハンドラなどで、ファイルを読んでキャッシュして
リクエスト時にはそれを返す方法でもいい。
ファイルの更新時刻を見て、例えば一秒以内程度なら前の結果を返すとか自由に制御できる。
697:nobodyさん
09/07/28 00:30:07
>>695
そこらへんまで行くと、完全に実装にかかるコストやなんやらとのトレードオフ
ISDNとか56kモデム全盛の時代は帯域が狭いから、
トラフィックも考慮されてたけど、今じゃよほど特殊な環境やページでなければ
トラフィックを気にして設計することなんかほとんどない
その証拠に、画面を描画するcssも、よくあるライブラリを記述するjsも、
必要な部分だけincludeしてるわけじゃなく、サーバに対して１つだけを設定してるだけでしょ
さらに言えば、今時、JavaScriptで入力チェックしてるサイトも少数派になってる
どうせ両方に実装するのならJavaScriptのほうは不必要という考えもできるからね
698:nobodyさん
09/07/28 02:26:18 FCPdlHYK
ASP.NETのValidatorが自動生成するスクリプトでのチェックならいいが、
自力でScriptをゴリゴリ実装するのは後で他人が多大なる被害を被るのでやめてくれ。
んなもんサーバ側でやればいいだろーが。
699:nobodyさん
09/07/28 08:13:31
前任者のソースに__doPostBackを
自前の関数から呼んでるのとかあったな
700:nobodyさん
09/07/28 09:19:48
つーか、client側にゴリゴリ処理を書くとか、むしろｱﾘｴﾈｰとか思うんだが。
そんなの、いくらでもエンドユーザが改変可能じゃん。
原則は、全部のデータをサーバに丸投げして、あとはサーバ側でチェック。
仮にclient側のjavascriptでチェックしてても、全く同じチェックをサーバ
側でも再実施。だったら実装の手間隙考えて、微々たるトラヒックの事なん
か気にしない。（＝clientではチェックしない）
701:nobodyさん
09/07/28 11:02:01
なんでajaxが出てきたと思ってる
ってまあ言いたいことは分かってるんだけどな
702:Appri童貞
09/07/28 17:08:04 sYPKb5BW
エラー発生アプリケーション xxxxxxxxxxxx.exe、バージョン 1.0.0.0、
エラー発生モジュール kernel32.dll、バージョン 5.2.3790.4480、
エラー発生アドレス 0x0000bef7
こんなログ出た人いますか？
703:nobodyさん
09/07/28 17:20:27
>>702
聞く前にぐぐれ
kernel32.dll 0x0000bef7 5.2.3790.4480
でぐぐったら、1つ目のリンクにSystem.OutOfMemoryExceptionがどうとか書いてあるぞ。
704:Appri童貞
09/07/28 17:33:53 sYPKb5BW
ありがとう＾＾
705:nobodyさん
09/07/28 19:06:55
死ね
706:nobodyさん
09/07/28 19:48:08
むしろ生きろ
707:nobodyさん
09/07/29 03:14:53 S6cUwBjX
>>699
ゴメン、今のプロジェクトで __doPostBack 書いてる。
708:nobodyさん
09/07/29 03:30:54
クライアントスクリプトからポストバックする方法って普通になかったっけ？
別に問題ないと思うけど
709:nobodyさん
09/07/29 07:38:21
ASP.NET2.0以降ならICallBackEventHandlerで出来るな。
しかしだからって、__doPostbackを自前で呼ぶことが許容できるかというと微妙。
十中八九、代替する方法があるだろうしな。
710:nobodyさん
09/07/29 19:40:32
リンクをcssで無効にして、Scriptでクリックすることにするという方法が簡単らしいね
ClientScriptで動作させることが前提の非ビジュアルコンポを作ったら楽かもしれない
つか、ICallBackEventHandler試したことないから、やってみようかな
711:nobodyさん
09/07/29 20:30:18
MaskedEditExtenderについて、教えて下さい。
<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"では問題ありませんでした。
これは何かの制限でしょうか？
712:nobodyさん
09/07/30 01:45:47 6Jkou0XR
__doPostback実装してもいいじゃん。ダメな理由って何がある？
713:nobodyさん
09/07/30 02:45:19
ServerControlの配置と、自分で記述するClientScriptの相関関係がまったくなくなるのが問題と言えば問題
714:nobodyさん
09/07/30 03:29:35
まったくなくなるかどうかはクライアントスクリプトの実装次第だと思うが
コールバックとポストバックは似て非なるものだから
どうしてもポストバック使いたいときもあるだろう
つか1.1まではそれしかなかったしな
ダメな理由はない
まあ、見通しが悪くなることが問題といえば問題
だがそれはコールバックでも同様
715:nobodyさん
09/07/30 06:36:24
コントロール名を変更しても、JavaScriptのほうまでは変更してくれないでしょ
だから相関関係が無くなる
716:nobodyさん
09/07/30 07:36:36
それは最初からJavascriptが間違ってるだろ。
717:nobodyさん
09/07/30 08:11:07
>>712
もちろん最終的には開発者の自由なんで、あくまで俺の見解として。
まず、前にも書いたがそんなことをしなくても
十中八九、正攻法で解決できると予想される。
また、他に方法がなかったとしても、
果たして裏道を使ってまで解決する要件か疑問が残る。
次に、そのような組み方は「らしくない」と感じる。
極端な例えだが、Responce.WriteでHTML出力してたり、
GridViewに仕込まれた無数のhiddenを見ている気になる。
最後に、フレームワークを使っていて、
ハッキング(裏道の利用)に手を染めたら負けかなと思ってる。
718:nobodyさん
09/07/30 14:41:52
>>716
違う
最初は正しかったが、IDEでaspxの何かを変更をすることで、
結果的に間違ったものになったということ
基本的にIDEの機能や本来のやり方と無縁だからこうなる
719:nobodyさん
09/07/30 18:15:21
>>715
それはスクリプトでIDなんかをハードコーティングするから悪い
スクリプトをサーバコントロールで動的に生成して出力するようにすれば
サーバコントロールとの関係は崩れない。これがAPS.NET流じゃないかな
まあ、__doPostback直接書くのはお勧めじゃない。GetPostBackEventReference使えと
.aspx側(html側)にスクリプト書いたとしても、動的に変更する必要があるところは
実行時バインド式で書いとくのが通常
720:nobodyさん
09/07/30 21:07:58
>スクリプトをサーバコントロールで動的に生成して出力するようにすれば
これが読みにくくて判読しにくいんだよな
そもそもサーバサイドスクリプトがcsに書かれてるのも違和感だし
うまく解決できないものか
721:nobodyさん
09/07/30 21:46:45
aspx側に書けばいいじゃん。
722:nobodyさん
09/07/30 22:11:19
ASP.net 2.0 なんですが、GirdViewの「編集」（正確には「更新」）のイベントハンドラを独自に記述する方法はあるでしょうか？
GridViewによるマスタメンテを実装しているのですが、GridViewはEnableViewStateをfalseにしないと更新が出来ないそうですね。
現在、ロジック側でConnectionStringを設定するつくりになっているので、EnableViewStateがtrueでないと動かないのです。
ということで%一行目%しかないかと思ったのですが、どこか参考になるURLなどご存知の方がいらっしゃれば、ご教授いただければ幸いです。
よろしくお願いします。
723:nobodyさん
09/07/30 22:18:30
>GridViewはEnableViewStateをfalseにしないと更新が出来ないそうですね。
そうなの？初めて聞いた。
>ロジック側でConnectionStringを設定するつくりになっているので、EnableViewStateがtrueでないと動かないのです。
そうなの？これも初めて聞いた。
724:nobodyさん
09/07/30 22:21:01
ゴメン、意味が分からない。
同じ環境でGridViewから更新処理してるが、EnableViewstateはTrueのままだぞ。
あと編集処理は通常CommandNameがEditであって、
更新はUpdateだから同じものでも無いはずなんだが。
まぁイベントハンドラならOnCommand辺りでフックすればいいんじゃないか。
と、ここまで書いて思い付いたが、
もしかしてObjectDataSource等をかまさずに
直接DataSourceにオブジェクトを割り当ててるとか？
725:nobodyさん
09/07/30 22:26:48
今テストしたけど、GridViewのEnableViewState=trueで更新できるな
VS2008+MSSQL2005
726:nobodyさん
09/07/30 22:41:33
エスパーすると
IsPostBackがtrueの時にDataBindするとイベントが発生しないということと、
ポストバックしてEnableViewStateがtrueの時だと、
取得時のデータと異なる可能性があるというデータの整合性や楽観的ロックの
関係とごっちゃになってるような気がする。
727:722
09/07/30 23:43:56
>>723-726
というと、これはガゼ？
URLﾘﾝｸ(bbs.wankuma.com)
URLﾘﾝｸ(yaplog.jp)
(1)削除は出来る
(2)更新も、少なくともSQLは流れてる
※UpdateCommandのSQL文弄るとエラーになるので
から、画面から入力した内容がUPDATE文に流れていないのだと判断したのですが・・・。
>>723
>>ロジック側でConnectionStringを設定するつくりになっているので、EnableViewStateがtrueでないと動かないのです。
>そうなの？これも初めて聞いた
初回は動くんですが、ポストバックするとConnectionStringが元に戻ってしまうらしいんですよ。
Page_loadで毎回代入してるはずなんですけどね・・・。
728:nobodyさん
09/07/30 23:58:28
>>727
>というと、これはガゼ？
それは、GridViewにデータをバインドした後に、誰かがデータを変更した場合の話
初回アクセス時にデータを取得し、それ以降はサーバとブラウザの間でポストバックして、
データを持ち回りしているので、その間にデータベースのデータが変更されても、
変更されたデータとして反映されないということ。
>初回は動くんですが、ポストバックするとConnectionStringが元に戻ってしまうらしいんですよ。
そう考えるとConnectionStringが元に戻るんじゃなくて、表示されるデータが戻ってるだけでは？
ConnectionStringをLabelなどに表示してみて、本当に変わっているかどうかチェックしてみたほうがいい
729:728
09/07/31 00:08:52
ああ、ごめん上のレスは却下
System.ArgumentException: 無効なポストバックまたはコールバック引数です。
の理由にはならないね
ただ、ポストバックで特殊なことをしてなければそんなエラーはでないから普通は関係ないはず
730:nobodyさん
09/07/31 00:14:03 dsR5PDEA
ASPでデバッグモードの時のみコードを実行させることってできます？
C#でウインドウアプリ作るときはプロジェクトの設定して
Conditional属性つければ、デバッグ時のみコードを実行させることが
できますが、同じようなことをASPでできないものでしょうか？
#if DEBUGでの切り分けはあんまり使いたくないなぁということで・・・
属性じゃなくても、似たようなことができる方法教えてもらえると助かります。
731:730
09/07/31 00:16:46 dsR5PDEA
あ、失礼しました
ASP.NETです
言語はC#です
732:nobodyさん
09/07/31 02:18:59
>>720
>そもそもサーバサイドスクリプトがcsに書かれてるのも違和感だし
クライアントサイドの間違いじゃないのか？
サーバサイドのスクリプト（プログラム）が.csに書いてあるのは普通だろう
そのために.aspxと.aspx.csに分離してあるんだから
まあ、サーバサイドとクライアントサイドのコードが混在すると
読みにくくて判読しにくいのは同意するが、これはWEBアプリの宿命的な部分もあるしな
ASP.NETな開発で考えると、そこはコントロールの作成者が苦労すれば、
その利用者は何も考えなくてよい、ってことなんだが．．．最大の成功例はAjaxToolkitか
実際はカスタムコントロールなんて作らんとページロジックに書く場合がほとんどだろうし
作ってもコントロール利用者＝コントロール作成者な場合が多いからなｗ
733:nobodyさん
09/07/31 19:40:32
VS2008SP1のセキュリティがあたらねぇ
WindowsUpdateはクソだな
734:nobodyさん
09/08/01 09:06:35 7MJE4N/J
ASP.NET MVC 2 Preview 1
URLﾘﾝｸ(www.microsoft.com)
735:nobodyさん
09/08/01 11:34:44
mvcは要らない子
736:nobodyさん
09/08/01 11:58:07
海外ではMVCに移行してきてると思うけど
携帯向けのことも考えるとMVC以外あり得ん
737:nobodyさん
09/08/01 13:47:25
ASP.NET for Mobilesはやれば出来る子
738:nobodyさん
09/08/01 15:10:04
ASP.NET MVCちょっと使ってみて、やべー、使いやすい！
って俺は思ったんだが。
他のフレームワークでのMVC開発全くやったことなかったし。
739:nobodyさん
09/08/01 15:45:55
コードビハインドで事足りる
MVCならResponse.Writeで全部はき出すのとそんなに変わらん
740:nobodyさん
09/08/01 15:56:50
今更Web Forms vs MVCみたいなこと言ってんのかよ
741:nobodyさん
09/08/01 16:01:59
ASP.NET MVCはLAMP対策。
それ以上でもそれ以下でもない。
742:nobodyさん
09/08/01 16:07:10
使いやすい云々よりjQueryフレンドリーなのが大きい
743:nobodyさん
09/08/01 16:12:12
苦肉の策って奴だなLAMP方式
744:nobodyさん
09/08/01 22:28:24 Xxdx6Cb4
ASP.NET MVCは単テがしやすいとか聞いたがそうなの？
今までのASP.NETでは、まともに単体テストやろうとしたらかなり面倒だよね。
745:nobodyさん
09/08/01 23:07:40
つVisual Studio Team Edition for Software Testers
746:nobodyさん
09/08/02 16:46:34 Ql7mD23J
URLﾘﾝｸ(www.netdive.jp)
747:nobodyさん
09/08/02 21:54:48
↑
これは便利だね
748:nobodyさん
09/08/02 22:00:36
昔のASP?
749:nobodyさん
09/08/03 00:39:33
っつーかマルウェア検出されるんだけど
750:nobodyさん
09/08/04 10:35:52
画面が重いとかクレーム付けられてンだけど、画面上にLabelとTextboxが5ﾏﾝｺも載ってりゃ
当然だろ常考。こっちは設計書に忠実に実装してるだけですが何か。
ページ切り替えとかの実装を要求されるンかなぁ。
更新系の画面でページ切り替えとか、考えることが増えてマジウザイんだけど。
751:nobodyさん
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
ああ、読んでるよ。
設計書通りに作ったんだろ。
設計書見た段階でこりゃ動かんわってわかってたんなら
その段階で何かするべきなんだよ。
ちゃんとせんから余計な後戻りが発生するんだ。