ASP .NET 4.0 #3 Ciò che non è cambiato

ASP .NET 4.0 è ormai alle porte, con la versione beta è possibile scoprire le novità  rispetto alla versione precedente, e non sono certamente poche, ma a livello di controlli lato server ce ne sono alcuni praticamente immutati rispetto alle precedenti versioni. Mi riferisco ad esempio al controllo Http File Upload, rimasto identico nelle varie versioni di ASP .NET che si sono succedute. Questo controllo soffre di qualche problema e non è certo il massimo in ottica web 2.0, ovvero su siti dove è richiesto una elevata user experience.

A meno di non utilizzare un controllo di terze parti probabilmente a pagamento, occorre fare i conti con il look del controllo rimasto identico nel tempo, con l’assenza di funzionalità  oggi richieste quali ad esempio la barra di progressione dell’upload in corso, e soprattutto con un fastidioso comportamento “by design”, ovvero la perdita del contenuto (il nome completo di percorso del file scelto) ad ogni postback della pagina; quest’ultima caratteristica è resa necessaria da motivi di sicurezza.

Se la pagina dispone di altri controlli che generano un postback, es. una dropdownlist, l’unico escamotage è quello di rendere il controllo File Upload l’ultimo controllo che genera postback in ordine di visualizzazione, in modo da invogliare l’utente ad interagire per ultimo con esso. In caso contrario, un postback della pagina provocherà  la perdita del suo contenuto, cioè del nome del file scelto, ed ovviamente obbligherà  l’utente a scegliere nuovamente il file da inviare.

Invocazione di metodo remoto da Javascript

A partire da ASP .NET 3.5 è possibile da JavaScript richiamare un metodo esterno, implementato nella stessa pagina aspx che invoca il codice Javascript, oppure in un ASP .NET XML Web Services (per intenderci, quello in formato .asmx), oppure in un WCF Services (in formato .svc), tutto questo senza passare attraverso il normale ciclo di vita della pagina, ma invocando semplicemente un metodo pubblico di una classe, visto che la pagina aspx è una classe a tutti gli effetti.

Al metodo è possibile passare dei parametri e ricevere indietro un valore di ritorno, che sarà serializzato / deserializzato in modalità JSON.

Se si ha la necessità di eseguire codice lato server senza passare dall’intero ciclo di vita della pagine, invocare un metodo pubblico della pagina è sicuramente la soluzione più veloce da implementare, poichè non necessita di creare una applicazione a sè stante (il web service o il WCF Service), e quindi è anche più facile da installare e da manutenere, ma non è esente da limitazioni, la maggiore delle quali è l’impossibilità di richiamare il metodo pubblico da parte di pagine diverse rispetto a quella in cui lo stesso è dichiarato (in tal caso è necessario creare un servizio web, ASP .NET XML Web Service oppure WCF Service).

Di seguito i passi necessari per richiamare un metodo pubblico esposto dalla classe che genera la pagina aspx, da codice Javascript:

  • E’ necessario creare un metodo pubblico e statico all’interno della classe che identifica la pagina aspx e decorarlo con l’attributo System.Web.Services.WebMethodAttribute;
[WebMethod]
public static string GetValueFromServer(string param1, string param2)
{
    return "TEST_RETURN_VALUE";
}
    • E’ necessario assegnare True alla proprietà  EnablePageMethods dell’oggetto ScriptManager ospitato dalla pagina in questione (il valore di default è False), per abilitare l’invocazione di metodi di pagina;
<asp:ScriptManager ID="ScriptManager1" runat="server" EnablePageMethods="true" />
  • I due passaggi precedenti fanno in modo che nella pagina aspx sia iniettato del codice di script (inline) che permette di richiamare il “Web Method”. Questo codice di script comprende essenzialmente un oggetto chiamato “PageMethods“, il cui nome è hardcoded e quindi non modificabile, avente metodi statici con lo stesso nome dei metodi statici di pagina, mediante cui è possibile richiamare questi ultimi passando gli opportuni parametri, e indicando una funzione di callback che sarà automaticamente richiamata al termine dell’invocazione del metodo remoto e che conterrà il valore di ritorno di quest’ultimo, piu un metodo di callback opzionale che sarà automaticamente richiamato in caso di errore del metodo remoto.
function Function1 {
    PageMethods.GetValueFromServer( param1, param2, onSuccessfullCall, onErrorCall);
}
  • La funzione di callback richiamata in caso di errore è opzionale. Occorre tener presente che l’invocazione del metodo remoto è asincrona, quindi il controllo tornerà immediatamente al codice Javascript chiamante. Al termine della invocazione del metodo sarà invocata automaticamente la funzione di callback opportuna (chiamata conlusa con successo o con errore). Nel caso di chiamata conclusa con esito positivo, la funzione di callback conterrà anche il valore di ritorno del metodo remoto invocato.
function onSuccessfullCall(results, userContext, methodName) {
    alert(results);
}
 
function onErrorCall(error, userContext, methodName) {
    if (error !== null)
        alert(error.get_message());
}
  • Il parametro results della funzione di callback richiamata in caso di invocazione riuscita conterrà il valore di ritorno del metodo remoto

ASP .NET 4.0 #2 Servizi "provider based"

Proseguendo nell’analisi delle nuove feature di ASP .NET 4.0 è evidente che l’architettura a providers, di cui tempo fa ho parlato in un articolo apparso su DotNetSide, è sempre più usata in modo intensivo per rendere quanto più modulare e personalizzabile l’application framework a disposizione.

Con la nuova versione di ASP .NET infatti questa architettura noto che sarà introdotta nei servizi di Output Caching, Browser Capabilities e Auto Start Application, almeno dalla documentazione in mio possesso.

Output Caching

Uno dei grossi limiti dell’ output caching delle precedenti versioni di ASP .NET è la limitatà flessibilità sul repository di memorizzazione dei dati in cache (output). Questi infatti potevano essere memorizzati solo nella memoria del server e da nessun altra parte. Come è facile intuire con la nuova versione è possibile scriversi un provider personalizzato per la memorizzazione dei dati e quindi utilizzare qualsivoglia repository a disposizione (es. disco locale, disco di rete, database, ecc)

Auto Start Application

Se si utilizza IIS 7.5 e Windows Server 2008 R2 insieme ad ASP .NET 4.0, è possibile far in modo che una applicazione si avvii in automatico ed esegua del codice di inizializzazione. Questo scenario si applica soprattutto a quelle applicazioni che necessitano di tempi lunghi per inizializzarsi, e quindi per evitare che questo overhead ricada totalmente sulla prima richiesta è possibile eseguire questo codice allo start-up automatico, ovvero senza che ci sia una richiesta di pagina esplicita. Questo codice può essere incapsulato in una classe provider, e quindi si possono avere n provider da utilizzare all’occorrenza in base alle specifiche esigenze.

Browser Capabilities

Questa funzionalità nelle precedenti versioni era fruibile solo mediante la modifica di files xml (.browser), a livello di macchina o di singola applicazione. Questi files xml non sono proprio il massimo per descrivere funzionalità come quelle del browser. Ora è possibile definire proprie funzionalità a livello di browser mediante l’uso di classi “provider based”

ASP .NET 4.0 #1 Nuova proprietà ViewStateMode

Per una applicazione ASP .NET soprattutto di livello enterprise la gestione del viewstate è sempre stato uno degli aspetti più delicati e, aggiungo io, più bistrattati in assoluto. Spesso e volentieri ho visto applicazioni di una certa complessità che ignorano completamente questo aspetto, che si traduce in pratica nell’utilizzo del valore di default della proprietà EnableViewState dei controlli di pagina (ovvero True), con conseguente saltataggio dei valori dello stato per tutti i controlli, a prescindere se questo salvataggio ha senso oppure no.

Anzi, spesso ho addirittura visto un utilizzo del ViewState a mò di Session, ovvero ho visto salvare informazioni aggiuntive rispetto allo stato dei controlli, e non parlo di tipi primitivi ma di veri e propri oggetti complessi, la cui serializzazione nel markup html provoca inevitabilmente un incremento notevole del peso della pagina web, con conseguenze facilmente immaginabili.

Con la prossima uscita della versione 4.0 di ASP .NET, lo sviluppatore avrà un controllo più fine sull’utilizzo del ViewState, soprattutto potrà impostare il valore di default desiderato in funzione della pagina che lo utilizza. Infatti, ogni server control (e quindi anche la classe Page) avrà a disposizione la proprietà ViewStateMode che potrà permettere ai controlli child situati all’interno di un contenitore (e quindi a tutti i controlli della pagina se guardiamo il livello più alto della gerarchia dei controlli), di ereditare la modalità di utilizzo dal rispettivo controllo container (valore Inherit), oppure di abilitare (Enabled) o disabilitare (valore Disabled) esplicitamente il Viewstate per un singolo controllo a prescindere dal valore impostato nel container.

Poichè il valore di default di questa nuova proprietà è Inherit, significa che a livello di pagina nessun controllo avrà il ViewState abilitato se non esplicitamente impostato dal programmatore.

Secondo me è un buon passo avanti verso la scrittura di applicazioni più efficienti.