Let's say you have a web page of a list of about 500 books (properties: cover image, titles, authors, summaries, etc) and want to paginate them. One way would be to use the limit and offset parameters, another would be by using cursors. For each subsequent page, the next batch would be fetched. But, what if you just fetched all the books, memcached the whole list for speed, used classes to hide the books belonging to other pages, and then used jquery for pagination? Wouldn't this be quicker and less quota intensive than the limit+offset or cursor methods?
This could also work for non-javascript users, simply by setting an appropriate hide class for the books belonging to other pages. It may be slower for them (although the memcache might help with that), but isn't it reasonable to assume that most modern day users have javascript enabled?
I could also then add more jquery features to the page, such as jquery searching (handy since app engine can't do full text searches), filtering, loading, etc.
It seems so much better, but are there disadvantages? Why isn't everyone doing thi开发者_开发知识库s, given that jquery is quite easy to learn? In other stackoverflow posts, about app engine pagination, no one even mentions jquery.
It'll be slower, because most users only view the first page or two of the results, but you're still pushing all 500 of them at page load time. That'll inflate page size and load time enormously.
It'll be less efficient, because the cost of loading 500 results is only marginally lower than the cost of loading, say, 20 results 25 times.
I think that in small number of entities, the plan that you describe may work, but you wouldn't have to get to especially large volumes before the download time, browser performance and browser memory usage made this approach untenable.
If you decide to take a more traditional approach to paging, save yourself a huge amount of time and use Ben Davies' PagedQuery class (if you are using Python). It is already highly-optimized for caching and responsible use of quota.
精彩评论