https://bugzilla.wikimedia.org/show_bug.cgi?id=30056
--- Comment #5 from MZMcBride <[email protected]> 2011-08-08 01:03:52 UTC --- (In reply to comment #3) > This sounds like a good idea, but is potentially a nightmare to implement. The > problem is that if you search for allocation across all Wikipedias, for > example, you could get 89,280 different results (372 languages x 240 > countries). Obviously we don't want to output 89,280 separate tables. If you > have any ideas for how to deal with this, let me know. I don't understand this. As I see it, you'd have three drop-downs, all with a particular filter type, and one option of "all" (very similar to the current setup). If there are a lot of results, you can paginate, right? That's what you'd do with a large data set in nearly any other context. Set a limit and paginate through the results with an offset. I think pagination might be easier to implement if BannerAllocation used GET instead of POST. Not really sure why it's currently using POST. Probably the subject of a separate bug, though. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
