最近では、DWZ のネイティブ テーブル ページングがプロジェクト開発で使用されることはほとんどなくなり、jqgrid や Grid などのサードパーティのデータ バインディング テーブル プラグインがよく使用されています。プロジェクトで必要な場合は、DWZ 独自のテーブルを使用する必要があります。 🎜>
次にコードを見て、DWZ でのテーブル ページングの使用方法を詳しく説明します。MVC でのテーブル ページングの実装方法を次に示します。
?
プロパティの紹介
targetType: バインディング メソッド。DWZ には "navTab" と "dialog" の 2 つのメソッドが用意されています。名前が示すように、ページングがタブ ページ上にあるのか、ポップアップ レイヤー上にあるのかを意味します。
totalCount: データの総行数
numPerPage: 現在のページのデータ行数
pageNumShown:総ページ数
currentPage: 現在のページ番号
@using (Html.BeginForm("BidPrjList ", " TbUnify", null, FormMethod.Post, new { id = "pagerForm" }))
{
}
DWZ の下のページング フォームには ID を追加する必要があることに注意してください="pagerForm " プロパティ。それ以外の場合は実行されません。 DWZ でのテーブルのページングの本質は、ページング メソッドをフォーム送信の形式でバックエンドに渡し、バックエンドがパラメーターを受信してページング情報を取得することです。例:
Request.Form["numPerPage"]
ページング情報フォームを取得する値は、View の pagerForm フォームで定義した隠しテキスト フィールドの名前です。バックグラウンドで受信した後、データ ソースからページング データを要求します。その後フロントデスクに戻ります。
ここには小さな問題があります。初めてこのページに入ったとき、現在のページングのフォーム送信イベントをトリガーできません。そのため、上で ViewBag.numPerPage の動的割り当てを定義しました。各ページに分割され、フロントエンド インターフェイス ページング スタイルを定義するだけで、実際のデータはバインドされていないため、フロント デスクから渡されたページング情報をバックグラウンド データ ページングの基礎として使用する必要があるため、フロント デスク ページングデータと一致する可能性があり、混乱を引き起こすことはないことに注意してください。
実際のプロジェクトの開発では、必ずテーブルとフィルター条件を組み合わせます。DWZ のテーブルに制限条件を渡す方法も、上記と同様に、渡す必要がある隠しテキスト フィールドを追加するだけです。ページング フォームに送信します。例:
このようにして、受信したフィルター条件をバックグラウンドで受け入れることができます。
DWZ のテーブル ページングの本質は、現在のタブ ページのデータを再ロードすることです。これにより、ページングと制限が併用されている場合、ページの再ロード後にフィルターが発生します。条件は失われます。ここでの解決策は、フィルター条件に値が割り当てられるたびに、それが空であるかどうか、およびフィルター条件を追加するかどうかをバックグラウンドで判断することです。皆さんもぜひ注目していただければと思います。
最後のポイントである targetType は、上で紹介したもので、現在のページング メソッドとページングが本質的にタブ ページの更新であることを示しています。そのため、テーブルを含むビュー レイヤーを部分ページとして非同期でロードすると、次のことがわかります。 DWZ のページング コントロールは表示されないため、ページングは実行できません。$.load または @Html.Partial を使用する場合は、ページングごとにタイプを指定する必要があると上で説明しました。最初のページの、これも DWZ の欠陥です。結局のところ、DWZ は近年台頭してきましたが、まだ多くの問題やバグがあり、特にテーブル ページングとデータ バインディングは非常に使いにくいです。一般に、DWZ の他のコンポーネントは DWZ とは異なります。スタイルは依然として非常に優れています。
さて、今日の DWZ テーブル ページングについてはこれで終わりです。