2016-05-26 3 views
3

遅いバックエンドに対して、ページング可能なテーブル(DataTable)にデータをプリロードしてキャッシュするように求められました。wicketページテーブルにデータをプリロードする

アイデアは、ISortableDataProviderでキャッシュを維持し、ページごとに表示するよりも大きなチャンクをバックエンドに求めることです。このようにして、ユーザーは次の表ページに切り替えるたびに待つ必要はありません。

困った部分は、次のチャンクをフェッチすることがバックグラウンドで実行されるという考え方です。良いアプローチは何でしょうか?

a)のフェッチ

Bへの新しいバックグラウンドスレッドを開始)背景がフェッチ(およびキャッシュに格納しないAjax呼び出しをトリガー)

私は本当にオプションのいずれか好きではありません私はいくつかの問題を予見しています。

コメントがありますか?

+0

私は過去にバックグラウンドスレッドを使用しました。私はそれがお気に入りの解決策であるかどうかわかりません。だから、あなたが最終的に何をするのか聞いてみたいと思います。私の場合、ISortableDataProviderを持つツリーを使用していたので、ページングナビゲータを構築するためにデータセット全体のサイズを知る必要はなかったため、少し異なります。私がやったのは、ユーザがすぐに必要とする初期セットをキャッシュにロードしてから、残りのスレッドをロードするためにバックグラウンドスレッドを使用することでした。 ISortableDataProviderはキャッシュからデータを要求します。 – JeredM

答えて

1

私の意見では、これは実際にはWicket関連の問題ではありません。 私はサービスレベルといくつかのキャッシュソリューションに焦点を当てるべきだと思います。

Wicketは、Wicketコンポーネントに余分なデータ(前/次のページ)を置くことを決めた場合にのみ解決することができます。

+0

こんにちはマーティン:それは私のアイデアだったので、そのデータをwicketコンポーネントに入れました。今、私はバックグラウンドスレッドなしで作業しようとしますが、ページの必要以上のデータをロードし、コンポーネント/データプロバイダにキャッシュします。私の意見では、複数のスレッドがそのデータを更新することは、価値よりも多くの問題を引き起こします。 – bert

関連する問題