今日は劉暁愛がジャワ島を独学して108日目。
ご視聴ありがとうございました。
それでは、今日の勉強を始めましょう：
昨日は遅かったので、フロントエンドを書いてからテストすることもできず、結局今日になってたくさんの問題を見つけました。
ページ分割をスキップして、直接検索することを学ぶつもりでした。
結局のところ、私の現在の実装は例外的に低いと聞いていますし、チュートリアルもチェックしましたし、ページングについては後でまた話します。
しかし、今はうまくいっていないようです。放置されている点がかなり多く、私がしっかり把握していない知識もたくさんあります。
だから、一晩かけてその知識を完璧にしたほうがいいんです。
バックエンドのコードについては昨日のメモで説明しましたが、今問題になっているのは主にフロントエンドの問題です。
I. フロントエンドページのレンダリング
結局のところ、主にJavaのバックエンドのコードを書いているので、基本的にはパスです。
でも、昨日、基本的なポイントさえも間違っていたことに気づいたのは、自分でも許せないことです。
ですから、この実装のアイデアを詳細に整理するつもりです。
1 静的ページ
静的ページのコード書き込みとページ効果は下図の通りです：
- このようなデータは1ページに8つあります。
もちろん、この8個は昨日のセットでもあり、動的に変更することができ、さらにいくつかの重要なパラメータを持っています。
つまり、上の図①②③④です。
しかし、静的ページでは、これらのデータは死に書き込まれますので、動的にページにスプライスされたデータの背景を介して応答する必要があります。
2 バックグラウンド応答データ
ブラウザのF12を介してコンソールを開くことができます：
jsonデータは、キーと値のペアでそれを理解することが可能です。
キーはrouteData
これは昨日バックグラウンドで設定されたキーで、これを介して対応する値valueを取り出すことができます。
上の図のArray(8)のように、8つのデータが格納されたコレクションでもあります。
コレクションの値
8つのデータはそれぞれ異なっており、1つのデータを見ると、その内容もキーと値のペアになっています。
4つのパラメータの説明の最初の1つは、rimage、rname、routeIntroduce、priceです。
という思考回路が出てきます：
- まず、キー値routeDataに基づいてArray(8)を取り出します。
- 次に、each()メソッドを使用してコレクションを繰り返し処理します。
- 次に、キーの4つのパラメータに従って、対応する値を取り出します。
- 最後に、"+"を使ってデータをページにつなぎます。
3 フロントエンドページのスプライシング
リクエストを送信する際に繰り返されることはありません、直接戻り値を言う、つまり、結果です。
結果.routeData
これは8つのデータの集まりなので、トラバースする必要があります。
routeDataを繰り返し処理します。
これは私が昨日犯した最も愚かなミスで、2つのパラメータを持つeach()メソッドを呼び出しています：
- index: コレクションのインデックスに対応します。
- route.rimage
上で強調した4つの重要なパラメータを覚えていますか？
取り出すキーに応じて、このルートを通して取り出します：
- route.rname
- route.routeIntroduce
- route.price
- route.price。
最後に、プラス記号でデータの動的接続が完了します。
ページのレンダリング
idセレクタを通して対応するタグを見つけます。
-
そのidはroutePageListです。
html()メソッドを使用して、そのタグに縫合されたページをレンダリングします。
4 最後にテストを行います
ページネーションのページ番号の1つをクリックしてください。
ページ番号の数とページデータのサイズに基づいて、対応する8つのデータをデータベースに照会ます。
それぞれのデータは異なり、ページ番号の数によって動的に変化します。
5 機能改善
従来のビジネスロジックの1つは、対応するページ番号をクリックして初めてリクエストが開始され、対応するデータがレンダリングされるというものです。
しかし、ページがクリックされない場合、ページがロードされるときにデフォルトのページがあるはずです。
通常、デフォルトはデータの最初のページなので、コードはパッチされます：
ページのロードイベントで、getPageDataメソッドを呼び出します。
次に、ページの総数
時には、ユーザーエクスペリエンスのために、次のように、レコードの総数とページの総数がページングで説明されます：
データの総数totalCountとページの総数totalPageです。
この2つの間にはどのような関係があるのでしょうか？
これにはまた数学の演算が必要になります：
総データがページあたりのデータ量で整数化できる場合：totalPage = totalCount / ページ上のデータ量。
総データが各ページのデータ量で切り上げられない場合： total pages = 総データ / ページデータ量 + 1.
このような場合は、三項演算子を使えばよいことになります。
さて、アイデアが分析できたので、コードを書き始めましょう：
2 バックグラウンドコードでのページング総数
これは、ページング内の小さな関数なので、唯一のサービス層でコードを追加する必要がありますすることができます：
クエリデータの総数
ダオ層を介してデータベース内の対応するデータの総数を照会します。
データの総数によって、ページの総数を計算します。
三項演算子を使って表現します：
データ総数をページ数で割れるか？できるは前者の計算方法、できないは後者の計算方法です。
データのカプセル化
昨日はrouteDataをカプセル化しただけでしたが、今日は小さな機能を追加したり、キーと値のペアを追加したりして、カプセル化を完了します。
対応するデータは、ブラウザのコンソールを介して表示することができます。
SQL文の記述
集計関数count(*)を通して、sql文でデータ量を照会るように記述することができます。
どのrflagデータベース内のこのフィールドは、上下の棚の意味を示すことである1、棚の上です。
jdbcTemplateクエリ
queryForObject（）メソッドを使用してデータを照会します。
クエリの戻り値はint型なので、パラメータは整数クラスのオブジェクトです。
queryForObject メソッドの使用には、アクティブな try...catch が必要であることに注意してください。
3 フロントエンドのレンダリング
レスポンスデータから totalPage と totalCount を取得し、それらを動的に分割します。
最後に、クラスセレクタを通して、対応するラベルにレンダリングします。
もちろん、ここでのクラスセレクタはあまり正確ではなく、ページには同じクラスが複数あるかもしれません。
対応するタグでidをカスタマイズしてからidセレクタを使うのが一番安全です。
そして最後に
ご視聴ありがとうございました。
