I have an ambitious requirement for an asp.net 2.0 web page that contains a table (gridview), and each row in the grid contains 6 select (dropdown) controls for data entry. The number of rows that will be displayed is dependent upon the user’s search parameters, which are specified in another area of the page. Unfortunately, with the default (and even basic) search parameters specified, the grid could contain several hundred rows. I’ve noticed that the browser, in this case IE8, starts behaving rather erratically once I reach a large number of rows — no documented evidence for the number of rows where this begins to be a problem. For example, trying to view the source of the page results in a message from IE stating that there was a problem with the page that forced the browser to reload it, and I never get the source. Obviously the page loads and renders rather slowly also.
I know that my solution is probably going to involve paging the gridview such that it only displays 20 or so rows per page, and I’ll have to write code to handle the saving of changes in the dropdown values when the user changes pages. I can probably turn off viewstate on the gridview also. However, the question I really want to pose is this — has anyone seen a documented rule indicating the maximum number of input controls that an HTML browser form is supposed to be able to contain? I could not find anything on the Internet after doing a search, and I suspect the answer may be whatever the browser can handle based on the machine configuration it is running on. Any rules of thumb you use?
Thanks for any suggestions.
Rich
Is there a better design available? What’s the usage scenario?
For example, presented with a requirement such as that (which I not-so-lovingly call “Excel on the web”), would it be viable to present a largely read-only dataset, then use jQuery to change a single row to edit controls when clicked? Perhaps even, using some server-side paging, simulating “infinite scroll” while still only loading 20 rows at a time? You can keep the displayed (and DOM-stored) data smaller this way, as well as reduce the number of edit controls in the browser, and on top of all that still provide most (if not all) of the desired functionality.
Generally speaking, tons of input controls visible at once is a usability nightmare, and visually very distracting and difficult to line up/deal with. You’re almost undoubtedly better off with a solution like what I’ve described above. Yes, it’s going to be a ton of client-side script, but it’ll be way easier on the browser, the users, and ultimately even you.