Una dintre cele mai grave limitări ale stării de prezentare este legătura strânsă cu o anumită pagină. Când un utilizator navighează către o altă pagină, aceste informații se pierd. Există mai multe soluții la această problemă, iar cea care va fi cea mai bună depinde de cerințe.
Întrebare șir
Avantajul șirului de interogare este că este simplu și nu introduce sarcină pe server. Spre deosebire de trimiterea interstițială, un șir de interogări poate transfera aceleași informații de la o pagină la o pagină. Cu toate acestea, are mai multe limitări:
Informațiile sunt accesibile vizual utilizatorilor și oricărei alte persoane care lucrează pe Internet.
Un utilizator întreprinzător poate decide să modifice șirul de interogare și să furnizeze noi valori pe care programul nu se așteaptă să le primească și din care nu este protejată.
Dar adăugarea de informații în șirul de interogare este o tehnică utilă. Este recomandat în special pentru aplicațiile de bază de date în care utilizatorul este prezentat cu o listă de articole care corespund înregistrărilor din baza de date (de exemplu, poate fi o listă de produse). Utilizatorul selectează elementul, după care este redirecționat către o altă pagină care conține informații detaliate despre elementul selectat.
Una dintre modalitățile cele mai ușoare de a implementa o astfel de soluție de proiectare este obținerea primei pagini pentru a trimite ID-ul articolului la a doua pagină. A doua pagină caută apoi acest element în baza de date și afișează informații detaliate despre el. Această tehnologie este adesea folosită pe site-uri de comerț electronic, de exemplu, Amazon.com.
Pentru a salva informațiile din șirul de interogări, trebuie să le puneți singur. Din păcate, nu există nici o modalitate de a face acest lucru cu ajutorul colecțiilor. În mod obișnuit, aceasta înseamnă că va trebui să utilizați un control HyperLink special sau o declarație Response.Redirect (), similară celei prezentate mai jos:
Pentru a trimite mai mulți parametri, acestea trebuie separate prin intermediul unei clase ampersand ():
Pagina de primire este mai ușor de utilizat cu șirul de interogare. Poate extrage valori din colecția de cuvinte cheie QueryString. furnizate de obiectul construit în Request, după cum se arată mai jos:
Dacă șirul de interogare nu conține parametrul recordID sau dacă conține acest parametru, dar fără o valoare, șirul de identificare este setat la null. Rețineți că informațiile sunt extrase întotdeauna ca un șir, care poate fi apoi convertit într-un alt tip de date simplu. Valorile din colecția QueryString sunt indexate după numele variabilei.
Din păcate, ASP.NET nu oferă un mecanism pentru verificarea sau criptarea automată a datelor din șirul de interogări. Ar putea funcționa în același mod ca și mecanismul de protecție al stării de prezentare. Fără această funcție, șirul de interogare este foarte vulnerabil.
Codarea URL-urilor
Mai mult, unele simboluri au un înțeles special. De exemplu, simbolul servește la parametrii separate în șirul de interogare, simbolul + este o modalitate alternativă de a reprezenta spațiu și este utilizat simbolul # pentru a se referi la o anumită filă pe pagina Web. O încercare de a trimite valori care conțin oricare dintre aceste caractere în șirul de interogare va duce în mod necesar la pierderea oricăror date.
Folosind metodele din clasa HttpServerUtility, puteți oferi codificarea automată a datelor. De exemplu, de mai jos arată cum să codificați un șir de date arbitrare pentru a fi utilizate într-un șir de interogări. Acest cod înlocuiește pur și simplu toate caracterele nevalide cu secvențele caracterelor convertite:
Pentru a reveni la valoarea inițială șir URL codificat poate fi HttpServerUtility.UrlDecode metoda () utilizată. Cu toate acestea, în cazul unui șir de interogare pentru a efectua acest pas nu este necesar, deoarece ASP.NET decodifică automat valoarea în obținerea accesului la ele printr-o colecție Request.QueryString.
De obicei, mai sigur de a provoca UrlDecode () metoda pentru a doua oară, pentru că decodificarea datelor care au fost deja decodat nu este o problemă. Singura excepție este prezența unei valori care include în mod rezonabil semnul +. În acest caz, apelarea metodei UrlDecode () va transforma acest caracter într-un caracter spațiu.
Returnează interstițială
Știți deja cum paginile ASP.NET efectuează o auto-postare. Cu acest feedback, conținutul actual al tuturor controalelor de pagină (împreună cu conținutul câmpului de stare ascunsă) este trimis în formular pentru aceeași pagină.
Pentru a transfera informații de la o pagină la alta, puteți utiliza același mecanism exact, dar trimiteți numai date către o altă pagină. Această tehnică pare destul de simplă în teorie, dar în practică poate avea multe "capcane". În caz de nerespectare a măsurilor de precauție, totul poate ajunge la obținerea de pagini prea strâns legate și extrem de incomode pentru extindere și depanare.
Fragmentul de cod afișat mai jos definește un formular cu două câmpuri de text și un buton care trimite date către o pagină numită CrossPage2.aspx:
Pagina CrossPage2.aspx poate interacționa cu obiectele paginii CrossPagel.aspx utilizând proprietatea PreviousPage. De exemplu:
Rețineți că înainte de a încerca să accesați obiectul PreviousPage, această pagină verifică o referință la obiectul null. Dacă obiectul PreviousPage nu există, returnarea între pagini nu este efectuată.
Pentru ca acest sistem să funcționeze, ASP.NET folosește un truc interesant. Atunci când a doua pagină încearcă mai întâi să acceseze obiectul Page.PreviousPage, mediul ASP.NET trebuie să creeze obiectul paginii anterioare. Pentru a face acest lucru, ASP.NET începe de fapt ciclul de procesare a paginilor, dar îl întrerupe imediat înainte de începerea fazei PreRender. În acest proces, ASP.NET creează, de asemenea, un obiect de substituție HttpResponse care interceptează în tăcere și ignoră toate comenzile Response.Write () provenite de la pagina anterioară.
Cu toate acestea, există încă unele efecte secundare interesante. De exemplu, toate evenimentele de pe pagina anterioară sunt declanșate, inclusiv Page.Load, Page.Init și chiar Button.Click pentru butonul care a lansat sendback-ul (dacă este definit). Activarea acestor evenimente este obligatorie, deoarece acestea sunt necesare pentru inițierea corectă a paginii.
Mesajele de urmărire, spre deosebire de mesajele de răspuns, nu sunt ignorate, ceea ce înseamnă că cu postback între pagini puteți vizualiza informațiile de urmărire din ambele pagini.
Primirea informațiilor specifice paginii
În exemplul de mai sus, informațiile preluate din pagina anterioară au fost restricționate numai pentru membrii din clasa de pagini. Dacă doriți să obțineți detalii mai detaliate, cum ar fi valorile controalelor, trebuie să aduceți linkul PreviousPage la tipul corespunzător.
Mai jos este un exemplu despre cum trebuie făcut acest lucru. Mai întâi, verifică dacă obiectul PreviousPage este o instanță a sursei așteptate (CrossPage1):
Într-un site Web fără proiect, Visual Studio poate marca un astfel de cod ca o eroare, indicând faptul că nu există informații despre tipul clasei de pagină sursă (în acest exemplu este CrossPage1). Cu toate acestea, după compilarea site-ului, această eroare dispare.
Această problemă poate fi rezolvată într-un alt mod. În loc să faceți referire manuală la tipul corespunzător, puteți adăuga o direcție la controlul PreviousPageType în codul paginii. care denotă tipul de pagină așteptat care inițiază returnarea inter-paginii, de exemplu:
Cu toate acestea, această abordare este mai puțin flexibilă, deoarece presupune utilizarea unui singur tip, fără a vă permite să faceți față situațiilor în care este necesar ca backflow-ul inter-paginii să inițieze mai mult de o pagină. Prin urmare, abordarea care implică aducerea la tipul potrivit este mai preferabilă.
Deoarece proprietatea PostBackUrl vă permite să specificați o singură pagină, este posibil ca postback-ul între pagini să poată fi setat numai între două pagini. Cu toate acestea, nu este așa - acest model este foarte ușor de extins printr-o varietate de tehnologii. De exemplu, puteți schimba programabil proprietatea PostBackUrl pentru a selecta o altă pagină de destinație. Sau vice-versa, face ca pagina de destinație din recuperarea de date înapoi între pagini să verifice valoarea proprietății PreviousPage și să determine dacă se referă la una din mai multe clase. Apoi, în funcție de ce pagină a inițiat postarea între pagini, puteți rezolva diferite sarcini.
După ce aduceți pagina anterioară la tipul corespunzător, nu veți mai putea accesa direct valorile controalelor sale. Acest lucru se datorează faptului că controalele sunt declarate ca membri protejați. Puteți rezolva această problemă prin adăugarea de proprietăți la clasa de pagini care sunt împachetate pentru variabilele de control, de exemplu:
Cu toate acestea, de regulă, această abordare nu este cea mai bună. Problema este că dezvăluie prea multe detalii, oferind astfel paginii țintă posibilitatea de a citi proprietățile tuturor comenzilor. Dacă mai târziu trebuie să schimbați pagina astfel încât să fie utilizate alte controale în ea, va fi foarte dificil să păstrați aceste proprietăți și, prin urmare, cel mai probabil, trebuie doar să rescrieți codul pentru ambele pagini.
O opțiune mai reușită este definirea unor metode sau a unor proprietăți specifice care să extragă doar informațiile necesare. De exemplu:
Prin această abordare, relația dintre pagini este bine documentată și nu prezintă dificultăți de înțelegere. Dacă modificați comenzile de pe pagina sursă, interfața pentru metodele sau proprietățile publice va rămâne probabil aceeași. De exemplu, dacă schimbați comenzile responsabile pentru obținerea informațiilor despre nume din exemplul anterior, trebuie să efectuați în continuare corecții la codul proprietății FullName. Cu toate acestea, după efectuarea tuturor acestor corecții în CrossPage1.aspx, pagina CrossPage2.aspx nu trebuie modificată deloc.
În unele cazuri, în loc de postback între pagini, este mai bine să folosiți un fel de control care simulează o multitudine de pagini sau mai mulți pași, de exemplu, comenzi separate, Panou, Multiview sau Expert. Aceste controale permit utilizatorilor să obțină același rezultat în același mod și să simplifice modelul de codificare.
Efectuarea trimiterii interstițiale în orice procesator de evenimente
După cum sa explicat în secțiunea anterioară, expedierea între pagini este disponibilă numai cu comenzile care implementează interfața IButtonControl. Cu toate acestea, există o soluție. Această cale implică utilizarea unei versiuni supraîncărcate a metodei Server.Transfer () pentru a trece la o nouă pagină ASP.NET, fără a afecta informațiile despre starea de vizualizare. Tot ce trebuie este să adăugați parametrul boolean preserveForm la această metodă și să-l setați la adevărat, după cum se arată mai jos:
Interesant este că există o modalitate de a distinge când inițierea returnării între pagini este inițiată direct prin buton și când - prin metoda Server.Transfer (). Deși accesul la obiectul Page.PreviousPage este posibil în ambele cazuri, într-o situație în care este utilizată metoda ServerTransfer (), proprietatea Page.PreviousPage.IsCrossPagePostBack este setată la false. Următorul cod arată modul în care funcționează această logică:
Returnarea și validarea intermediare
Când validarea este utilizată într-un script de întoarcere intercalată, există întotdeauna posibilitatea unor probleme. Să vedem ce se întâmplă când este aplicată returnarea între pagini, iar pagina de start include controale de validare. Figura următoare prezintă un exemplu de pagină care conține un control RequiredValidator care necesită introducere în câmpul de text:
Ambele butoane din această pagină au proprietatea CausesValidation setată la true. Prin urmare, dacă faceți clic pe butonul de returnare intercalată, codul de validare a clientului din browser nu va permite acest lucru. În schimb, va apărea un mesaj de eroare.
De asemenea, puteți vedea ce se întâmplă când scriptul client nu este acceptat de browser, prin setarea proprietății RequiredFieldValidator.EnableClientScript la false. (După îmbunătățirea codului, acesta trebuie setat din nou la adevărat.) Dacă faceți clic pe unul dintre butoane, pagina va fi trimisă înapoi la server și va apărea o nouă pagină.
Pentru a exclude acest comportament, înainte de a efectua orice altă acțiune pe pagina țintă, trebuie să verificați validitatea paginii originale utilizând proprietatea Page.IsValid. Aceasta este metoda standard de securitate utilizată în orice formă web care implementează validarea. Singura diferență este că, dacă datele de pe pagină sunt nevalide, doar nimic nu va fi de ajuns. Aici trebuie să faceți încă un pas suplimentar: reveniți la pagina originală. Iată ce aveți nevoie pentru codul din pagina de destinație:
Codul poate fi îmbunătățit. Acum, când utilizatorul revine la pagina originală, nu apare un mesaj de eroare, deoarece pagina este pur și simplu solicitată din nou (mai degrabă decât trimisă înapoi). Acest lucru poate fi corectat prin setarea unui semnalizator care să permită paginii sursă să știe că pagina a fost respinsă de pagina țintă. Următorul este un fragment de cod care adaugă acest steag la șirul de interogare:
Acum, pagina sursă trebuie să verifice prezența acestei valori în șirul de interogare și să efectueze o validare în consecință. Pentru orice date nevalide, se afișează mesaje de eroare:
Acest exemplu demonstrează că backflow-urile inter-paginilor sunt adesea mai complexe decât se așteaptă inițial de dezvoltatori. Utilizarea necorespunzătoare a acestora poate duce la pagini strâns interconectate, cu dependințe greu de detectat, ceea ce face dificilă schimbarea paginilor în viitor. Prin urmare, înainte de a le aplica ca o metodă de transmitere a informațiilor, asigurați-vă că ați cântărit toate argumentele pro și contra.
Articole similare
Trimiteți-le prietenilor: