Având în vedere o mare varietate de instrumente suportate de diferite browsere, uneori nu este ușor să creați o aplicație care să funcționeze cu toate browserele, oferind cea mai bună interfață de utilizator posibilă. Platforma ASP.NET oferă mai multe instrumente care vă pot ajuta să scrieți marcarea corectă care funcționează pe o varietate de dispozitive.
Clasa HtmlTextWriter
Platforma ASP.NET oferă o marcare foarte diferită pe care o vede clientul, astfel încât un client primește codul HTML 3.2. cealaltă este HTML 4.0. iar al treilea - XHTML 1.1. Nici măcar nu puteți suspecta diferențe semnificative.
Toate acestea funcționează prin clasa HtmlTextWriter, care are mai multe clase derivate. HtmlTextWriter însăși este proiectat ținând cont de rezultatul marcajului HTML 4.0. Dar clasele sale derivate se disting: Deci, Html32TextWriter înregistrează elementele de limbaj HTML 3.2 pentru clienții de nivel inferior, un XhtmlTextWriter - markup XHTML 1.1. Deoarece toate aceste clase moștenesc de la HtmlTextWriter, sunteți liber să utilizați codul de vizualizare este același set de bază de metode HtmlTextWriter. Cu toate acestea, punerea în aplicare a multora dintre aceste metode este diferit, astfel încât, în funcție de faptul dacă a fost obținut obiectul, producția poate diferi.
De exemplu, să presupunem că este folosit următorul cod de vizualizare:
În acest caz, se așteaptă un astfel de aspect:
Dar de mai jos arată rezultatul care se obține prin Html32TextWriter (presupunând că Html32TextWriter.ShouldPerformDivTableSubstitution este egal cu adevărat):
Pe de altă parte, dacă se folosește următorul cod, ieșirea randată va fi complet inflexibilă și nu se va schimba niciodată în funcție de capacitățile dispozitivului țintă:
În mod similar, dacă mosteniți de la WebControl pentru a obține suport automat pentru proprietățile de stil, acest suport este implementat diferit, în funcție de randător.
Din aceasta rezultă că este necesar să se evite nivel scăzut de scriere HTML marcare (folosind metoda de scriere ()), dar în schimb, în cazul în care este posibil, să utilizeze o metode de nivel înalt (cum ar fi RenderBeginTag () RenderEndTag (), etc.). Ca urmare, controalele devin mai flexibile. ASP.NET creează și transmite corecta HtmlTextWriter, care se bazează pe funcționalitatea browser-ului, este nevoie de pagină, și va fi capabil să se adapteze HTML-marcare.
Această problemă nu este acum la fel de critică ca și în trecut, deoarece cele mai frecvente browsere acceptă XHTML. Cu toate acestea, aceasta este regula unei bune soluții de design care garantează disponibilitatea corectă a codului în cazul în care ASP.NET este actualizat pentru a sprijini noi tipuri de vizualizare care nu au încă suport pe scară largă.
Definiția browserului
Deci, cum definește cadrul ASP.NET tipul de clasă de introducere a textului adecvat unui anumit client? Aici totul depinde de șirul agentului de utilizator care este trimis de client când execută cererea. ASP.NET încearcă să potrivească această linie cu un catalog uriaș de browsere cunoscute. Puteți găsi acest director în directorul C: \ [directorul Windows] \ Microsoft.NET \ Framework \ [Version] \ Config \ Browsers. Acolo puteți găsi multe fișiere .browser. Fiecare este un fișier HTML care afișează un șir de agenți personalizați pentru setarea capabilităților și a clasei de scriere a textului.
Fiecare fișier .browser are următoarea structură de bază:
Acest sistem poate părea destul de fragil. Din păcate, așa este. Nu există garanții că nu va exista un browser cu un șir care nu se potrivește cu nici unul dintre modelele cunoscute. Cu toate acestea, este inevitabil un compromis în lumea conectată slab de Internet, iar creatorii ASP.NET de locuri de muncă destul de bine peste un browser informațiile care vine cu ASP.NET 4.0, a fost de încredere și mai completă decât în versiunile anterioare. Setările pentru browser pot fi, de asemenea, personalizate și chiar pot adăuga definiții noi pentru diferitele șiruri de agenți personalizați.
Proprietățile browserului
Puteți determina configurația browserului curent folosind proprietatea Browser a obiectului HttpRequest, care returnează o referință la obiectul HttpBrowserCapabilities. (De asemenea, puteți obține șirul de utilizator-agent prin intermediul proprietății UserAgent.)
Când clientul execută o solicitare HTTP, este creat un obiect HttpBrowserCapabilities, care este populat cu informații despre capabilitățile browserului bazate pe fișierul .browser corespunzător. Informațiile furnizate în clasa HttpBrowserCapabilities includ vizualizarea și versiunea browserului, dacă suportă execuția script-ului pe partea clientului și așa mai departe. După ce ați determinat capacitățile browserului, puteți ajusta ieșirea pentru a oferi comportamente diferite în diferite browsere. Astfel, puteți să deblocați pe deplin capacitățile potențiale ale clienților de nivel înalt, fără a întrerupe activitatea lucrătorilor de nivel scăzut.
Următorul tabel afișează proprietățile clasei HttpBrowserCapabilities:
Proprietățile clasei HttpBrowserCapabilities
Oferă numărul versiunii senior a runtimei .NET CLR instalat pe computerul client. De asemenea, puteți utiliza metoda GetClrVersions () pentru a prelua informații despre toate versiunile de medii CLR instalate. Această setare este importantă numai dacă pagina Web are built-in controalele .NET Windows Forms. Browserele clienților nu au nevoie de un CLR pentru a rula pagini ASP.NET obișnuite
Returnează true dacă browserul client acceptă controale ActiveX
Clasa HttpBrowserCapabilities are o limitare izbitoare: poate determina numai funcționalitatea așteptată a browserului. Nu poate determina starea actuală a acestei funcționalități.
De fapt, tot ceea ce face ASP.NET de fapt este citirea informațiilor agentului de utilizator transmisă de la browser către server în momentul solicitării și compară acest șir cu informațiile predefinite din fișierele .browser. Fișierele .browser afișează caracteristicile browserului, cum ar fi funcționalitatea de a sprijini scripturi, stiluri, cadre etc. Din păcate, clientul nu trimite informații despre configurarea browserului.
Această situație lasă două opțiuni. Puteți să vă bazați pe clasa HttpBrowserCapabilities pentru a obține informații despre disponibilitatea anumitor instrumente de browser și pentru a vă baza logica software-ului la aceste informații. În acest caz, trebuie să fii pregătit pentru erori accidentale. Dacă preferați o abordare mai durabilă, va trebui să scrieți propriul cod astfel încât să verifice independent suportul instrumentului dorit.
Acești pași sunt mai degrabă ciudați și confuze, însă acesta este singurul mod de a obține încrederea deplină în disponibilitatea anumitor instrumente de browser. Din păcate, atunci când creați controale speciale, de obicei nu aveți capacitatea de a efectua astfel de controale.
Modificați definiția tipului de browser
Platforma ASP.NET oferă posibilitatea de a specifica în mod explicit modul în care va fi redată pagina, mai degrabă decât să se bazeze pe detectarea automată a browserului. Trucul este setarea proprietății Page.ClientTarget. sau programatic (la etapa Page.PreInit> fie declarativ (folosind directiva Page). În cazul proprietăților de setare ClientTarget browser-ului determinarea automată dezactivată pentru restul de interogare ASP.NET utilizează setările browser-ului, specificați.
Singura nuanță asociată cu utilizarea proprietății ClientTarget este abilitatea de a utiliza numai anumite pseudonime. Fiecare alias este mapat la un șir specific al agentului personalizat (iar instalarea browserului pentru acest agent personalizat este declarată în fișierul .browser corespunzător).
De exemplu, să presupunem că trebuie să verificați modul în care pagina va fi redată într-un browser învechit, cum ar fi Internet Explorer 6. În primul rând, trebuie să creați un alias în
Acum puteți forța pagina să folosească acest alias și să se vizualizeze, ca și cum cererea a venit din Internet Explorer 6, setând în ie6 atributul ClientTarget al directivei Page. Iată cum se face:
Vizualizare adaptivă
În mod ideal, puteți genera marcare care va funcționa în toate browserele importante. Dar, în unele cazuri, va trebui să scrieți o logică de vizualizare specifică browserului. În cel mai rău caz, arată cam așa:
Cea mai bună abordare implică utilizarea unui control pentru a vizualiza standardul de ieșire și crearea unui adaptor de control care implementează redarea specializată pentru un anumit browser. Modelul de adaptor adaptor vă permite să creați un singur control care poate fi adaptat diferitelor tipuri de dispozitive. Cel mai bine, datorită acestei separări a controalelor de la adaptoare, dezvoltatorii independenți pot scrie adaptoare pentru elementele existente, oferindu-le posibilitatea de a lucra cu alte platforme.
Orice control este asociat cu adaptorul în fișierul .browser. De exemplu, puteți crea un adaptor FirefoxSlideMenuAdapter care modifică codul de vizualizare al controlului SlideMenu astfel încât să funcționeze mai bine cu browserele Firefox. Apoi va trebui să editați fișierul mozilla.browser, precizând că acest adaptor ar trebui să fie utilizat cu browserele Firefox.
Adaptorul de control funcționează prin includerea în procesul de vizualizare. Platforma ASP.NET apelează adaptorul în fiecare etapă a ciclului de viață al controlului Web, permițând adaptorului să interfereze cu procesul de redare și să gestioneze alte detalii, cum ar fi logica stării de vizualizare specifice dispozitivului.
Pentru a crea un adaptor, o nouă clasă de moștenesc de la System.Web.UI.Adapters.ControlAdapter (în cazul în care un element de control special moștenit de la Control) sau System.Web.UI.WebControls.Adapters.WebControlAdapter (în cazul în care un control special este moștenit de la WebControl). Aplicați apoi funcționalitatea necesară, redefinind metodele dorite. Fiecare metodă corespunde unui control special clasă metoda și dacă metoda overriden în adaptor o metodă de control al adaptorului va fi utilizat în locul metodei de control.
Ca și în cazul controalelor de pe server, adaptorii trebuie să fie plasați într-un ansamblu DLL separat. Dacă adaptoarele sunt relativ simple, ele pot fi plasate în același ansamblu care conține comenzile. Cu toate acestea, în cazul în care adaptoarele sunt complexe și concepute pentru a sprijini scenarii de utilizare specializate, este de preferat să le plasați într-un ansamblu separat.
De exemplu, în ControlAdapter pot fi înlocuite metode cum ar fi OnInit (), Render () și RenderChildren (). In WebControlAdapter poate suprascrie RenderBeginTag (), RenderEndTag () și RenderContents ().