Nemilos trimite asp. Postback automat de date

Prenumele tău:

Care este aroma ta preferată de înghețată:

vanilie

Căpșună

Ciocolată

drum pietros

Următorul corp de cerere poate fi transmis din acest formular:

firstname=James&flavor=Rocky+Road

Scriptul de mai jos poate fi apoi folosit:

Bine ati venit,<%= Request.Form("firstname") %>.

Aroma ta preferată este<%= Request.Form("flavor") %>.

Rezultatul va arăta astfel:

Bine ai venit, James. Aroma ta preferată este Rocky Road.

Dacă utilizați scriptul de mai jos:

Datele formularului neanalizate sunt:<%= Request.Form %>

rezultatul va arăta astfel:

Datele de formular neanalizate sunt: ​​firstname=James&flavor=Rocky+Road

Notă. Dacă formularul include mai multe obiecte cu același nume (cum ar fi etichetele HTML SELECT), elementul din familia formularului va fi o listă cu toate valorile selectate, separate prin virgulă.

Zona de aplicare

Vezi si

ClientCertificate _ClientCertificate, Cookie-uri _Solicitare_cookies, Șir de interogare _Șir de interogare, Variabile de server _ServerVariables

Modelul ASP.NET

Formulare HTML

Cei care sunt familiarizați cu limbajul HTML știu asta cel mai mult într-un mod simplu trimiterea datelor clientului către server înseamnă folosirea mânerului . În interiorul mânerului se pot plasa descriptori reprezentandu-i pe altii elemente de baza interfață cu utilizatorul, cum ar fi butoanele, câmpurile de text, casetele de listă și butoanele radio.

De exemplu, mai jos este o pagină HTML cu un formular care conține două câmpuri de text, două casete de selectare și un buton de trimitere, de exemplu. doar cinci descriptori :

FirstName=Vasily&LastName=Pukin&CS=on&VB=on

La crearea acestui șir, browserul urmează anumite reguli. Informațiile sunt întotdeauna trimise ca o secvență de perechi nume/valoare separate de un ampersand (&). În cadrul unei perechi, numele este separat de valoare printr-un semn egal (=). Casetele de selectare sunt ignorate până când sunt selectate, caz în care browserul transmite textul ca valoare. Informații complete despre standardul de formulare HTML acceptat în fiecare browser curent poate fi găsit la W3C - Forms.

Practic, toate cadrele de programare pe partea de server adaugă un strat de abstractizare datelor brute din formă. Ei rup acea linie și o prezintă într-un mod mai util. De exemplu, JSP, ASP și ASP.NET vă permit să preluați valoarea unui control de formular folosind stratul subțire de obiecte. În ASP și ASP.NET, valorile pot fi căutate după nume în Cerere.Formulare colecţii. Dacă convertim pagina anterioară într-un formular web ASP.NET, atunci această abordare poate fi aplicată cu cod ca acesta:

String firstName = Request.Form["FirstName"];

Acest „strat” subțire de deasupra mesajului POST este util, dar încă departe de o structură adevărată orientată pe obiecte. De aceea, ASP.NET face un pas mai departe. Când pagina este postată înapoi în mediul ASP.NET, preia valorile, populează colecția de formulare (pentru compatibilitate cu codul ASP) și apoi configurează obiectele de control corespunzătoare. Aceasta înseamnă că următoarea sintaxă mult mai semnificativă poate fi utilizată pentru a prelua informații dintr-un formular web ASP.NET:

String firstName = txtFirstName.Text;

Acest cod are și avantajul siguranței de tip. Cu alte cuvinte, când recuperați starea casetei de selectare, veți obține o valoare booleană adevărată sau falsă în loc de cuvântul activat. Ca rezultat, dezvoltatorii sunt izolați de caracteristicile individuale ale sintaxei HTML.

În ASP.NET, toate controalele sunt plasate într-un mâner separat. . Acest handle este marcat cu atributul runat="server", care îi permite să ruleze pe server. ASP.NET nu permite crearea de formulare Web care conțin mai mult de un handle de server , deși este posibil să creați pagini care trimit informații către alte pagini folosind tehnologia de trimitere pe mai multe pagini.

Interfață de utilizator dinamică

Fără îndoială, modelul de control facilitează extragerea informațiilor despre formular. Și mai remarcabil, vă face viața mai ușoară atunci când trebuie să adăugați informații pe o pagină. Aproape toate proprietățile de control web pot fi citite și setate. Aceasta înseamnă că, de exemplu, proprietatea Text a unui câmp de text poate fi setată la fel de ușor ca și citirea acestuia.

De exemplu, luați în considerare ce se întâmplă dacă sunteți pe cale să actualizați o bucată de text pe o pagină web pentru a reflecta unele informații introduse anterior de utilizator. În ASP clasic, trebuie să găsiți un loc convenabil pentru a insera un bloc de script care scrie cod HTML. Următorul este un fragment de cod ASP.NET care utilizează această tehnică pentru a afișa un mesaj de bun venit viu colorat:

Mesaj șir = " Bun venit " + txtFirstName.Text + " " + txtLastName.Text + ""; Răspuns.Scrie(mesaj);

Pe de altă parte, situația este simplificată la definirea controlului Label (etichetă) în ASP.NET:

Acum puteți doar să-i setați proprietățile:

Label1.Text = "Bun venit " + txtFirstName.Text + " " + txtLastName.Text; Label1.ForeColor = Culoare.Roșu;

Acest cod are mai multe avantaje. În primul rând, este mult mai ușor de scris (și fără erori). În acest exemplu, economiile sunt neglijabile, dar devin destul de semnificative dacă luăm în considerare pagină plină ASP.NET care trebuie să modifice dinamic blocuri HTML complexe care conțin linkuri, imagini și stiluri.

În al doilea rând, codul bazat pe control este, de asemenea, mult mai ușor de plasat în interiorul paginii. Puteți scrie cod ASP.NET indiferent unde are loc acțiunea corespunzătoare. Pe de altă parte, în cazul ASP-ului clasic, va trebui să vă ocupați de aspectul conținutului de pe pagină și de plasarea corespunzătoare a codului blocului de script. Dacă o pagină conține regiuni dinamice, poate deveni o mizerie de blocuri de script care nu au legătură și nu sunt în ordine.

Un alt avantaj (mai puțin vizibil, dar mai semnificativ) al modelului de control este modul în care sunt ascunse detaliile HTML de nivel scăzut. Acest lucru nu numai că face posibilă scrierea codului fără a învăța toate detaliile HTML, dar permite și paginilor să accepte o gamă mai largă de browsere. Deoarece controlul se redă singur, are capacitatea de a-și adapta rezultatul pentru a suporta diferite browsere, caracteristici avansate la nivelul clientului sau chiar alte standarde legate de HTML, cum ar fi XHTML sau WML. Ca atare, codul nu mai este legat direct de standardul HTML.

Model de evenimente ASP.NET

Tehnologia clasică ASP utilizează model liniar prelucrare. Aceasta înseamnă că codul paginii este procesat de la început până la sfârșit și executat în ordine. Datorită acestui model, dezvoltatorii care folosesc tehnologia clasică ASP trebuie să scrie o cantitate decentă de cod chiar și pentru pagini simple.

Un exemplu tipic în acest sens este o pagină web care conține trei butoane de trimitere diferite pentru trei operațiuni diferite. Într-un astfel de caz, codul de script trebuie să distingă clar pe ce buton a fost făcut clic la trimiterea paginii, apoi să determine și să efectueze acțiunea corespunzătoare pe baza logicii condiționate.

ASP.NET ușurează lucrurile prin oferirea model de procesare bazat pe evenimente. În acest model, dezvoltatorul adaugă mai întâi controale la formularul web și apoi decide la ce evenimente doresc să răspundă. Fiecare handler de evenimente este o metodă separată, făcând codul paginii să pară ordonat și organizat.

Acest model nu este nou, dar înainte de apariția ASP.NET, a fost folosit exclusiv în domeniul programării interfețelor utilizator cu ferestre pentru aplicații client bogat. Cum funcționează evenimentele în ASP.NET? Surprinzător de simplu. Pe scurt, arată așa:

Prima dată când o pagină este rulată, ASP.NET creează obiecte pentru pagină și controalele acesteia. În continuare, se execută codul de inițializare, după care pagina este convertită în HTML și returnată clientului, iar obiectele create sunt eliminate din memoria serverului.

La un moment dat, utilizatorul efectuează o acțiune care declanșează o postback, cum ar fi clic pe un buton. Pagina este apoi trimisă la server împreună cu toate datele din formular.

ASP.NET interceptează această pagină returnată și recreează obiectele acesteia din nou, readucendu-le la starea în care se aflau când această pagină a fost trimisă ultima dată către client.

În continuare, ASP.NET verifică ce operațiune a determinat ca datele să fie postate înapoi și generează evenimentele corespunzătoare (de exemplu, Button.Click), la care dezvoltatorul poate oferi o anumită reacție în codul său.

De regulă, dezvoltatorii preferă să efectueze un fel de operație pe partea de server în această etapă (cum ar fi actualizarea unei baze de date sau citirea datelor dintr-un fișier), apoi modifica obiectele de control astfel încât să afișeze noile informații.

Pagina modificată este convertită în HTML și returnată clientului. Obiectele pagină sunt eliminate din memorie. În cazul în care are loc o altă postback, ASP.NET repetă pașii enumerați în paragrafele 2-4.

Cu alte cuvinte, ASP.NET folosește datele din formular nu numai pentru a configura obiectele de control din pagină, ci și pentru a decide ce evenimente să declanșeze.

De exemplu, la observarea că textul afișat într-un câmp de text s-a schimbat de la ultima postback, ASP.NET va declanșa evenimentul necesar pentru a notifica pagina despre acest lucru. Să reacționeze sau nu la acest eveniment depinde de dezvoltator să aleagă.

Rețineți că, deoarece HTTP nu acceptă conceptul de stări și toate stările pe care ASP.NET le pune la dispoziție sunt restaurate, modelul bazat pe evenimente este în esență o emulare. Pentru a susține acest model, ASP.NET trebuie să efectueze multe sarcini în fundal. Frumusețea acestui concept este că un programator începător nu trebuie să fie familiarizat cu toate detaliile sistemului pentru a profita cu succes de evenimentele serverului.

Postback automat de date

Desigur, există un decalaj în sistemul de evenimente care a fost descris până acum. Dezvoltatorii de aplicații Windows au fost de mult obișnuiți să se ocupe de un model bogat de evenimente care permite codului să răspundă la mișcările mouse-ului, la apăsarea tastei și la interacțiunile de control instantanee. Dar în ASP.NET, acțiunea clientului are loc pe partea clientului, iar procesarea pe partea serverului are loc pe serverul web. Acest lucru înseamnă că răspunsul la un eveniment implică întotdeauna unele cheltuieli generale. Prin urmare, evenimentele declanșate rapid (cum ar fi evenimentele de mișcare a mouse-ului) sunt complet impracticabile în lumea ASP.NET.

Pentru a realiza în interfața cu utilizatorul efect specific, puteți crea JavaScript la nivelul clientului pentru a gestiona evenimente rapide, cum ar fi mișcările mouse-ului. Sau, și mai bine, poți folosi element special Controale ASP.NET cu capabilități încorporate de acest tip, cum ar fi unul dintre controalele ASP.NET AJAX. Cu toate acestea, codul logicii de afaceri ar trebui să fie rulat numai într-un mediu de server bogat securizat.

Dacă sunteți familiarizat cu Formulare HTML, atunci știți că o modalitate destul de comună de a trimite o pagină este să faceți clic pe butonul Trimiteți. În cazul utilizării controalelor standard de server HTML în formularele web .aspx, această metodă este în general singura opțiune posibilă. Cu toate acestea, după ce pagina a fost deja postată înapoi, ASP.NET poate declanșa imediat alte evenimente (de exemplu, evenimente care notifică faptul că o valoare dintr-un control de intrare s-a schimbat).

Evident, acest lucru nu este suficient pentru a crea un formular web complet funcțional. Din fericire, controalele web furnizate în ASP.NET extind acest model cu postback automat. Cu această facilitate, controalele de intrare pot genera diverse evenimente la care codul serverului dumneavoastră poate răspunde imediat.

De exemplu, puteți declanșa o postback atunci când utilizatorul face clic pe o casetă de selectare, modifică o selecție dintr-o listă sau modifică textul dintr-un câmp de text și apoi navighează la alt câmp. Aceste evenimente nu sunt la fel de modulare ca evenimentele dintr-o aplicație Windows, dar reprezintă o îmbunătățire semnificativă față de butonul Trimitere.

Ce este postback automat

Pentru a utiliza postback automat, trebuie să instalați Proprietate AutoPostBack controlul web la true (în mod implicit, această proprietate este setată la false, ceea ce asigură o performanță optimă în cazurile în care nu trebuie să răspundeți la niciun eveniment de modificare). ASP.NET folosește apoi partea client JavaScript pentru a reduce decalajul dintre codul client și cel al serverului.

În special, se întâmplă următoarele: atunci când o pagină web este creată cu una sau mai multe controale web care au configurat AutoPostBack, ASP.NET adaugă o funcție JavaScript la pagina HTML redată numită ____doPostBack(). Când este apelată, această funcție inițiază o postback, trimițând pagina înapoi la serverul web cu toate datele formularului.

În plus, ASP.NET adaugă și două câmpuri de intrare ascunse pe care funcția ____doPostBack() le folosește pentru a trimite anumite informații înapoi către server. Aceste informații sunt ID-ul controlului care a declanșat evenimentul și alte informații relevante. Inițial, datele câmpului sunt goale, după cum se arată mai jos:

Funcția __doPostBack() este responsabilă pentru setarea acestor valori la informațiile corespunzătoare despre eveniment și apoi trimiterea formularului. Mai jos este un exemplu de funcție ____doPostBack():

Funcția __doPostBack(eventTarget, eventArgument) ( dacă (!theForm.onsubmit || (theForm.onsubmit() != false)) ( theForm.__EVENTTARGET.value = eventTarget; theForm.__EVENTARGUMENT.value = eventArgument; theForm.submit(); ) )

Nu uitați că ASP.NET generează automat funcția __doPostBack(). Acest cod se extinde pe măsură ce mai multe controale AutoPostBack sunt adăugate în pagină, deoarece datele despre eveniment trebuie setate pentru fiecare control.

În cele din urmă, orice control care are proprietatea AutoPostBack setată la true este conectat la funcția __doPostBack() folosind atributul onclick sau onchange. Aceste atribute indică ce acțiune ar trebui să întreprindă browserul ca răspuns la evenimentele client JavaScript onclick și onchange.

Cu alte cuvinte, ASP.NET convertește automat un eveniment client JavaScript într-un eveniment server ASP.NET folosind funcția __doPostBack() ca proxy. Un dezvoltator de aplicații ASP cu experiență ar putea, desigur, să creeze manual solutie similara pentru pagini web în stil tradițional ASP. Dar cu siguranță ASP.NET face viața mult mai ușoară dezvoltatorului prin gestionarea automată a tuturor acestor detalii.

Vedeți starea

Ultima componentă din modelul ASP.NET este vizualizați mecanismul de stare. Acest mecanism rezolvă o altă problemă care apare din faptul că HTTP nu acceptă starea - pierderea de informații despre modificări.

De fiecare dată când o pagină este trimisă înapoi la server, ASP.NET primește toate datele pe care utilizatorul le-a introdus în oricare dintre datele conținute în handle. controale . ASP.NET încarcă apoi pagina web în starea inițială (pe baza schemei de aspect și a setărilor implicite care au fost specificate în fișierul .aspx) și o personalizează în funcție de aceste date noi.

Problema este că într-un formular web dinamic, codul poate modifica mult mai multe detalii. De exemplu, poate schimba în mod programatic culoarea titlului, poate edita o bucată de text static, poate ascunde sau afișa un panou cu comenzi sau chiar poate fixa un întreg tabel de date într-o grilă. Toate aceste acțiuni implică schimbarea stării inițiale a paginii. Cu toate acestea, niciuna dintre acestea nu este reflectată în datele din formularul trimis. Și asta înseamnă că după fiecare postback de date, aceste informații se vor pierde.

De obicei, lipsa suportului de stat este depășită prin utilizarea cookie-urilor simple, cookie-urilor de sesiune și alte soluții. Cu toate acestea, toate astfel de mecanisme necesită utilizarea unor măsuri de dezvoltare proprie (care uneori necesită mult efort).

Pentru a aborda această limitare, ASP.NET are propriul mecanism integrat de serializare a stării. În esență, acest mecanism funcționează astfel: după ce codul paginii s-a terminat de executat (și chiar înainte ca documentul HTML final să fie generat și trimis către client), ASP.NET examinează proprietățile tuturor controalelor prezentate pe această pagină. Dacă oricare dintre aceste proprietăți s-a schimbat față de starea inițială, ASP.NET face o notă corespunzătoare în colecția nume-valoare. ASP.NET preia apoi toate informațiile colectate și le serializează într-un șir în format Base64 (care garantează că nu există caractere speciale ilegale în HTML), apoi inserează acest șir în secțiune paginile ca un nou câmp ascuns.

Data viitoare când această pagină este postată înapoi, ASP.NET face următoarele:

Recreează obiectul pagină și controalele acestuia pe baza valorilor implicite (specificate în fișierul .aspx), lăsând pagina în aceeași stare în care se afla când a fost solicitată prima dată.

Deserializează informațiile de stare și actualizează toate controalele. Ca urmare, pagina revine la starea în care se afla înainte de a fi trimisă ultima dată către client.

În cele din urmă, pagina este configurată conform datelor din formularul trimis. De exemplu, dacă utilizatorul introduce text nou într-o casetă de text sau face o nouă selecție într-o casetă de listă, acele informații sunt plasate în colecția Formular și utilizate de ASP.NET pentru a construi controalele corespunzătoare. Pagina afișează apoi starea curentă atunci când este vizualizată de utilizator.

Acum intră în joc codul dvs. de gestionare a evenimentelor. ASP.NET generează evenimentele corespunzătoare, iar codul poate reacționa schimbând pagina, navigând la pagina noua sau prin efectuarea unei alte operații.

Utilizarea stării de vizualizare este o soluție excelentă, deoarece resursele serverului pot fi eliberate după fiecare solicitare, permițând scalabilitate la sute sau mii de solicitări fără a încetini serverul. Cu toate acestea, trebuie să plătiți pentru tot. Stocarea stării de vizualizare în interiorul paginii mărește dimensiunea paginii. Acest lucru are un efect dublu asupra clientului, deoarece nu numai că trebuie să obțină o pagină mai mare, ci și să returneze date ascunse privind starea vizualizării către server la următoarea postare. Prin urmare, este nevoie de mult timp pentru a primi și trimite pagina.

Pentru paginile simple, această suprasarcină este mică, dar atunci când se configurează controale complexe de date grele, cum ar fi un GridView, cantitatea de informații despre starea vizualizării poate crește semnificativ. În astfel de cazuri, puteți dezactiva starea de vizualizare pentru control setând-o la Proprietatea EnableViewState la fals. Dar, în acest caz, ar trebui să reinițializi controlul pentru fiecare postback.

Chiar și atunci când EnableViewState este setat la fals, controlul poate reține o cantitate mică de informații despre starea vizualizării, care este esențială pentru funcționarea sa corectă. Această informație privilegiată privind starea vizualizării este cunoscută ca stare de control, și nu îl puteți opri. Cu toate acestea, într-un control bine conceput, cantitatea de date privind starea controlului este mult mai mică decât dimensiunea întregii stări de vizualizare.

ASP.NET aplică starea de vizualizare numai proprietăților de pagină și control. ASP.NET nu face același lucru cu variabilele de instanță și alte date pe care le puteți utiliza. Cu toate acestea, puteți pune alte tipuri de date în stare de vizualizare și puteți prelua acele informații manual ulterior.

Următoarea figură arată mecanismul de solicitare a paginii de trecere care combină toate aceste concepte:

Vedeți analiza stării

Dacă vizualizați HTML generat pentru pagina ASP.NET, veți găsi un câmp de intrare ascuns cu informații despre starea vizualizării:

Bara de stare a vizualizării nu poate fi citită de om: arată doar ca o secvență de caractere aleatorii. Cu toate acestea, este important de reținut că, dacă dorește, utilizatorul poate face puțin efort și îl poate decripta destul de ușor. Următorul este un fragment de cod .NET care face acest lucru și afișează informațiile decodificate pe o pagină web:

// viewStateString conține informații despre starea vizualizării. șir viewStateString = Solicitare["__VIEWSTATE"]; // Convertiți șirul Base64 într-o matrice obișnuită de octeți // reprezentând caractere ASCII. byte bytes = Convert.FromBase64String(viewStateString); // Deserializați și afișați șirul Label1.Text = System.Text.Encoding.ASCII.GetString(bytes);

Când este decodificată, linia de stare va arăta cam așa:

915261182d__ControlsRequirePostBackKey__CSVB[?S???&?7 ???

Starea de vizualizare nu este un loc bun pentru a stoca informații sensibile pe care clientul nu dorește să le vadă, așa că acest tip de date ar trebui lăsate pe server. În plus, ar trebui să evitați, de asemenea, să luați decizii bazate pe starea vizualizării care ar putea compromite aplicația dacă clientul efectuează în mod intenționat sau accidental orice modificare a datelor privind starea vizualizării.

Din fericire, este posibil să creșteți securitatea datelor de stare de vizualizare. Puteți activa hashingul automat pentru a preveni încercările de a schimba starea de vizualizare sau puteți chiar cripta starea de vizualizare pentru a preveni decriptarea acesteia. Aceste trucuri transformă câmpurile ascunse dintr-o soluție brută într-o infrastructură mult mai fiabilă și respectată.

Divizarea stării vizualizării

Dimensiunea câmpului de stare de vizualizare ascunsă nu are limită. Cu toate acestea, unele proxy-uri, firewall-uri și browsere mobile nu vor lăsa paginile să treacă dacă câmpurile ascunse sunt mai mari decât o anumită valoare. Pentru a rezolva această problemă, puteți utiliza divizarea stării de vizualizare, care împarte automat starea de vizualizare în mai multe câmpuri, astfel încât dimensiunile câmpurilor ascunse să nu depășească limita specificată.

Pentru aceasta trebuie să instalați maxPageStateFieldLength atribut element În fișierul web.config. Aceasta determină dimensiune maximă vizualizați starea în octeți. Următorul este un exemplu, definind o dimensiune a stării de vizualizare de 1 KB:

Rețineți că împărțirea stării de vizualizare este doar un mecanism pentru a minimiza problemele cu anumite proxy (ceea ce este o apariție relativ rară). Împărțirea stării de vizualizare nu îmbunătățește performanța (dimpotrivă, introduce o mică suprasarcină de serializare suplimentară). Pentru a îmbunătăți performanța, ar trebui să vă străduiți să includeți cât mai puține informații în starea de vizualizare.

Atributul UseSubmitBehavior specifică dacă controlul Button utilizează caracteristica de comitere încorporată a browserului client sau folosește mecanismul de notificare a tranzacțiilor ASP.NET.

Dacă controlul folosește un browser pentru a-și trimite funcțiile, atunci proprietatea este setată la TRUE. Altfel, FALS. Valoarea implicită este TRUE.

Dacă UseSubmitBehavior este setat la FALSE, ASP.NET adaugă un script la nivelul clientului pentru a trimite formularul. În prezent, dezvoltatorii de control pot folosi metoda GetPostBackEventReference a butonului pentru a returna un eveniment postback client. Metoda GetPostBackEventReference returnează un șir care conține text pentru apelurile de funcții client care poate fi lipit într-un handler de evenimente la nivel de client.

gramatică

/>

exemple

exemple

Următorul exemplu utilizează mecanismul de postback ASP.NET:

Faceți clic pe butonul:
Text="Trimite" onclick="TrimiteBtn"
UseSubmitBehavior="FALSE" />