1

そのため、多くのページで、サーバー上に構築されている標準の「グリッド」(asp:table) を持つサイトを構築しました。多くのページでは、これらのグリッドに標準のリンク (「編集」、「削除」など) が含まれています。または複数選択操作用の行ごとのチェックボックス。

グリッドは、イベント処理 (CommandEvents) のために動的サーバー コントロールにアクセスできるように、ページ ライフ サイクルの早い段階で構築する必要があります。たとえば、コマンド イベント (コマンド引数でレコードの ID を渡す) を発生させる [レコードの編集] ボタンは、page_load 時またはその前に作成する必要があります。そうしないと、イベントは処理されません。これは問題なく機能しますが、事前にグリッド全体を構築することはあまり効率的ではありません。たとえば、アクションを実行してからページを離れる操作の場合、レンダリング/必要になる前にページを離れるためだけにグリッド全体を構築するのはばかげています。または、アクションがテーブルからレコードを追加または削除する場合、テーブルは既に構築されており、まったく 2 回構築する必要があります。

私の質問は、デザイン フローに関して、ここに欠けているものがあるかどうかです。これは、CRUD タイプのサイトの標準的なシナリオだと思います。基本的に、冗長/不要なサーバー処理を最小限に抑えて、動的に構築されたコントロールからイベントを処理できるようにしたいと考えています。

標準の html コントロールを動的に構築し、クライアント側スクリプトを使用して __postback() を実行し、"アクション" と "ID" の値を渡す方がよいでしょうか。これにより、たとえば、グリッドにアクセスする前に Page_Load() でアクセスできます。構築されますか?動的 ASP サーバー コントロールにアクセスする前に Request.Form 情報を使用できるという事実を利用する必要がありますか? 動的コントロールのプロパティに (動的な html 文字列を作成するのではなく) よりオブジェクト指向の方法でアクセス/設定する機能が好きですが、この場合は効率が優先されると思います。

4

1 に答える 1

1

したがって、私は先に進み、__EVENTTARGET および __EVENTARGUMENT リクエスト値を利用して、ページの大量の読み込みが完了する前に処理したいサーバー イベントを処理しました。WebControls セットの代わりに HTMLControls セットのコントロールを利用しても、動的コントロールの構築に違いはありませんでした。

プラス面は、すべての動的コンテンツが構築され、ビュー ステートが処理された後に発生する CommandEvents に依存するのではなく、ページ ライフ サイクルの任意の場所で単純な switch ステートメントでイベントをキャッチできることです。

本質的に独自のイベント処理ルーチンを作成するよりも、.net「フォーム」環境に組み込まれたイベント処理の性質を利用する方が好ましいと考えましたが、これにはいくつかの例外があるようです。

于 2013-10-22T15:31:55.530 に答える