Page processing - Solo quello che ti interessa
annuncio pubblicitario
Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ WEB FORM - Page processing La Web form non è altro che la pagina ASP.NET. Di seguito le nuove caratteristiche: - Strict XHTML rendering. Il codice generato relativa alla Web form è 100% XHTML-compliant. - Predictable client IDs. E' possibile identificare gli oggetti lato client grazie ad ID univoci - Nuova proprietà HtmlHead. Grazie a questa proprietà è ora possibile impostare i meta tag "descrizione" e le parole chiave da codice. - Permanent redirects. ASP.NET consente ora di reindirizzare le richieste con lo stato HTTP codice 301, che indica un redirect permanente. Quando i crawler dei motori di ricerca ottengono questo messaggio, aggiorneranno i loro cataloghi. Anche se ASP.NET consente di scrivere un'applicazione Web in modo molto simile ad un'applicazione Windows, ci sono però delle differenze: - Le applicazioni web sono eseguite sul server. Grazie alla tecnica del postback ASP.NET gestisce questo divario con l'applicazione desktop. Fare un postback significa inviare la pagina (e tutte le informazioni fornite dall'utente) al server, quando vengono eseguite alcune azioni sulla pagina. Una volta che ASP.NET riceve la pagina, si possono sparare i corrispondenti eventi serve-side per notificare il codice. - Le web application sono stateless. Quando una pagina viene renderizzata in HTML, tutti gli oggetti della pagina vengono distrutti e tutte le informazioni specifiche del client vengono scartate. Questo rende difficile ottenere un'esperienza utente senza soluzione di continuità. ASP.NET, però, include diversi strumenti per aiutare a colmare questa lacuna. Il più importante è l'uso del view state, che incorpora automaticamente le informazioni relative alla pagina in un campo nascosto nel rendering HTML della pagina. HTML Forms Il modo più semplice per inviare dati client-side al server è l'uso del tag <form> . Al suo interno è possibile inserire i tag di interfaccia (bottoni, textbox, radio button, ecc.). page 1 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ <html xmlns=" http://www.w3.org/1999/xhtml"> <head> <title>Programmer Questionnaire</title> </head> <body> <form method="post" action="Default.aspx"> <div> Enter your first name:&nbsp; <input type="text" name="FirstName" /> <br /> Enter your last name:&nbsp; <input type="text" name="LastName" /> <br /><br /> You program with:<br /> &nbsp;&nbsp;&nbsp; <input type="checkbox" name="CS" />C# <br /> &nbsp;&nbsp;&nbsp; <input type="checkbox" name="VB" />VB .NET <br /> <br /> <input type="submit" value="Submit" id="OK" /> </div> </form> </body> </html> Quando l'utente fa clic sul pulsante di invio, il browser raccoglie il valore corrente di ogni controllo e lo incolla in una lunga stringa. Questa stringa viene inviata alla pagina indicata nel tag <form> (in questo caso, default.aspx) mediante un'operazione HTTP POST. In questo esempio il web server potrà ricevere una richiesta con la seguente stringa di informazioni: FirstName=Matthew&LastName=MacDonald&CS=on&VB=on Il browser segue alcune regole per la costruzione di questa stringa. Le informazioni sono sempre inviate come serie di coppie nome/valore separate da '&'. Ogni coppia nome/valore è diviso da un segno di uguale. Le caselle di controllo sono omesse a meno che esse siano 'segnate', nel qual caso viene passato il valore on. Per vedere page 2 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ come si usa il Form andare su http://www.w3.org/TR/REC-html40/interact/forms.html. Tutti i framework di programmazione server-side aggiungono un livello di astrazione sui dati grezzi del modulo. In ASP e ASP.NET, è possibile cercare i valori in base al nome della variabile nella collezione Request.Form. Ad esempio: string firstName = Request.Form["FirstName"]; Questa soluzione è però lontana da una soluzione Object Oriented. ASP.NET quindi aggiunge qualcosa di più, in modo da usare un approccio più Object Oriented. Infatti consente di utilizzare la seguente sintassi: string firstName = txtFirstName.Text; dove però txtFirstName è il Server Control o l'HTML Control (runat="server") destinato a mantenere il valore del first name. Questo codice ha anche il vantaggio di essere indipendente dai tipi. In altre parole, se si sta recuperando lo stato della casella di controllo, riceverai un valore booleano vero o falso, invece di una stringa con la parola on. In questo modo, gli sviluppatori sono isolati dalle stranezze della sintassi HTML. In ASP.NET tutti i controlli sono collocati all'interno di un tag <form> che deve essere unico (contrassegnato con il runat = "server" in modo di lavorare sul lato server). Interfaccia utente dinamica Vediamo la differenza con ASP classico. Supponiamo di voler aggiornare una parte di testo in una pagina in modo da riflettere alcune informazioni inserite dall'utente subito prima. In ASP classico, si deve trovare un posto comodo per inserire un blocco di script che scrivere il codice HTML grezzo. Ecco un frammento di codice ASP che utilizza questo tecnica per visualizzare un messaggio di benvenuto di colore rosso: string message = "<span style=\"color:Red\">Welcome " + FirstName + " " + page 3 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ LastName + "</span>"; Response.Write(message); Utilizzando ASP.NET il tutto risulta più ordinato: <asp:Label id="lblWelcome" runat="server" /> lblWelcome.Text = "Welcome " + FirstName + " " + LastName; lblWelcome.ForeColor = Color.Red; DI seguito i vantaggi dell'uso di ASP.NET rispetto ASP classico: - Il codice ASP.NET è molto più facile da scrivere e quindi da mantenere. - Il codice ASP.NET possiamo scriverlo dove vogliamo. Nell'esempio precedente con ASP classico, invece dovevamo preoccuparci di dove inserire il codice in modo da far apparire il testo nel posto giusto. In ASP classico infatti l'organizzazione dei contenuti dinamici sisultava molto più caotica. - Non dobbiamo preoccuparci della sintassi HTML. - Non dobbiamo preoccuparci del tipo di browser che dovrà fare il rendering della pagina. Il Modello ad eventi di ASP.NET Classic ASP utilizza un modello lineare di elaborazione. Questo significa che il codice della pagina deve essere scritto considerando il fatto che questo viene elaborato in ordine dall'inizio alla fine. ASP.NET è invece event-driven. Ogni gestore di eventi è un metodo, che mantiene il codice della pagina ordinato e ben organizzato. Di seguito un breve riassunto di come gli eventi funzionano in ASP.NET: page 4 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ 1. La pagina viene eseguita per la prima volta. ASP.NET crea la pagina ed i controlli, il codice di inizializzazione viene eseguito, successivamente la pagina viene rederizzata in formato HTML e restituita al client. Gli oggetti della pagina sono poi rilasciati dalla memoria del server. 2. Ad un certo punto, l'utente fa qualcosa che fa scattare un postback, come ad esempio clic su un pulsante. A questo punto, la pagina viene mandata al server con tutti i dati del modulo. 3. ASP.NET ntercetta la pagina restituita e ricrea gli oggetti della pagina, tenendo cura della possibilità di restituirli allo stato in cui erano l'ultima volta che la pagina era stata inviata. 4. ASP.NET controlla quale operazione ha fatto scattare il postback, e richiama il gestore eventi appropriato (come Button.Click). In genere, verranno eseguire alcune operazioni lato server (come ad esempio l'aggiornamento di un database o la lettura di dati da un file) e quindi modifica gli oggetti della pagina per visualizzare le nuove informazioni. 5. La pagina modificata viene renderizzata in HTML e restituita al client. La pagina e gli oggetti vengono rilasciati dalla memoria. Se si verifica un altro postback, ASP.NET ripete i passi da 2 a 5. Ricordiamo che ASP.NET supera il problema dell'assenza del mantenimento dello stato di HTML e quindi permette al programmatore di non preoccuparsi di ciò (grazie al ViewState). Postback automatici A differenza della gestione degli eventi in un programa Windows, in ASP.NET le azioni dell'utente avvengono lato client, mentre l'elaborazione avviene sul lato server. Ciò significa che è sempre necessaria una certa quantità di overhead in risposta a un evento. Per questo motivo, eventi rapidi (come ad esempio lo spostamento del mouse) sono completamente impraticabile nel mondo di ASP.NET. Per gestire eventi di quest tipo occorre utilizzare codice JavaScript lato client, o controlli AJAX (che comunque utilizzano JavaScript). L'esecuzione lato server, garantisce comunque un più alto livello di sicurezza. Con i moduli HTML, c'è un solo modo per fare il submit (invio al server) di una pagina: facendo clic su un pulsante submit. Se usiamo i controll server HTML nei nostri moduli web .aspx, questa è ancora l'unica opzione. Fortunatamente, i controlli ASP.NET web estendono questo modello con una funzione di postback automatico. Con questa funzione, i controlli di input possono generare eventi diversi, e il codice lato server sarà in grado di rispondere immediatamente. Ad page 5 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ esempio, è possibile attivare un postback quando l'utente fa clic su una casella di controllo, o modifica la selezione in un elenco, o modifica il testo in una casella di testo e poi si trasferisce a un altro campo. Questi eventi sono ancora a soluzione grosollana se paragonata agli gli eventi in un'applicazione Windows, ma sono un significativo passo in avanti dal semplice pulsante submit. Il postback automatico "sotto il cofano" Per usare il postback automatico, basta settare la porprietà AutoPostBack del Web Control a True (di default il valore è False). ASP.NET utilizza sul lato client le capacità di JavaScript per colmare il divario tra client-side e il codice lato server. Vediamo come funziona: se creiamo una pagina web al cui interno abbiamo controlli con AutoPostBack a True, ASP.NET aggiunge una funzione JavaScript alla pagina HTML denominata __doPostBack(). Quando viene chiamata, essa innesca un postback e rimanda indietro al server la pagina con tutte le informaizoni del form. ASP.NET aggiunge anche due campi di input nascosti che il __doPostBack() utilizza per passare le informazioni al server. Questa informazione è costituita dell'ID del controllo che ha scatenato l'evento ed eventuali altri informazioni rilevanti. Questi campi sono inizialmente vuoti: <div> <input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" /> <input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" /> ... </div> La funzione __doPostBack() è responabile dell'impostazione in questi campi dei valori appropiati: <script type="text/javascript"> function __doPostBack(eventTarget, eventArgument) { if (!theForm.onsubmit || (theForm.onsubmit() != false)) { theForm.__EVENTTARGET.value = eventTarget; theForm.__EVENTARGUMENT.value = eventArgument; theForm.submit(); ... } </script> } ASP.NET genera automaticamente la funzione __doPostBack(). Il suo codice sarà più lungo quanti più controlli con la proprietà AutoPostback=True aggiungiamo nella pagina. Quanlunque controllo con tale proprietà a True sarà collegato alla funzione attraverso gli attributi onclick o onchange. Questi attributi indicano a quali azioni il browser deve esguiere in risposta agli eventi client JavaScript onclik o onchange. In altre parole, ASP.NET passa da un evento lato client JavaScript ad un evento page 6 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ server-side utillizzanod il __doPostBack() come intermediario. Il postback automatico è disponibile solo con i Controlli Web. View State E' ll meccanismo con cui ASP.NET risolve il probela della natura stateless di HTTP. Ogni informazione sulla pagina viene persa ad ogni postback, quindi non posso tornare allo stato precedente della pagina. Tradizionalmente il problema veniva superato con l'uso dei cookies ed altri espedenti, ma tutte queste sono però soluzioni poco sicure. Il problema è il seguente: se io scrivo del testo su un campo e faccio submit, la pagina che mi ritorna in teoria dovrà avere il campo testo vuoto. Invece: come viene garantito, al recupero della pagina, che venga mantenuto il valore di tale campo ? Grazie al meccanismo del View State la pagina che ritorna al client potrà andare su questo "camp nascosto" per recuperare i valori dei controlli che avevano prima del submit. Per far fronte a tale problema, quindi, ASP.NET ha messo a punto un meccanismo integrato di serializzazione dello stato. In sostanza, una volta che il codice della pagina ha terminato l'esecuzione e poco prima che il codice HTML finale venga renderizzato ed inviato al client, ASP.NET esamina tutte le proprietà di tutti i controlli della pagina. Se una qualsiasi di queste proprietà è stata modificata dal suo stato iniziale, ASP.NET ne prende nota in una collezione nome/valore. Infine, ASP.NET prende tutte queste informazioni che ha accumulato e le serializza come una stringa Base64. La stringa finale viene inserita nella sezione <form> della pagina in un nuovo campo nascosto. La volta successiva che viene esguto il postback della pagina, ASP.NET segue i seguenti passaggi: 1. ASP.NET ricrea la pagina ed i suoi controlli basati sulle impostazioni page 7 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ predefinite (come definiti nel file .aspx). In questo modo la pagina ha lo stesso stato che aveva alla prima richiesta. 2. ASP.NET deserializza le informazioni del view state ed aggiorna tutti i controlli. Questa operazione riporta la pagina allo stato in cui era prima di essere inviata al cliente l'ultima volta. 3. Successivamente ASP.NET risistema la pagina in accordo ai dati inviati dal modulo. Per esempio se il client ha inserito del nuovo testo in una casella di testo, l'informazione sarà mantenuta nella collezione del Form ed ASP.NET lo userà per modificare i controlli corrispondenti. Dopo questo passo la pagina rifletterà lo stato corretto all'utente. 4. Ora il nostro codice di gestione degli eventi potrà essere invocato. ASP.NET innesca gli eventi appropriati ed il nostro codice potrà reagire ai cambiamenti della pagina, passare ad una nuova pagina o eseguire un'operazione cimpletamente diversa. La soluzione del View State aumenta la dimensione della pagina, in quanto il View State viene memorizzato al suo interno. Questo influenza il client doppiamente, perché il client non solo riceve una pagina più grande, ma deve anche inviare i dati del View State al server con ogni postback successivo, in questo modo ci vorrà più tempo sia per ricevere che per inviare la pagina. L'overhead si manifesta maggiormente quando nelal pagina abbiamo controlli complessi come una GridView. E' possibile disabilitare il View State impostando la proprietà EnableViewState su false. Tuttavia, in questo caso è necessario reinizializzare il controllo con ogni postback. Anche se si imposta EnableViewState su false, il controllo mantiene sempre alcune informazioni per il suo corretto funzionamento e questo viene chiamato Control State. Questo diventa interessante quando scriviamo controlli personalizzati. Il View State è utilizzato solo per le proprietà di pagine e controlli. ASP.NET non prevede lo stesso comportamento per variabili membro ed altri dati. Tuttavia è possibile inserire altri tipi di dati nel View State e recuperare queste informazioni manualmente in un secondo momento. E' essenziale ricordare che il modulo web è ricreato con ogni andata e ritorno. Questo rimane in memoria per il tempo necessario al rendering di una singola richiesta. page 8 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ Il View State "sotto il cofano" Consideriamo una semplice pagina ASP.NET con una label che memorizza la scritta "Hello Word" ed un bottone SUBMIT. Nella pagina renderizzata sarà facile individuare il nostro campo nascosto: <html> <head> <title>Hello World Page</title> </head> <body> <form method="post" action="Default3.aspx" id="form1"> <div class="aspNetHidden"> <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/ wEPDwUKLTE2MjY5MTY1NQ9kFgICAw9kFgICAQ8PFgIe BFRleHQFDEhlbGxvIFdvcmxkIWRkZPsbiNOyNAufEt7OvNI bVYcGWH" /> ... </div> <div> <input type="submit" name="Button1" value="Button" id="Button1" /> <span id="lbl">Hello, world</span> </div> </form> </body> </html> E' possibile decodificare lato server, nel Page_Load con il codice seguente (è stata aggiunta una Label2 per visualizzare il contenuto decodificato): if (IsPostBack==true) { string viewStateString = Request["__VIEWSTATE"]; // viewStateString contains the view state information. // Convert the Base64 string to an ordinary array of bytes // representing ASCII characters byte[] stringBytes = Convert.FromBase64String(viewStateString); // Deserialize and display the string. string decodedViewState = System.Text.Encoding.ASCII.GetString(stringBytes); Label2.Text = decodedViewState; } Il testo decodificato avrà qualcosa di simile alla seguente stringa: page 9 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ ? -162691655dd-Text Hello, worldddd????4 ?????U?Xz? Come si può notare il testo risulta leggibile, quindi il View State non è il luogo per inserire informazioni sensibili; inoltre non fare affidamento sul contenuto del View State nelle nostre elaborazioni: non prendere decisioni in base al suo contenuto. Per rendere più sicure le nostre applicazioni è però possibile crittografare il View State in modo da non poter essere decodificato, oppure usare una funzione hash automatica. page 10 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ I blocchi del View State Alcuni server proxy, firewalls e browser mobili rifiutano campi nascosti più grandi di una certa dimensione. Per evitare questo problema ASP.NET divide in blocchi il View State. L'attributo maxPageStateFieldLength del tag <pages> del web.config, specifica la dimensione massima del View State, in byte: page 11 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ <configuration> <system.web> <pages maxPageStateFieldLength="1024" /> ... </system.web> </configuration> Quando la pagina richiede un View State più grande, ASP.NET lo divide in blocchi come nel seguente codice (anche se è molto raro che succeda): <input type="hidden" name="__VIEWSTATEFIELDCOUNT" value="3" /> <input type="hidden" name="__VIEWSTATE" value="..." /> <input type="hidden" name="__VIEWSTATE1" value="..." /> <input type="hidden" name="__VIEWSTATE2" value="..." /> Conformità XHTML Anche se i controlli ASP.NET sono conformi allo standard XHTML, tocca a noi rendere la nostra pagina nel complesso renderizzata in formato XHTML. XNTML non aggiunge funzionalità all'HTML 4.01, ma ha una sintassi più rigorosa. Questa contribuisce ad individuare piccoli errori, inoltre le pagine conformi risultano più semplici alle applicazioni da leggere o analizzare. Per le specifiche andare su http://www.w3.org/TR/xhtml11. Tutti i controlli ASP.NET rispettono lo standard, in particolare: - I nomi delle variabili e degli attributi sono in minuscolo. - Tutti gli elementi devono essere chiusi, o devono utilizzare un unico tag che si chiude(<br />). - Tutti i valori degli attributi devono essere racchiusi tra virgolette singole o doppie - L'attributo id deve essere usato al posto dell'attributo name. page 12 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ XHTML rimuove anche il supporto ad alcune caratteristiche ammesse in HTML come i frame e la formattazione senza CSS. Una caratteristica non presente in XHTML, ma comunque molto usata è l'attributo target . I seguenti controlli ASP.NET lo ammettono: AdRotator, TreeNode, HyperLink, HyperLinkColumn, BulletedList. Utilizzare l'attributo target rende la pagina non più conforme allo standard XHTML. Tale attributo comunque non causerà nessun problema di browser moderni. Tuttavia, se è necessario creare un sito web che deve essere completamente compatibile con XHTML, è necessario evitare di utilizzare l'attributo target. Nell'immediato non si intuisce il vantaggio dell'uso di XHTML, ma questo garantisce la compatibilità con le evoluzioni future dello standard. Sarà facilmente estendibile con nuove funzionalità di markup come XSLT, inoltre il documento XHTML può essere trasformato in altre forme basate su XML Document Type Definitions (DTD) Ogni documento XHTML deve iniziare con un doctype (Document Type Definition), che definisce il tipo di XHTML che utilizza. In una pagina ASP.NET, il doctype deve essere posto immediatamente dopo la direttiva di pagina. In questo modo, il doctype sarà renderizzato come prima riga del documento (è un requisito): <%@ Page Language="C#" AutoEventWireup="true" CodeFile="TestPage.aspx.cs" Inherits="TestPage" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > ... Questa pagina definisce anche lo spazio dei nomi XML per l'elemento <html>. Se non si vuole sostenere lo standard XHTML 1.1, si può fare un compromesso. Una possibilità è la scelta di XHTML 1.0 Transitional per il doctype, che in pratica applica le regole strutturali di XHTML ma permette funzionalità di formattazione HTML che nello standard 1.1 sono stati sostituiti dai CSS. Ecco il tipo di documento è necessario: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> Se abbiamo bisogno anche dei frame ma vogliamo rimanere con lo standard XHTML possiam usare il seguente DTD page 13 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd"> I controlli ASP.NET funzionano con qualunque doctype. Sta a noi scegliere il livello di standard da seguire. E' essenziale comunque inserire il DTD in quanto senza di questo ogni browser potrebbe avere un comportamento differente. Configurare il rendering XHTML I controlli server ASP.NET usano automaticamente lo standard XHTML 1.0 strict. Il rendering XHTML viene impostato tramite un attributo di file di configurazione chiamato controlRenderingCompatibilityVersion, che viene applicato sulla <pages>. Per impostazione predefinita, attributo è impostato nel web.config principale, in modo che si applica a tutte le applicazioni ASP.NET 4.0: <configuration> <system.web> <pages controlRenderingCompatibilityVersion="4.0" /> </configuration> ... </system.web> Impostando un valore diverso si impone la compatibilità con le versioni più vecchie di ASP.NET, ad esempio 3.5. Per ottenere le restrizioni più severe, eliminare tale attributo. Se si vuole usare la versione 3.5 è possibile utilizzare un altra impostazione sul web.config, <xhtmlConformance> che ha come attributo la voce more che può assumere i seguenti valori - Strict: ottiene un XHTML quasi pulito come quello che si ottiene con controlRenderingCompatibilityVersion="4.0" - Transitional: valore predefinito. Produce un rendering compatibile con XHTML, ma un piccolo gruppo di stranezze vietate dal rendering XHTML Strict (attributo name per <form>, border=0 per alcuni controlli). - Legacy: porta il rendering alla versione ASP.NET 1.1 Nota: Le incoerenze di rendering in ASP.NET 3.5 non comportano errori. I browser saranno sempre in grado di elaborare la pagina con successo, anche se si utilizza il doctype XHTML 1.1 rigoroso. Tuttavia, le incongruenze saranno segnalate come errore da uno strumento di validazione XHTML. page 14 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ Default doctype per Visual Studio Quando si screa una nuova web form, Visual Studio aggiunge automaticamente un doctype per l'XHTML Transitional. Se non si vuole questo, occorre modificare il doctype in ogni pagina. Se stiamo utilizzando una master page, basta impostare qui il doctype in modo che tutte le pagine figlio che la utilizzeranno lo acquisiranno automaticamente E' possibile ambiare il template della web page di Visual Studio, in modo da utilizzare doctype differenti, ma il procedimento è un po' tortuso. E' necessario prima modificare i template e poi fare il rebuild della cache dei template di Visual Studio. Di seguito i passi da seguire: - È possibile trovare i template di Visual Studio in una serie di file ZIP in diverse cartelle. Nel nostro caso è necessario modificare i file WebForm.aspx e WebForm_cb.aspx in c: \ Program Files \ Microsoft Visual Studio 10.0 \ Common7 \ IDE \ ItemTemplates \ Web \ CSharp \ 1033 \ WebForm.zip. Se siamo in una versione a 64 bit di Windows, al posto di c troveremo Program Files (x86). - copiare l'archivio su un'altra posizione, estrarre i file appropriati, modificarli, aggiungerli di nuovo all'archivio, e quindi copiare l'intero archivio nuovamente nella posizione originale. Questo perché è necessario disporre dei diritti di amministratore per modificare questi file. - Dopo aver aggiornato i template, eliminare la cartella C: \ Programmi \ Microsoft Visual Studio 10.0 \ Common7 \ IDE \ ItemTemplatesCache per cancellare il template dalla cache. - Eseguire Visual Studio utilizzando la seguente riga di comando per ricostruire la cache dei modelli (questo passaggio richiede privilegi di amministratore): devenv / InstallVSTemplates - È ora possibile eseguire Visual Studio normalmente. Tutti i nuovi template web aggiunti a una applicazione web dovrebbe avere il doctype nuovo che abbiamo impostato. Validazione XHTML Per assicurarsi che l'intera pagina sia XHTML-Compilant è necessario assicurarsi che qualunque contenuto statico che si aggiunge rispetti le regole XHTML. Vusual Studio ci corre in aiuto con un validatore built-in : attivare il menu Modifica Origine HTML e nell'elenco a discesa Schema di destinazione per la convalida selezionare il page 15 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ tipo di validazione da applicare. Tutti i tag non conformi verranno così evidenziati, come ad esempio il tag <br> in una validazione XHTML 1.1. Rimane però il problema dei controlli di terze parti: come si fa ad assicurarsi che il rendering di tali controlli sia l'XHTML-Compilant ? Occorre un validatore di terze parti. Una buona risorsa è il servizio gratuito di validazione W3C in http://validator.w3.org. Ricordiamo che questo deve essere fatto sulla pagina finale, quindi sull'URL o sul file aspx renderizzato (cioè sul codice presente nel browser). ID lato client dei controlli ASP.NET richiede che gli elementi lato client abbiano un ID univoco. Ma perché non usare gli stessi ID lato server ? In primo luogo, un controllo lato server può esistere senza server ID. In secondo luogo, un singolo controllo può occorrere più volte nella pagina in diversi container (come gli oggetti di una riga di una GridView che sono ripetuti per ogni nuova riga). Per far fronte a scenari come questi, ASP.NET fonde insieme all'ID del controllo server con tutti i suoi naming container, e (se si tratta di dati associati) anche con un indice numerico. Questo porta a lunghi e scomodi client ID, come il seguente : ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel_TextBox1 Un Naming Container è un controllo che implementa l'interfaccia INamingContainer. I Naming Container includono l'oggetto Page, gli User Control, i Content e tutti i controlli che possono essere associati ad un elenco di dati (dai più semplici HtmlSelect, ListBox, e CheckBoxList ai più ricchi come Details, FormView e GridView). Tuttavia non tutti i contenitori sono Naming Container, come ad esempio Panel che semplicemente avvolge l'elemento <div>. Il client ID può servire per fare riferimento ad un oggetto in un CSS oppure per fare manipolazioni con JavaScript, ma utilizzare quello generato di default risulta piuttosto complesso. A questo proposito ASP.NET 4.0 aggiunge la proprietà ClientIDMode che consente di modificare il sistema di denominazione di una intera pagina, di una sezione di una pagina, o un singolo controllo. Tale proprietà è un membro della classe di base Control da cui tutti i controlli Web ASP.NET derivano. Esso supporta quattro possibili valori: - AutoID: il client ID è generato concatenando gli ID del controllo con gli ID dei page 16 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ Naming Container, separati da un carattere di sottolineatura. Viene aggiunto un indice numerico se il controllo viene associato a un controllo dati. Per esempio: ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel_TextBox1. - Static: Utilizza lo stesso server ID per impostare il client ID. Questo è da usare in casi semplice. Infatti si può incorrere in problemi se il controllo viene ripetuto nella pagina in differenti Naming Container. Per esempio: TextBox1. - Predictable: viene usato lo stesso metodo dell'AutoID, ma non include l'ID della pagina di livello superiore (come ctl00) ed inoltre viene usata la proprietà ClientIDRowSuffix per generare valori univoci in un controllo associato ai dati (che ha più senso di un indice numerico standard). Per esempio: ContentPlaceHolder1_ParentPanel_NamingPanel_TextBox1. - Inherit: viene usata la strategia di denominazione del Naming Container padre. O, se questo è impostato nella pagina, utilizza la strategia di denominazione che è specificato nel tag <pages> del file web.config. L'impostazione predefinita di ClientIDMode è Inherit per ogni controllo. Ciò significa che il controllo prende il ClientIDMode del suo Naming Container padre. Questa eredità si propaga fino alla pagina di livello superiore, che eredita l'impostazione ClientIDMode dal <pages> del file web.config. In una nuovo sito ASP.NET 4, nel web.config principale viene impostato ClientIDMode=Predictable. ma in un sito web che è stata eseguita la migrazione ad ASP.NET 4 da una versione precedente di ASP.NET, Visual Studio imposta ClientIDMode=AutoID per la compatibilità. <configuration> <system.web> </system.web> </configuration> <pages clientIDMode="AutoID" /> ... Naturalmente è possibile rimuovere o modificare la proprietà ClientIDMode in base alle esigenze. Come scegliere la modalità giusta: - Se non è necessario fare riferimento a elementi lato client, non occorre pensare questo problema. page 17 / 18 Solo quello che ti interessa | WEB FORM - Page processing Copyright admin [email protected] http://www.belloma.it/web-form-page-processing/ - Se occorre fare riferimento ad un elemento lato client, il modo più semplice per farlo è impostare il valore Static. - Se si utilizzano spesso i controlli sul lato client che contengono controlli associati adi dati o elementi ripetuti è possibile impostare per questi controlli il valore Predictable (insieme alla proprietà ClientIDRowSuffix). page 18 / 18
