di: Andrea Boschin 19 Maggio 2010
Pensando in termini astratti ad un comando è intuibile che in esso può essere individuato uno stato. Esistono infatti condizioni nelle quali un comando può essere eseguito piuttosto che situazioni in cui esso non è significativo - ad esempio perchè mancano i dati che ne consentono il funzionamento - la sua esecuzione potrebbe essere persino dannosa.
Se consideriamo l'esempio della scorsa puntata, eseguire il comando di ricerca quando la casella di testo è vuota è perfettamente inutile a potrebbe essere anche fonte di errori. A nostra tutela in tale situazione possiamo seguire due strade: possiamo innanzitutto validare la chiave prima di eseguire la ricerca e quindi di conseguenza interrompere l'esecuzione, oppure possiamo disabilitare il pulsante qualora la TextBox non sia ancora stata compilata. Questo seconda strategia ha il pregio di suggerire all'utente che deve ancora fornire ulteriori informazioni prima di compiere la sua ricerca.
L'interfaccia ICommand, implementata dalla classe DelegateCommand<T> che abbiamo impiegato la volta scorsa, fornisce gli strumenti necessari a questo scopo. Vediamo la sua definizione:
public interface ICommand
{
event EventHandler CanExecuteChanged;
bool CanExecute(object parameter);
void Execute(object parameter);
}
L'interfaccia in questione espone un metodo CanExecute e un evento CanExecuteChanged che hanno rispettivamente lo scopo di verificare se il comando può essere eseguito rispetto ad un eventuale parametro e di notificare che lo stato di "eseguibilità" è cambiato. Per mezzo della classe DelegateCommand possiamo facilmente trarre vantaggio di questa interfaccia come segue; dapprima forniamo al costruttore un metodo che restituisce un boolean che indica se il comando può essere eseguito:
public ProductViewModel(IProductRepository repository)
{
this.Repository = repository;
this.Products = new ObservableCollection<Product>();
this.SearchCommand = new DelegateCommand<object>(this.Search, this.CanExecuteSearch);
this.Load(string.Empty);
}
L'implementazione del metodo deve valutare se le condizioni attuali del ViewModel sono adeguate all'esecuzione del comando. Nel nostro caso il comando può essere eseguito qualora la proprietà SearchKey sia diversa da string.Empty.
public bool CanExecuteSearch(object state)
{
return !string.IsNullOrEmpty(this.SearchKey);
}
L'attached property Click.Command che abbiamo usato per collegare il DelegateCommand al Button è in grado autonomamente di gestire l'interfaccia ICommand e adeguare lo stato abilitato e disabilitato del pulsante al risultato del nostro metodo. A noi rimane il compito di notificare al DelegateCommand che lo stato del ViewModel è cambiato - ad esempio quando la proprietà SearchKey cambia - e di conseguenza chiedere una nuova valutazione:
public string SearchKey
{
get { return searchKey; }
set
{
searchKey = value;
this.SearchCommand.RaiseCanExecuteChanged();
}
}
Ogni qualvolta la proprietà SearchKey sia cambiata dall'utente, digitando nella casella di testo, il metodo RaiseCanExecuteChanged si occuperà di informare che è necessario verificare nuovamente se il comando può essere eseguito. In risultato è ovvio in questo caso: il nostro pulsante cambierà di stato e diverrà abilitato.
Guida Windows Azure Code SnippetsLe migliori pratiche per far girare le applicazioni "in the cloud",... |
Guida ASP.NET MVC Best PracticesUn workflow dettagliato e ricco di suggerimenti pratici per... |
Guida ASP.NET Starter KitUn modo semplice per imparare ad utilizzare le tecnologie Microsoft... |
Ogni giovedì, direttamente nella tua e-mail: articoli, guide, tutorial e script ASP, ASP.Net, SQL server e IIS.
Iscriviti alla newsletter
|
|
Corso Progettazione database11 Maggio 2012 a Milano |
|
|
Amministratore di Reti Windows Server 200811 Giugno 2012 a Milano |
|
Nessun corso previsto |