Семейство Form извлекает значения элементов формы, отправленных в теле HTTP-запроса, с помощью формы, использующей метод POST.
СинтаксисRequest.Form(элемент ) [(индекс ) |.Count ]
Параметрыэлемент
Имя элемента формы, из которой семейство извлекает значения.
индекс
Необязательный параметр, который дает возможность получения доступа к одному из нескольких значений параметра. Может быть любым целым числом в диапазоне от –1 до Request.Form(параметр ).Count .
ПримечанияСемейство Form индексируется по именам параметров в теле запроса. Значение Request.Form(element ) представляет собой массив всех значений элемента, которые встречаются в теле запроса. Можно определить число значений параметра, вызвав Request.Form(элемент ).Count . Если параметр не имеет нескольких значений, связанных с ним, счетчик равен 1. Если параметр не найден, счетчик равен 0.
Для ссылки на отдельное значение элемента формы, имеющего несколько значений, необходимо указать значение для индекса . Параметр индекс может быть любым числом в диапазоне от 1 до Request.Form(элемент ).Count . Если ссылаются на один из нескольких параметров формы без указания значения индекса , данные возвращаются в виде строки, разделенной запятыми.
Когда Request.Form используется с параметрами, веб-сервер производит анализ тела HTTP-запроса и возвращает указанные данные. Если приложение требует неразобранных данных из формы, можно обратиться к ним, вызвав Request.Form без параметров.
Примечание. При работе с ASP и отправке больших объемов данных, превышаюших 100 Кбайт, метод Request.Form использовать нельзя. Если приложению нужно отправить данные, выходяще за этот предел, можно создать компонент, использующий метод Request.BinaryRead .
Можно перебирать все значения данных в запросе формы. Например, если пользователь заполняет форму, указывая два значения - Chocolate и Butterscotch - для элемента FavoriteFlavor, можно извлечь эти значения с помощью сценария, приведенного ниже.
For i = 1 To Request.Form("FavoriteFlavor").Count
Response.Write Request.Form("FavoriteFlavor")(i) & "
"
Приведенный выше сценарий будет отображать следующую информацию.
Можно использовать этот прием для отображения имени параметра, как показано в сценарии, приведенном ниже.
For i = 1 to Request.Form("FavoriteFlavor").count %>
Request.Form(FavoriteFlavor) =
Этот сценарий отобразит в обозревателе следующее:
Request.Form(FavoriteFlavor) = Chocolate
Request.Form(FavoriteFlavor) = Butterscotch
ПримерРассмотрим следующую форму:
Your first name:
What is your favorite ice cream flavor:
Vanilla
Strawberry
Chocolate
Rocky Road
Из этой формы может быть передано следующее тело запроса:
firstname=James&flavor=Rocky+Road
Затем может быть использован приведенный ниже сценарий:
Welcome, .
Your favorite flavor is .
Результат будет иметь следующий вид:
Welcome, James. Your favorite flavor is Rocky Road.
Если использовать приведенный ниже сценарий:
The unparsed form data is:
результат будет иметь следующий вид:
The unparsed form data is: firstname=James&flavor=Rocky+Road
Примечание. Iесли форма включает несколько объектов с одинаковыми именами (например, теги HTML SELECT), элементом в семействе формы будет список всех выбранных значений, разделенных запятыми.
Область применения См. такжеClientCertificate _ClientCertificate, Cookies _Cookies_Request, QueryString _QueryString, ServerVariables _ServerVariables
Модель ASP.NET
Формы HTMLТем, кто знаком с языком HTML, известно, что наиболее простым способом отправки клиентских данных серверу является использование дескриптора . Внутри дескриптора можно размещать дескрипторы , представляющие другие базовые элементы пользовательского интерфейса, вроде кнопок, текстовых полей, окон списков и переключателей.
Например, ниже показана HTML-страница с формой, которая содержит два текстовых поля, два флажка и кнопку отправки, т.е. всего пять дескрипторов :
Опрос
Введите ваше имя:
Введите фамилию:
На чем программируете:
C#
VB .NET
На рисунке показано, как эта простая страница будет выглядеть в окне веб-браузера:
Когда пользователь щелкает на кнопке Submit (Отправить), браузер извлекает текущие значения каждого элемента управления и формирует из них длинную строку. Затем эта строка отправляется странице, указанной в дескрипторе (в данном случае page.aspx) с использованием HTTP-операции POST. В данном примере это означает, что веб-сервер может получить запрос со следующей строкой информации:
FirstName=Василий&LastName=Пупкин&CS=on&VB=on
При создании этой строки браузер соблюдает определенные правила. Информация всегда отправляется в виде последовательности пар "имя-значение", разделенных символом амперсанда (&). Внутри пары имя отделяется от значения знаком равенства (=). Флажки игнорируются до тех пор, пока не будут выбраны, в таком случае браузер передает в качестве значения текст on. Полную информацию о стандарте форм HTML, поддерживаемом в каждом текущем браузере, можно найти на W3C - Forms .
Фактически все серверные каркасы программирования добавляют уровень абстракции к необработанным данным формы. Они разбивают эту строку и представляют ее более полезным способом. Например, JSP, ASP и ASP.NET позволяют извлекать значение элемента управления формы с использованием тонкого объектного уровня. В ASP и ASP.NET значения можно искать по имени в коллекции Request.Form . Если преобразовать предыдущую страницу в веб-форму ASP.NET, тогда этот подход можно будет применить с помощью такого кода:
String firstName = Request.Form["FirstName"];
Этот тонкий "слой" поверх сообщения POST полезен, но все же далек от истинной объектно-ориентированной структуры. Вот почему в ASP.NET делается еще один шаг вперед. Когда страница отправляется обратно среде ASP.NET, она извлекает значения, заполняет коллекцию Form (для обратной совместимости с кодом ASP) и затем конфигурирует соответствующие объекты элементов управления. Это означает, что для извлечения информации из веб-формы ASP.NET можно использовать следующий намного более содержательный синтаксис:
String firstName = txtFirstName.Text;
Данный код также обладает преимуществом безопасности типов. Иначе говоря, при извлечении состояния флажка вы получите булевское значение true или false вместо слова on. В результате разработчики оказываются изолированными от индивидуальных особенностей синтаксиса HTML.
В ASP.NET все элементы управления помещены в отдельный дескриптор . Этот дескриптор помечен атрибутом runat="server", который позволяет ему работать на сервере. ASP.NET не допускает создание веб-форм, содержащих более одного серверного дескриптора , хотя можно создавать страницы, выполняющие отправку информации другим страницам, с использованием технологии межстраничной отправки.
Динамический пользовательский интерфейсНесомненно, модель элементов управления облегчает извлечение информации о форме. Еще более примечательно то, что она упрощает жизнь при необходимости добавления информации к странице. Почти все свойства веб-элемента управления можно читать и устанавливать. Это означает, что, например, свойство текстового поля Text можно установить так же просто, как и прочитать его.
Например, рассмотрим, что происходит, если вы собираетесь обновить часть текста на веб-странице для отражения какой-либо информации, введенной ранее пользователем. В классической ASP вам понадобится найти удобное место для вставки блока сценария, записывающего HTML-код. Ниже показан фрагмент ASP.NET-кода, в котором этот прием используется для отображения ярко окрашенного приветственного сообщения:
String message = "Welcome " + txtFirstName.Text + " " + txtLastName.Text + ""; Response.Write(message);
С другой стороны, ситуация упрощается при определении в ASP.NET элемента управления Label (метка):
Теперь можно просто установить его свойства:
Label1.Text = "Welcome " + txtFirstName.Text + " " + txtLastName.Text; Label1.ForeColor = Color.Red;
Этот код обладает несколькими преимуществами. Во-первых, его намного легче написать (причем без ошибок). В данном примере экономия незначительна, однако она становится весьма существенной, если принимать во внимание полную страницу ASP.NET, на которой необходимо динамически изменять сложные блоки HTML, содержащие ссылки, изображения и стили.
Во-вторых, основанный на элементах управления код также намного легче разместить внутри страницы. Вы можете написать код ASP.NET независимо от того, где происходит соответствующее действие. С другой стороны, в случае классической ASP вам придется позаботиться о расположении содержимого на странице и соответствующем размещении кода блоков сценариев. Если страница содержит динамические области, она может превратиться в путаницу из блоков сценариев, не связанных между собой и не упорядоченных.
Другим (менее заметным, но более значительным) преимуществом модели элементов управления является способ сокрытия низкоуровневых подробностей HTML. Это не только дает возможность писать код без изучения всех индивидуальных особенностей HTML, но также позволяет страницам поддерживать более широкий диапазон браузеров. Поскольку элемент управления визуализирует себя сам, он обладает способностью адаптировать свой вывод с целью поддержки различных браузеров, усовершенствованных клиентских свойств или даже других стандартов, связанных с HTML, наподобие XHTML или WML. По существу код уже не привязан непосредственно к стандарту HTML.
Модель событий ASP.NETВ классической технологии ASP используется линейная модель обработки. Это означает, что код страницы обрабатывается от начала до конца и выполняется по порядку. Из-за этой модели разработчикам, пользующимся классической технологией ASP, приходится писать приличный объем кода даже для простых страниц.
Типичным тому примером является веб-страница, содержащая три разных кнопки отправки (Submit) для трех разных операций. В таком случае код сценария должен четко отличать, на какой кнопке был выполнен щелчок при отправке страницы, а затем определять и выполнять соответствующее действие на основе условной логики.
ASP.NET облегчает ситуацию, предлагая управляемую событиями модель обработки (event-driven model) . В этой модели разработчик сначала добавляет в веб-форму элементы управления, а затем решает, на какие события он хочет реагировать. Каждый обработчик событий представляет собой отдельный метод, благодаря чему код страниц выглядит аккуратно и организованно.
Эта модель не является новой, но до появления ASP.NET она применялась исключительно в области программирования оконных пользовательских интерфейсов для многофункциональных клиентских приложений. Каким же образом работают события в ASP.NET? На удивление очень просто. Вкратце это выглядит так:
При первом запуске страницы ASP.NET создает объекты этой страницы и ее элементов управления. Далее выполняется код инициализации, после чего страница преобразуется в HTML и возвращается клиенту, а созданные объекты удаляются из памяти сервера.
На каком-то этапе пользователь выполняет действие, инициирующее обратную отправку данных, например, щелкает на кнопке. Тогда страница отправляется серверу вместе со всеми данными формы.
ASP.NET перехватывает эту возвращаемую страницу и снова воссоздает ее объекты, возвращая их в то состояние, в котором они находились тогда, когда эта страница в последний раз отправлялась клиенту.
Далее ASP.NET проверяет, какая именно операция привела к обратной отправке данных, и генерирует соответствующие события (например, Button.Click), на которые разработчик может предусмотреть в своем коде определенную реакцию.
Как правило, разработчики предпочитают выполнять на этом этапе какую-то серверную операцию (вроде обновления базы данных или чтения данных из файла), а затем изменять объекты элементов управления так, чтобы они отображали уже новую информацию.
Измененная страница преобразуется в HTML и возвращается клиенту. Объекты страницы удаляются из памяти. В случае если происходит еще одна обратная отправка данных, ASP.NET повторяет действия, перечисленные в пунктах 2-4.
Другими словами, ASP.NET использует данные формы не только для конфигурирования объектов имеющихся на странице элементов управления, но также и для принятия решения о том, какие события запускать.
Например, заметив, что с момента последней обратной отправки данных текст, отображаемый в текстовом поле, изменился, ASP.NET запустит событие, необходимое для того, чтобы уведомить об этом страницу. Реагировать на это событие или нет - уже выбирать самому разработчику.
Имейте в виду, что поскольку HTTP не поддерживает концепцию состояний, а все состояния, которые делает доступными ASP.NET, восстанавливаются, управляемая событиями модель, по сути, является эмуляцией. Для того чтобы поддерживать эту модель, ASP.NET приходится выполнять немало задач в фоновом режиме. Прелесть этой концепции состоит в том, что начинающему программисту вовсе необязательно быть знакомым со всеми деталями системы для того, чтобы успешно пользоваться преимуществами серверных событий.
Автоматическая обратная отправка данныхКонечно, в системе событий, которая пока что была описана, имеется один пробел. Разработчики Windows-приложений уже давно привыкли иметь дело с полнофункциональной моделью событий, позволяющей коду реагировать на перемещения мыши, нажатия клавиш клавиатуры и мгновенные взаимодействия элементов управления. Но в ASP.NET действия клиента происходят на стороне клиента, а серверная обработка осуществляется на веб-сервере. Это означает, что ответ на событие всегда влечет за собой определенные накладные расходы. Поэтому быстро генерируемые события (вроде событий перемещения курсора мыши) в мире ASP.NET являются совершенно непрактичными.
Чтобы добиться в пользовательском интерфейсе определенного эффекта, для обработки быстрых событий вроде перемещений курсора мыши можно создать клиентский сценарий JavaScript. Или, что даже лучше, можно воспользоваться специальным элементом управления ASP.NET со встроенными возможностями подобного рода, например, одним из элементов ASP.NET AJAX. Однако код бизнес-логики должен обязательно выполняться только в безопасной многофункциональной среде сервера.
Если вы знакомы с формами HTML, то вам известно, что для отправки страницы существует один довольно распространенный способ - щелчок на кнопке Submit (Отправить). В случае использования в веб-формах.aspx стандартных серверных элементов управления HTML этот способ вообще является единственно возможным вариантом. Однако после того как обратная отправка страницы уже произошла, ASP.NET может тут же генерировать другие события (например, события, уведомляющие о том, что значение в элементе управления вводом изменилось).
Очевидно, что для создания полнофункциональной веб-формы этого не достаточно. К счастью, предлагаемые в ASP.NET веб-элементы управления дополняют эту модель средством автоматической обратной отправки. С помощью этого средства элементы управления вводом могут генерировать различные события, на которые ваш серверный код может немедленно отвечать.
Например, вы можете инициировать обратную отправку, когда пользователь щелкает на флажке, меняет выбор в списке либо изменяет текст в текстовом поле, а затем переходит на другое поле. Эти события не являются такими же модульными, как события в Windows-приложении, однако они представляют собой значительный шаг вперед по сравнению с применением кнопки Submit.
Что собой представляет автоматическая обратная отправкаЧтобы использовать автоматическую обратную отправку, понадобится установить свойство AutoPostBack веб-элемента управления в true (по умолчанию это свойство устанавливается в false, что гарантирует оптимальную производительность в случаях, когда не требуется реагировать ни на какие события изменения). После этого ASP.NET использует клиентские возможности JavaScript для устранения пробела между клиентским и серверным кодом.
В частности, происходит следующее: в случае создания веб-страницы с одним или более веб-элементами управления, для которых настраивается AutoPostBack, ASP.NET добавляет в визуализируемую HTML-страницу JavaScript-функцию по имени ____doPostBack() . При вызове эта функция инициирует обратную отправку, отправляя страницу обратно веб-серверу со всеми данными формы.
Помимо этого, ASP.NET также добавляет два скрытых поля ввода, которые функция ____doPostBack() использует для передачи обратно серверу определенной информации. Этой информацией является идентификатор элемента управления, который инициировал событие, и другие значимые сведения. Первоначально данные поля пусты, как показано ниже:
Функция ____doPostBack() отвечает за установку этих значений в соответствующую информацию о событии и последующую отправку формы. Ниже представлен пример функции ____doPostBack():
Function __doPostBack(eventTarget, eventArgument) { if (!theForm.onsubmit || (theForm.onsubmit() != false)) { theForm.__EVENTTARGET.value = eventTarget; theForm.__EVENTARGUMENT.value = eventArgument; theForm.submit(); } }
He забывайте, что ASP.NET генерирует функцию __doPostBack() автоматически. Этот код расширяется при добавлении к странице большего количества элементов управления AutoPostBack, поскольку данные о событиях должны быть установлены для каждого элемента управления.
Наконец, любой элемент управления, свойство AutoPostBack которого установлено в true, подключается к функции __doPostBack() с использованием атрибута onclick или onchange. Эти атрибуты указывают на то, какое действие следует выполнить браузеру в ответ на клиентские JavaScript-события onclick и onchange.
Другими словами, ASP.NET автоматически преобразует клиентское событие JavaScript в серверное событие ASP.NET, используя функцию __doPostBack() в качестве посредника. Опытный разработчик ASP-приложений смог бы, конечно, и вручную создать подобное решение для веб-страниц в традиционном стиле ASP. Но ASP.NET, несомненно, значительно облегчает жизнь разработчика тем, что обрабатывает все эти детали автоматически.
Состояние представленияПоследним компонентом в модели ASP.NET является механизм состояния представления (view state) . Этот механизм решает еще одну проблему, которая возникает из-за того, что HTTP не поддерживает состояний - утрату информации об изменениях.
Каждый раз, когда страница отправляется обратно серверу, ASP.NET получает все данные, которые пользователь ввел в любом из содержащихся в дескрипторе элементов управления . После этого ASP.NET загружает веб-страницу в исходном состоянии (на основе схемы компоновки и параметров по умолчанию, которые были указаны в файле.aspx) и настраивает ее в соответствии с этими новыми данными.
Проблема состоит в том, что в динамической веб-форме код может изменять намного больше деталей. Например, он может программно изменять цвет заголовка, редактировать фрагмент статического текста, скрывать или отображать панель с элементами управления или даже привязывать целую таблицу данных к сетке. Все эти действия подразумевают изменение исходного состояния страницы. Однако ни одно из них не отражается в пересылаемых данных формы. А это означает, что после каждой обратной отправки данных эта информация будет утрачиваться.
Обычно проблема отсутствия поддержки состояний преодолевается за счет использования простых cookie-наборов, сеансовых cookie-наборов и других обходных приемов. Однако все такие механизмы требуют применения мер собственной разработки (на которые порой уходит немало усилий).
Для устранения этого ограничения в ASP.NET имеется свой интегрированный механизм сериализации состояния. По сути, этот механизм работает так: после завершения выполнения кода страницы (и непосредственно перед генерацией и отправкой клиенту окончательного документа HTML) ASP.NET изучает свойства всех представленных на этой странице элементов управления. Если хоть какое-то из этих свойств изменилось по сравнению с тем, каким оно было в исходном состоянии, ASP.NET делает соответствующую заметку в коллекции "имя-значение". Потом ASP.NET берет всю собранную информацию и сериализирует ее в строку формата Base64 (который гарантирует отсутствие специальных символов, являющихся недопустимыми в HTML), а затем вставляет эту строку в раздел страницы как новое скрытое поле.
При следующей обратной отправке данной страницы, ASP.NET выполняет перечисленные ниже действия:
Воссоздает объект страницы и ее элементов управления на основе значений по умолчанию (указанных в файле.aspx), в результате чего страница оказывается в том же состоянии, в котором была, когда запрашивалась впервые.
Выполняет десериализацию информации о состоянии и обновляет все элементы управления. В результате страница возвращается в состояние, в котором находилась перед последней отправкой клиенту.
Напоследок производится настройка страницы в соответствии с отправленными данными формы. Например, если пользователь ввел новый текст в текстовом поле или же сделал новый выбор в окне списка, эта информация разместится в коллекции Form и используется ASP.NET для постройки соответствующих элементов управления. После этого страница отображает текущее состояние при ее просмотре пользователем.
Теперь в действие вступает ваш код обработки событий. ASP.NET генерирует соответствующие события, и код может реагировать изменением страницы, переходом на новую страницу или же выполнением какой-то другой операции.
Использование состояния представления является прекрасным решением, поскольку серверные ресурсы могут освобождаться после каждого запроса, допуская масштабируемость сотен или тысяч запросов без замедления работы сервера. Однако за все приходится платить. Хранение состояния представления внутри страницы увеличивает ее размеры. Это оказывает двойное влияние на клиента, поскольку ему необходимо не только получить страницу больших размеров, но и вернуть скрытые данные о состоянии представления серверу со следующей обратной отправкой. Поэтому на получение и отправку страницы уходит много времени.
Для простых страниц эти издержки невелики, но при настройке сложных элементов управления с большим количеством данных, таких как GridView, объем информации о состоянии представления может существенно увеличиться. В таких случаях можно отключить состояние представления для элемента управления, установив его свойство EnableViewState в false. Но в таком случае придется повторно инициализировать элемент управления при каждой обратной отправке.
Даже при установке EnableViewState в false элемент управления по-прежнему может сохранять небольшой объем информации о состоянии представления, которая является критичной для его надлежащего функционирования. Эта привилегированная информация о состоянии представления известна как состояние элемента управления (control state) , и отключить ее нельзя. Однако в хорошо разработанном элементе управления объем данных о состоянии элемента управления значительно меньше размера всего состояния представления.
ASP.NET применяет состояние представления только к свойствам страниц и элементов управления. ASP.NET не выполняет эти же действия с переменными экземпляров и другими данными, которые вы можете использовать. Однако, вы сможете помещать другие типы данных в состояние представления и извлекать эту информацию вручную позже.
На следующем рисунке показан механизм сквозных запросов страниц, объединяющий все эти концепции:
Если вы просмотрите сгенерированный HTML-код для страницы ASP.NET, то обнаружите скрытое поле ввода с информацией о состоянии представления:
Строка состояния представления не является читабельной для человека: она выглядит просто как последовательность случайных символов. Тем не менее, важно отметить, что при желании пользователь может приложить немного усилий и довольно легко расшифровать ее. Ниже показан фрагмент кода.NET, который делает это и выводит расшифрованную информацию на веб-странице:
// viewStateString содержит информацию состояния представления. string viewStateString = Request["__VIEWSTATE"]; // Преобразовать строку Base64 в обычный массив байт, // представляющих ASCII-символы. byte bytes = Convert.FromBase64String(viewStateString); // Выполнить десериализацию и отобразить строку Label1.Text = System.Text.Encoding.ASCII.GetString(bytes);
В расшифрованном виде строка с информацией о состоянии будет выглядеть примерно так:
915261182d__ControlsRequirePostBackKey__CSVB[?S???&?7 ???
Состояние представления является не очень хорошим местом для хранения секретной информации, которую клиент не должен видеть, поэтому данные такого рода следует оставлять на сервере. Помимо этого, также не стоит принимать на основе состояния представления решений, которые смогут скомпрометировать приложение в случае, если клиент специально или случайно внесет в данные состояния представления какие-то изменения.
К счастью, существует возможность усилить безопасность данных состояния представления. Можно включить функцию автоматического хеширования для предотвращения попыток изменения состояния представления, а можно даже зашифровать состояние представления для исключения вероятности его расшифровки. Эти приемы превращают скрытые поля из грубого обходного пути в гораздо более надежную и почитаемую часть инфраструктуры.
Разбиение состояния представленияРазмер скрытого поля состояния представления не имеет пределов. Однако некоторые прокси-серверы, брандмауэры и мобильные браузеры не пропускают страницы, если размер скрытых полей превышает определенное значение. Для решения этой проблемы можно воспользоваться разбиением состояния представления, предполагающим автоматическое разделение состояния представления на несколько полей, чтобы размеры скрытых полей не превышали заданного предела.
Для этого понадобится установить атрибут maxPageStateFieldLength элемента В файле web.config. Тем самым определяется максимальный размер состояния представления в байтах. Ниже показан пример, определения размера состояния представления в 1 Кбайт:
Следует помнить, что разбиение состояния представления является просто механизмом минимизации проблем с определенными прокси-серверами (что является относительно редким явлением). Разбиение состояния представления не улучшает производительности (наоборот, оно привносит небольшие накладные расходы на дополнительную сериализацию). Для улучшения производительности следует стремиться к включению в состояние представления как можно меньшего объема информации.
UseSubmitBehavior атрибут определяет элемент управления Button использует встроенную функцию фиксации клиентского браузера или использовать механизм ASP.NET уведомлений о транзакциях.
Если элемент управления использовать браузер, чтобы отправлять свои функции, то свойство имеет значение TRUE. В противном случае FALSE. Значение по умолчанию равно TRUE.
Если установлено значение FALSE UseSubmitBehavior, ASP.NET добавляет сценарий на стороне клиента, чтобы отправить форму. В настоящее время разработчики управления могут использовать метод для возврата кнопки GetPostBackEventReference клиент обратной передачи событие. Метод GetPostBackEventReference возвращает строку, содержащую вызовы функций клиента текст, который можно вставить в обработчик событий на стороне клиента.
грамматикапримеровпримеров
В следующем примере используется механизм обратной передачи ASP.NET:
Sub SubmitBtn(obj As Object, e As EventArgs)
lblMsg.Text = "Submitted using the ASP.NET postback mechanism."
End Sub
Click the button:
Последнее обновление: 31.10.2015
Хотя мы можем сами написать любой требуемый хелпер, но фреймворк MVC уже предоставляет большой набор встроенных html-хелперов, которые позволяют генерировать ту или иную разметку, главным образом, для работы с формами. Поэтому в большинстве случаев не придется создавать свои хелперы, и можно будет воспользоваться встроенными.
Хелпер Html.BeginFormДля создания форм мы вполне можем использовать стандартные элементы html, например:
Введите свое имя |
|
Введите адрес: |
|
Это обычная html-форма, которая по нажатию на кнопку отправляет все введенные данные запросом POST на адрес /Home/Buy. Встроенный хелпер BeginForm/EndForm позволяет создать ту же самую форму:
Введите свое имя |
|
Введите адрес: |
|
Метод BeginForm принимает в качестве параметров имя метода действия и имя контроллера, а также тип запроса. Данный хелпер создает как открывающий тег , так и закрывающий тег . Поэтому при рендеринге представления в выходной поток у нас получится тот же самый html-код, что и с применением тега form. Поэтому оба способа идентичны.
Здесь есть один момент. Если у нас в контроллере определены две версии одного метода - для методов POST и GET, например:
Public ActionResult Buy() { return View(); } public string Buy(Purchase purchase) { .............. return "Спасибо за покупку книги";; }
То есть фактически вызов страницы с формой и отправка формы осуществляется одним и тем же действием Buy. В этом случае можно не указывать в хелпере Html.BeginForm параметры:
@using(Html.BeginForm()) { ............. }
Ввод информацииВ предыдущем примере вместе с хелпером Html.BeginForm использовались стандартные элементы html. Однако набор html-хелперов содержит также хелперы для ввода информации пользователем. В MVC определен широкий набор хелперов ввода практически для каждого html-элемента. Что выбрать - хелпер или стандартный элементы ввода html, уже решает сам разработчик.
Вне зависимости от типа все базовые html-хелперы используют как минимум два параметра: первый параметр применяется для установки значений для атрибутов id и name , а второй параметр - для установки значения атрибута value
Html.TextBoxХелпер Html.TextBox генерирует тег input со значением атрибута type равным text . Хелпер TextBox используют для получения ввода пользователем информации. Так, перепишем предыдущую форму с заменой полей ввода на хелпер Html.TextBox:
@using(Html.BeginForm("Buy", "Home", FormMethod.Post)) {
Введите свое имя:
@Html.TextBox("Person", "Введите имя")Введите адрес:
@Html.TextBox("Address", "Введите адрес") }Мы получим тот же результат:
Html.TextAreaХелпер TextArea используется для создания элемента
, который представляет многострочное текстовое поле. Результатом выражения @Html.TextArea("text", "привет
мир")
будет следующая html-разметка:
привет
мир
Обратите внимание, что хелпер декодирует помещаемое в него значение, в том числе и html-теги, (все хелперы декодируют значения моделей и значения атрибутов). Другие версии хелпера TextArea позволяют указать число строк и столбцов, определяющих размер текстового поля.
@Html.TextArea("text", "привет
мир", 5, 50, null)
Этот хелпер сгенерирует следующую разметку:
привет
мир
В примере с формой мы использовали скрытое поле input type="hidden" , вместо которого могли бы вполне использовать хелпер Html.Hidden . Так, следующий вызов хелпера:
@Html.Hidden("BookId", "2")
сгенерирует разметку:
А при передаче переменной из ViewBag нам надо привести ее к типу string: @Html.Hidden("BookId", @ViewBag.BookId as string)
Html.PasswordHtml.Password создает поле для ввода пароля. Он похож на хелпер TextBox , но вместо введенных символов отображает маску пароля. Следующий код:
@Html.Password("UserPassword", "val")
генерирует разметку:
Html.RadioButton
Для создания переключателей применяется хелпер Html.RadioButton . Он генерирует элемент input со значением type="radio" . Для создания группы переключателей, надо присвоить всем им одно и то же имя (свойство name):
@Html.RadioButton("color", "red")
красный
@Html.RadioButton("color", "blue")
синий
@Html.RadioButton("color", "green", true)
зеленый
Этот код создает следующую разметку:
красный
синий
зеленый
Html.CheckBox может применяться для создания сразу двух элементов. Возьмем, к примеру, следующий код:
@Html.CheckBox("Enable", false)
Это выражение будет генерировать следующий HTML:
То есть кроме собственно поля флажка, еще и генерируется скрытое поле. Зачем оно нужно? Дело в том, что браузер посылает значение флажка только тогда, когда флажок выбран или отмечен. А скрытое поле гарантирует, что для элемента Enable будет установлено значение даже, если пользователь не отметил флажок.
Html.LabelХелпер Html.Label создает элемент , а передаваемый в хелпер параметр определяет значение атрибута for и одновременно текст на элементе. Перегруженная версия хелпера позволяет определить значение атрибута for и текст на метке независимо друг от друга. Например, объявление хелпера Html.Label("Name") создает следующую разметку:
Name
Элемент label представляет простую метку, предназначенную для прикрепления информации к элементам ввода, например, к текстовым полям. Атрибут for элемента label должен содержать ID ассоциированного элемента ввода. Если пользователь нажимает на метку, то браузер автоматически передает фокус связанному с этой меткой элементу ввода.
Html.DropDownListХелпер Html.DropDownList создает выпадающий список, то есть элемент . Для генерации такого списка нужна коллекция объектов SelectListItem , которые представляют элементы списка. Объект SelectListItem имеет свойства Text (отображаемый текст), Value (само значение, которое может не совпадать с текстом) и Selected . Можно создать коллекцию объектов SelectListItem или использовать хелпер SelectList . Этот хелпер просматривает объекты IEnumerable и преобразуют их в последовательность объектов SelectListItem . Так, код @Html.DropDownList("countires", new SelectList(new string {"Russia","USA", "Canada","France"}),"Countries") генерирует следующую разметку:
Countries Russia USA Canada France
Теперь более сложный пример. Выведем в список коллекцию элементов Book. В контроллере передадим этот список через ViewBag:
BookContext db = new BookContext(); public ActionResult Index() { SelectList books = new SelectList(db.Books, "Author", "Name"); ViewBag.Books = books; return View(); }
Здесь мы создаем объект SelectList, передавая в его конструктор набор значений для списка (db.Books), название свойства модели Book, которое будет использоваться в качестве значения (Author), и название свойства модели Book, которое будет использоваться для отображения в списке. В данном случае необязательно устанавливать два разных свойства, можно было и одно установить и для значения и отображения.
Тогда в представлении мы можем так использовать этот SelectList:
@Html.DropDownList("Author", ViewBag.Books as SelectList)
И при рендеринге представления все элементы SelectList добавятся в выпадающий список
Html.ListBoxХелпер Html.ListBox , также как и DropDownList , создает элемент , но при этом делает возможным множественное выделение элементов (то есть для атрибута multiple устанавливается значение multiple). Для создания списка, поддерживающего множественное выделение, вместо SelectList можно использовать класс MultiSelectList:
@Html.ListBox("countires", new MultiSelectList(new string {"Россия","США", "Китай","Индия"}))
Этот код генерирует следующую разметку:
Россия США Китай Индия
С передачей одиночных значений на сервер все понятно, но как передать множественные значения? Допустим, у нас есть следующая форма:
@using (Html.BeginForm()) { @Html.ListBox("countries", new MultiSelectList(new string { "Россия", "США", "Китай", "Индия" }))
}Тогда метод контроллера мог бы получать эти значения следующим образом:
Public string Index(string countries) { string result = ""; foreach (string c in countries) { result += c; result += ";"; } return "Вы выбрали: " + result; }
Форма с несколькими кнопкамиКак правило, на форме есть только одна кнопка для отправки. Однако в определенных ситуациях может возникнуть потребность, использовать более одной кнопки. Например, есть поле для ввода значения, а две кнопки указывают, надо это значение удалить или, наоборот, добавить:
@using (Html.BeginForm("MyAction", "Home", FormMethod.Post))
{
Добавить
Удалить
}
Самое простое решение состоит в том, что для каждой кнопки устанавливается одинаковое значение атрибута name , но разное для атрибута value . А метод, принимающий форму, может выглядеть следующим образом:
Public ActionResult MyAction(string product, string action) { if(action=="add") { } else if(action=="delete") { } // остальной код метода }
И с помощью условной конструкции в зависимости от значения параметра action, который хранит значение атрибута value нажатой кнопки, производятся определенные действия.
Загрузка...