Nel mio primo progettino con ASP.NET MVC mi si è presentata l’esigenza di dover presentare la stessa view in due modalità diverse (diverso titolo, una con link di modifica e l’altra no, ecc.).
Ingenuamente, siccome la prima modalità (link tipo Controller/List) esisteva già, ho pensato di usare una Action di questo tipo:
public ActionResult ViewList()
{
TempData["mode"] = "readonly";
return RedirectToAction("List");
}
delegando così tutto il lavoro di preparazione dei dati alla Action già in opera; nella pagina ho poi usato un paio di if (e si, mi capita ancora di usarli ;-)) per generare o meno i link per l’editing e per impostare il titolo.
Problema (di cui non mi sono accorto subito perché l’applicazione gira in un normale frame html che rende l’indirizzo visualizzato nella barra di IE sempre identico!): una volta eseguito RedirectToAction è come se avessi digitato quell’indirizzo (Controller/List nel mio caso) per cui se l’utente preme il pulsante Aggiorna del browser finisce nella prima modalità!
Soluzione “veloce”: ho spostato il codice presente nella prima action (Controller/List) in una funzione che richiamo da entrambe le action; la action ViewList è diventata:
public ActionResult ViewList()
{
TempData["mode"] = "readonly";
OnList_AddDataToViewData();
return View("List");
}
In un paio di progetti a cui sto lavorando attualmente mi si è ripresentata un’esigenza classica: memorizzare certe impostazioni (come la larghezza delle colonne di una datagrid) per ogni singolo utente. Il contesto è tale per cui ogni utente utilizza in genere la stessa macchina, per cui non c’è bisogno di distribuire le impostazioni da un server, ma basta salvarle sulla macchina.
Tempo addietro avevo risolto lo stesso problema serializzando e deserializzando una mia classe di impostazioni o utilizzando uno degli application block dell’enterprise library (mi sembra si chiamasse Configuration application block).
La serializzazione ha il grosso svantaggio che se aggiungo qualche opzione alla mia classe di impostazioni il file serializzato sul pc utente non è più valido; l’application block non mi risulta più presente nella Library.
Ho quindi deciso di dare un’occhiata alla gestione di user e application setting nel framework e ne sono rimasto piacevolmente sorpreso.
In sintesi:
- I setting di tipo application sono comuni a tutti gli utenti, mentre quelli di tipo user sono specifici di ogni utente.
- Nelle proprietà del progetto – Settings si aggiungono tutte le impostazioni necessarie specificando lo scope User o Application.
- L’ambiente aggiunge delle sezioni ad app.config e crea una classe Settings con una defaultInstance che ha proprietà in sola lettura per ogni impostazione con scope application e proprietà in lettura e scrittura per ogni impostazione con scope user.
[global::System.Configuration.ApplicationScopedSettingAttribute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
[global::System.Configuration.DefaultSettingValueAttribute("ApplicazioneDiProva")]
public string NomeApplicazione {
get {
return ((string)(this["NomeApplicazione"]));
}
}
[global::System.Configuration.UserScopedSettingAttribute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
[global::System.Configuration.DefaultSettingValueAttribute("UtentePredefinitoDiProva")]
public string NomeUtente {
get {
return ((string)(this["NomeUtente"]));
}
set {
this["NomeUtente"] = value;
}
}
- E’ possibile leggere le impostazioni user o application con la sintassi:
nomeApplicazione.Text = Settings.Default.NomeApplicazione;
nomeUtente.Text = Settings.Default.NomeUtente;
- E’ possibile modificare le impostazioni user (non application!) così:
Settings.Default.NomeUtente = nomeUtente.Text;
Settings.Default.Save();
Il sistema salva queste impostazioni nel file user.config nella cartella AppData dell’utente.
- E’ possibile ripristinare le impostazioni user (secondo il default salvato sia nell’app.config nella cartella del programma che nel codice della classe Settings) così:
Settings.Default.Reset();
Di tutto questo mi piacciono:
-
La semplicità (è gratis nel framework ;-));
-
La possibilità di ripristinare i valori di default;
-
Il fatto che il file delle impostazioni specifiche dell’utente viene salvato “per differenza” rispetto alle impostazioni di default e ne viene fatto il merge con le impostazioni di default; in questo modo se ad un nuovo rilascio aggiungo altre impostazioni il tutto funzionerà senza problemi mantenendo ciò che l’utente ha cambiato.