問題タブ [will-paginate]

私のバージョンの Oracle では、will_paginate gem が壊れています。paginate_by_sqlWillPaginate モジュールのデフォルトの方法では、余分な「AS」がクエリに挿入され、クエリが失敗します。

コード自体は簡単に修正できますが、Rails に変更を反映させる最善の方法がわかりません。

gem 自体のコードを変更したくありません。変更すると、他のマシンでコードが壊れてしまうからです。

以下を含む lib/test.rb ファイルを作成してみました。

environment.rbからそれを要求していますが、私の変更を反映していません。また、controllers/application.rb から要求しようとしましたが、やはり変更が反映されませんでした。

一時的に、特定のモデル自体のメソッドをオーバーライドすることで機能するようになりましたが、これはちょっとしたハックであり、このプロジェクトの他のモデルでは使用できません。

これを行う簡単な方法があると確信していますが、Google を使用して追跡することはできません。

ユーザーがブログの投稿をランダムな順序でページングできるようにしたいと考えています。

次のように実装することはできません。

パラメータはすべてのクエリで呼び出されるため:order、ブログ投稿を繰り返すリスクがあります。

これを行う最善の方法は何ですか？

will_paginate プラグインを使用して、連続するページに分割された写真がいくつかあります。写真を開いてからリンクを使用してすべての写真に戻ると、常に最初のページに戻ります (たとえば、写真が 5 ページに表示されている場合、写真を開いてリンクをクリックしてすべての写真を表示し、そのページにいることを期待します)。再び 5 ページに戻りますが、現在は 1 ページにいます)。

さて、写真が属するページ番号を取得する方法はありますか?

GET パラメーターを渡そうとしましたが、これはユーザーがそれ以上のアクション (コメントの投稿、写真の編集など) を実行しない場合にのみ機能します。

will_paginateのpaginateメソッドのオプションを理解しようとしています：

page、、per_pageおよびfinderは簡単です。

total_entriesおよびcount-「手動でエントリをカウントする場合にのみ使用する」を理解していませんか？彼らは、別のカウントクエリを実行し、その結果をpaginateオプションとして渡すシナリオを想定していますか？あなたがそれをする状況は何でしょうか？

「カウントに渡される追加のオプション」-どのようなオプションが利用可能ですか？count???の方法に「渡す」

ここで本当に単純なものが欠けていることを確信しています：

プロファイルとグループという 2 つの異なるモデルのインスタンスを含む一連のページを表示しようとしています。名前属性で並べ替える必要があります。モデルごとにすべてのインスタンスを選択し、それらを並べ替えてページ番号を付けることもできますが、これはずさんで非効率的です。

私はmislav-will_paginateを使用していますが、これを達成するためのより良い方法があるかどうか疑問に思っていましたか? 何かのようなもの：

理想的でしょう！

もう一度...

will_paginateプラグインを使用して、投稿リストのオプションを選択して、ページごとに10、20、または50の結果数を表示する必要があります

手伝ってくれませんか。

ありがとう！

Rails の mislav-will_paginate プラグインを使用して、レコードのページ付けを行っています。複数のページがあるかどうかに関係なく、次の出力を生成したいと考えています。

WillPaginate::ViewHelpers の will_paginate は、レコードが 1 ページしかない場合は nil を返します。これを可能な限りクリーンな方法でオーバーライドして、ページが 1 つしかない場合は上記の出力を生成し、複数のページがある場合は通常の出力に囲まれた上記の出力を生成したいと考えています。

この出力を生成するために、WillPaginate::LinkRenderer の to_html メソッドをオーバーライドしましたが、レコードが 1 ページしかない場合に生成する方法がわかりません。

X - Z の Y を生成するコードを別の場所に移動し、オーバーライドする to_html メソッドと、nil が返された場合に will_paginate 呼び出しを行う場所の両方から呼び出す必要がありますか? もしそうなら、それはどこに住むべきですか？

ここで何が欠けていますか？私はhaml_scaffoldジェネレーターを使用しており、ページはwill_paginateで正常に動作します。私がいじくり回し始めると、この「total_pages」エラーが発生し、それが原因で何をしているのかわかりません。誰か洞察がありますか？mislav-will_paginate2.3.11を使用しています。

現在、 paginate_by_sqlメソッドを使用してページ化するコレクションを構築するwill_paginateの実装があります。total_entriesのカスタムクエリがありますが、これは非常に複雑で、DBに大きな負荷をかけます。したがって、ページネーションからtotal_entriesを完全に削除したいと思います。

言い換えると、「前へ1 [2] 3 4 5次へ」の典型的なページネーション表示の代わりに、「次へ-前へ」ボタンのみが必要です。しかし、私たちはいくつかのことを知る必要があります。

1. 前のリンクを表示しますか？もちろん、これは、現在の選択で表示されているレコードより前に存在するレコードの場合にのみ発生します。
2. 次のリンクを表示しますか？コレクションの最後のレコードが表示されている場合、これは表示されません。

ドキュメントから

：total_entriesを指定しない場合、行をカウントするためのクエリが自動的に生成されます。この生成されたSQLで問題が発生した場合は、アプリケーションで手動でカウントを実行することをお勧めします。

したがって、最終的に理想的な状況は次のとおりです。

• データベースに過度の負荷がかかるため、total_entriesカウントを削除します
• ナビゲートするために次/前のボタンのみを使用してセミページネーションで一度に50レコードを表示し、使用可能なすべてのページ番号を表示する必要はありません
• それに応じて次のボタンと前のボタンのみを表示します

誰かが同様の問題に取り組んだり、解決策について考えたことはありますか？

私は最近、クエリを 4 つの名前付きスコープに分割して、再並べ替えを容易にし、それ以外の場合は常に正常に機能していたページ番号を付けますが、現在はページ数の計算に問題があります。

最後に paginate をスローして、そのように使用します...

たとえば、Paginate は、それぞれ 15 の 6 ページがあることを示しますが、4 ページに到達すると、5 ～ 6 ページが消えます...そして、5 または 6 に直接ジャンプしようとすると、それらは存在しません。

それを見て、私はページネーションが持っている問題に気づきました

でも

前者のために生成されるSQLは、後者よりも約8行短く、より多くの結果を返す原因となる私のSQL HAVING句を無視しています...

これを修正する方法についてのアイデアはありますか?