Жорстокий submit asp. Автоматичне зворотне відправлення даних

Your first name:

What is your favorite ice cream flavor:

Vanilla

Strawberry

Chocolate

Rocky Road

З цієї форми може бути передано таке тіло запиту:

firstname=James&flavor=Rocky+Road

Потім може бути використаний наведений нижче сценарій:

Welcome,<%= Request.Form("firstname") %>.

Your favorite flavor is<%= Request.Form("flavor") %>.

Результат матиме такий вигляд:

Welcome, James. Your favorite flavor is Rocky Road.

Якщо використовувати наведений нижче сценарій:

Unparsed form data is:<%= Request.Form %>

результат матиме такий вигляд:

The unparsed form data is: firstname=James&flavor=Rocky+Road

Примітка.Якщо форма включає кілька об'єктів з однаковими іменами (наприклад, теги HTML SELECT), елементом у сімействі форми буде список всіх вибраних значень, розділених комами.

Галузь застосування

Див. також

ClientCertificate _ClientCertificate, Cookies _Cookies_Request, QueryString _QueryString, ServerVariables _ServerVariables

Модель ASP.NET

Форми HTML

Тим, хто знайомий з мовою HTML, відомо, що найбільше простим способомнадсилання клієнтських даних серверу є використання дескриптора . Усередині дескриптора можна розміщувати дескриптори , що представляють інші базові елементиінтерфейсу користувача, на кшталт кнопок, текстових полів, вікон списків і перемикачів.

Наприклад, нижче показана HTML-сторінка з формою, яка містить два текстові поля, два прапорці та кнопку відправки, тобто. всього п'ять дескрипторів :

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 додає JavaScript-функцію на ім'я, що візуалізується HTML-сторінку ____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. )

Не забувайте, що ASP.NET генерує функцію __doPostBack() автоматично. Цей код розширюється, додавши до сторінки більшої кількості елементів керування AutoPostBack, оскільки дані про події повинні бути встановлені для кожного елемента керування.

Нарешті, будь-який елемент керування, властивість AutoPostBack якого встановлений у true, підключається до функції __doPostBack() з використанням атрибуту onclick або onchange. Ці атрибути вказують на те, яку дію слід виконати браузеру у відповідь на клієнтські події 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:

Click the button:
Text="Submit" onclick="SubmitBtn"
UseSubmitBehavior="FALSE" />