Il framework ASP.NET Ajax implementa un sistema per la localizzazione delle applicazioni "lato client". Se abbiamo uno ScriptManager in una pagina, impostando l'attributo EnableScriptLocalization a "true" abilitiamo questa funzionalità che in sostanza "serve" dei file javascript in base alla cultura corrente. Prendiamo ad esempio il codice seguente e supponiamo che venga eseguita su un PC con impostata la localizzazione in lingua inglese (en-US ad esempio):
1: <asp:ScriptManager runat="server" ID="TheScriptManager"
EnableScriptLocalization="true">
2: <Scripts>
3: <asp:ScriptReference Path="~/js/Risorse.js" />
4: </Scripts>
5: </asp:ScriptManager>
Viene referenziato nello script manager il file Risorse.js, questo significa che il file in questione verrà inviato (o meglio la direttiva script..ecc verrà inserita nell'html prodotto dalla pagina) al client ql momento della richiesta della pagina. La particolarità è che, avendo abilitato l'apposita opzione dello ScriptManager (che per default è impostata a false) per la localizzazione, se nella posizione dove si trova il file js ne esiste una versione con nome Risorse.en-US.js, verrà servita questa in quanto corrisponde alla cultura correntemente impostata.
In questo modo è possibile creare dei file js contenenti le risorse necessarie alla localizzazione in diverse lingue e ASP.NET Ajax provvederà in automatico ad inviarci quello corretto per la lingua in uso. Un esempio di utilizzo potrebbe essere il seguente, un file di risorse fatto in questo modo:
1: Risorse = {
2: "Lingua" : "it-IT",
3: "testoBtnAnnulla" : "Annulla"
4: };
oppure in questo nella sua versione per la lingua inglese (con estensione .en-US.js)
1: Risorse = {
2: "Lingua" : "en-US",
3: "testoBtnAnnulla" : "Cancel"
4: };
Nel codice javascript del client ci basterà scrivere qualcosa tipo:
1: alert("La lingua corrente è: " + Risorse.Lingua);
Per ottenere un alert contenente un messaggio che cambierà in base alla lingua correntemente selezionata.
Fin qui tutto ok; qualche perplessità potrerbbe però nascere nel momento in cui la nostra applicazione debba gestire/memorizzare la cultura da utilizzare sul server. Già perche il sistema appena illustrato tiene conto in realtà della cultura corrente del client (dove gira il browser per intenderci) e non quella del server. Nella nostra applicazione invece potrebbe servire la cosa opposta perchè ad esempio la lingua impostata da utilizzare può essere impostata manualmente dall'utente attraverso l'interfaccia dell'applicazione e poi salvata nel profilo personale o in un cookie, e magari ci serve che sia lato server per localizzare altre parti/pagine dell'applicazione che "girano" soltanto sul server.
In questi casi si può comunque continuare ad utilizzare la tecnica appena descritta, con pochi accorgimenti. Prima di tutto possiamo in questo caso non abilitare la localizzazione automatica degli script, semplicemente impostando a false l'attributo EnableScriptLocalization dello ScriptManager o non impostandolo affatto in quanto come detto per default non è abilitato.
Ora possiamo sfruttare un'altra possibilità della localizzazione che consiste nel poter forzare per mezzo di un attributo la cultura con cui deve essere servito un particolare script dallo ScriptManager, semplicemente impostandola sul singolo riferimento per mezzo della proprietà ResourceUICultures come nell'esempio seguente:
1: <asp:ScriptManager runat="server" ID="TheScriptManager">
2: <Scripts>
3: <asp:ScriptReference Path="~/js/Risorse.js"
ResourceUICultures="it-IT" />
4: </Scripts>
5: </asp:ScriptManager>
In questo modo lo ScriptManager cercherà di utilizzare sempre e comunque un file scritto per la cultura italiana, indipendentemente da quella impostata sul client. Il prossimo passo per sfruttare questo meccanismo per il nostro scopo, è quello di fare in modo che il file di risorse javascript venga effettivamente inviato specificandone la cultura, ma quest'ultima sia impostata dal server prima della renderizzazione della pagina. Quello che serve quindi è semplicemente specificare il riferimento al file di risorse nello ScriptManager da codice a runtime impostandone di volta in volta la cultura da utilizzare (che ovviamente può cambiare anche da un postback all'altro.. l'importante è che per la cultura che si imposta ci sia un file js corrispondente, altrimenti le risorse non saranno inviate al client). Per farlo basta togliere dallo ScriptManager il riferimento al file Risorse.js dell'esempio ed aggiungerlo a runtime nel codice eseguito lato server, ad esempio nell'evento PageLoad della pagina in questo modo:
1: protected void Page_Load(object sender, EventArgs e)
2: {
3: // Riferimento al file di risorse da utilizzare
4: ScriptReference jsRisorse = new ScriptReference("~/js/Risorse.js");
5:
6: // la cultura viene impostata leggendola dal thread corrente,
7: // potrebbe essere diversa da quella del client
8: // e anche da quella di altri processi che girano sul server web
9: jsRisorse.ResourceUICultures = new string[1]
{ System.Threading.Thread.CurrentThread.CurrentUICulture.ToString() };
10:
11: // il riferimento con la cultura specificata viene aggiunto allo
12: // ScriptManager. Se ad esempio la cultura impostata fosse en-US
13: // è necessario che sia presente il file ~/js/Risorse.en-US.js
14: // perchè questo verrà effettivamente referenziato nell'HTML
15: TheScriptManager.Scripts.Add(jsRisorse);
16: }
E con questo abbiamo raggiunto il nostro scopo, cioè sul client verra servito il file js di risorse localizzato in base alle impostazioni memorizzate sul server, magari n el profilo dell'utente, e queste ultime possono essere diverse da quelle del PC client dove gira l'applicazione all'interno del browser.
Il titolo di questo post non è solo uno slogan da cartellone pubblicitario (anche se l'obiettivo è quello 
) ma un'iniziativa "lanciata" dal team del Microsoft MF per incoraggiare gli sviluppatori a prendere parte al programma di beta della nuova versione 3.0.
In sostanza, registrandosi al programma beta e scaricando l'SDK dal sito http://connect.microsoft.com/netmf entro il 31 Agosto, si riceve un "biglietto elettronico" ed il 15 Settembre verrà "estratto" il fortunato vincitore di un RicaVision Universal Remote Control (non so quanto utile, ma sicuramente un bell'oggettino)...
Per i numerosi appassionati di Micro Framework che ci sono da queste parti, una buona scusa per studiarsi le novità della nuova versione di questo framework che, a prescindere dalle trovate marketing, promette veramente molto bene. Ecco una sintesi delle novità che saranno introdotte (tratte dal sito ufficiale):
• Interop and native code linking
• Touch screen and inking/gesturing support
• USB device
• SSL (secure sockets) for the TCP/IP stack
• Visual Studio 2008 support
• DPWS (Devices Profile for Web Services), including new codegen tools
• 4bpp font support
• Enhanced and more compatible serial/UART model
• File system*
• 802.11 Wi-Fi infrastructure*
• Support for more cores and processor architectures*
• Publicly available Porting Kit for purchase* (separate product not included with the SDK)
(Features noted with * will not be available in the first public beta)
A questo punto non resta altro che provare...
Microsoft ASP.NET Ajax e l'Ajax Control Toolkit (di cui abbiamo parlato durante l'ultimo evento) mettono a disposizione numerosi controlli subito utilizzabili nella pallicazioni web per aggiungere funzionalità Ajax con il minimo sforzo. Spesso però per ottenere effetti e comportamenti un po' più "sofisticati" ed alla moda, c'è bisogno di scrivere qualche riga di codice in più.
Di seguito segnalo alcuni utili link di brevissimi articoli o vere e proprie "pillole" per personalizzare/migliorare l'utilizzo di alcuni controlli o semplicemente per capirne meglio il funzionamento:
Per ora è tutto. Ovviamente se qualcuno volesse condividere qualche altro link utile è liberissimo di lasciare un commento a questo post 
oppure si potrrebbe aprire una discussione direttamente sul forum.
Technorati tags:
Ajax,
Tips
Questo è il primo post (spero di una lunga serie 
) su dotNetUmbria quindi cosa dire se non.. un caloroso benvenuto a me .
Ormai a poche ore dall'evento vorrei approfittare subito per ringraziare Andrea e Paolo per la fiducia e la possibilità offerta sia a me che al "compare" Simone. Condividere queste avventure con amici vecchi e nuovi, parafrasando il famoso spot, non ha prezzo.
Per ora un saluto a tutti, ci vediamo l'8 Aprile mi raccomando!