Существует ли максимальное количество элементов управления вводом, которые могут использоваться на HTML-форме?
У меня есть амбициозное требование для asp.net 2,0 веб-страницы, которые содержат таблицу (gridview), и каждая строка в сетке содержит 6 избранных (выпадающих) средств управления для ввода данных. Количество строк, которые будут отображены, зависит от поисковых параметров пользователя, которые указаны в другой области страницы. К сожалению, со значением по умолчанию (и даже основной) поисковые указанные параметры, сетка могла содержать несколько сотен строк. Я заметил, что браузер, в этом случае IE8, начинает вести себя скорее беспорядочно, после того как я достигаю большого количества строк - никакое зарегистрированное доказательство для количества строк, где это начинает быть проблемой. Например, попытка просмотреть источник страницы приводит к сообщению от IE, указывая, что была проблема со страницей, которая вынудила браузер перезагрузить его, и я никогда не получаю источник. Очевидно, загрузки страницы и рендеринг скорее медленно также.
Я знаю, что мое решение, вероятно, собирается включить подкачку страниц gridview, таким образом, что это только отображает приблизительно 20 строк на страницу, и я должен буду написать код для обработки сохранения изменений в выпадающих значениях, когда пользователь изменяет страницы. Я могу, вероятно, выключить состояние отображения на gridview также. Однако вопрос, который я действительно хочу поставить, является этим - кто-либо видел зарегистрированное правило указать на максимальное количество элементов управления вводом, которые форма браузера HTML, как предполагается, может содержать? Я ничего не мог найти в Интернете после выполнения поиска, и я подозреваю, что ответ может быть тем, что браузер может обработать на основе конфигурации машины, на которой это работает. Какие-либо эмпирические правила Вы используете?
Спасибо за любые предложения.
Богатый
2 ответа
Есть ли лучший дизайн? Каков сценарий использования?
Например, при наличии такого требования (которое я не очень люблю называть "Excel в Интернете"), было бы целесообразно представить набор данных, доступный только для чтения, а затем использовать jQuery для изменения одной строки на элементы управления редактированием при нажатии? Возможно даже, используя некоторую подкачку на стороне сервера, имитировать "бесконечную прокрутку", загружая при этом только 20 строк за раз? Таким образом можно уменьшить размер отображаемых (и хранимых в DOM) данных, а также сократить количество элементов управления редактированием в браузере, и при этом обеспечить большинство (если не все) желаемых функций.
Вообще говоря, тонны элементов управления вводом, видимых одновременно, - это кошмар для юзабилити, и визуально они очень отвлекают и с трудом выстраиваются в линию/разбираются. Почти несомненно, лучше использовать решение, подобное тому, что я описал выше. Да, это будет тонна скриптов на стороне клиента, но это будет намного проще для браузера, пользователей и, в конечном счете, даже для вас.
В значительной степени это будет связано с памятью клиентской машины. Насколько я знаю, фактического ограничения на количество элементов управления нет. В конце концов, это движок браузера, который отображает все, что диктует код. Там нет оператора if, говорящего:
if (this.InputControls.Count > N) then GoBang();
Неустойчивое поведение, которое вы, вероятно, испытываете с большим количеством элементов управления, вероятно, связано с самим отображением элемента управления, вызванным воздействием на ЦП и память вашего компьютера. Вероятно, вы заметите разницу если вы развернете проект и запустите сайт на нескольких машинах с различными спецификациями.
Но тогда, действительно ли вам нужно такое огромное количество элементов управления? вы думаете, что вам следует использовать пейджинг, предполагает, что вы знаете, что делаете неправильно. Сделайте это правильно и внедрите пейджинг, иначе у вас возникнут проблемы, которые нужно исправить позже, и у вас возникнут проблемы с клиентами;).