daze wrote in post #994152: > Okay, but it doesn't have to be AUTOMATIC... I mean Facebook has a > very nice "show more" button at the bottom of its news feed so you > only show more if you want to. > > And I could potentially have an unordered list of hundreds of > things.... so I don't think the div strategy you mentioned would be > good...
While using a "Show More" button is fine in many cases it is not that different than pagination. This is why there are so many different implementations for pagination. It's really difficult to create a "one-size-fits-all" solution. For a few hundred results I would prefer an endless page style solution. What difference does it make to the browser if the DIV is long enough to fit a few hundred results? It still only has to render a single DIV. It should make little difference to the browser if the DIV has a 500px height or a 200,000px height. For a few thousand I would probably prefer a paging solution. Whether that's accomplished with a "show more" or traditional pagination makes little difference in that case. It all depends on the type of information being displayed. In most cases, even in the cases of something like Google search results, most people will never see the results beyond maybe 10 pages or so. In cases like this it's vital that the most important results are shown first. Pagination works well in cases like this. In fact pagination can work better than a "show more" in certain cases. With a "show more" solution there is no convenient way to skip ahead. Consider the search engine results once again. Say you have performed a particular search before and remember that you found a link somewhere around page 10. With pagination you can skip directly, or within a click or two, to page 10. Then go forward or back from there to find that elusive not-so-popular link. All I'm saying is that there is no "magic bullet" solution here. We need different solutions for different scenarios. This discussion here was about creating a nice gem for managing paged results. I think it would be difficult to create a single gem that can deal with every case, while still providing an easier solution than custom building a paging solution yourself. The previously linked Railscasts episode illustrates that it's not terribly difficult to begin with. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
