Il Blog di Nicolò Carandini

Facendo seguito alla richiesta di Raffaeu, sono andato a googlare per documentarmi meglio sulla questione ed ho trovato una interessante pagina web al riguardo. Interessante non solo perchè contiene una marea di info che stanotte mi sbobbinerò, ma anche perchè è un esempio reale del sito stackoverflow.com, il sito utilizzato da Phil Haack nella sua recente presentazione di ASP.NET MVC al PDC 2008.

Ho sempre pensato che l'uso del componente <GRID> fosse un brutto rientro dalla finestra di ciò che più volte è stato cacciato dalla porta. Ad esempio, per anni (e forse molti ancora lo fanno) nelle pagine web si è usato e abusato del tag html <TABLE> per impostare graficamente la pagina. I Cascade Style Sheet hanno dimostrato che si può fare a meno di tabelle, separando contenuto e formato.

Nella recente after hours tenuta a Roma, ho potuto notare come l'applicazione dimostrativa facesse pesante uso di <GRID>, introducendo notevoli complessità di cui magari parlerò in un'altro post.

Finalmente un post di Karl Shifflett dimostra che è possibile semplificare la produzione di Forms LOB (Line Of Business) evitando del tutto l'uso di <GRID>.

Un post eccezionale, perchè contiene molte cose da studiare con spunti di riflessione interessantissimi, ma dimostra una volta di più la potenza produttiva di WPF e la sua versatilità, frutto di una vera genialità di chi ha realizzato il framework.

Non è solo WPF che sta entrando in una fase di maturità e fruibilità (nuovi controlli, migliori strumenti di sviluppo, ecc. ecc.) ma anche la comprensione del Framework (grazie anche alla sua divulgazione per tramite di gente del calibro di Karl, Dr. WPF, Josh Smith, e Corrado Cavalli) è oramai disponibilie per tutti.

Ovviamente WPF pecche ancora ne ha (ad esempio la scarsa leggibilità del testo piccolo lamentata da alcuni) ma sono certo che il tempo è arrivato, e volenti o nolenti avremo presto TUTTI a che fare con WPF. E questa non è una minaccia...

Disclaimer:

Ogni enfasi contenuta in questo post è puramente personale, ed è dovuta alla notevole alienazione del soggetto scrivente, in fase di dipendenza acuta e cronica da WPF !

Dopo aver presentato il contesto (I° parte) e una dimostrazione (II° parte) voglio concludere con una mia considerazione al riguardo, visto che Julio Di Egidio (aka LudovicoVan) è stato così stoico da vedersi tutto il video (lo ammetto, sono a dir poco soporifero) e lasciare un commento.

Come lascia intendere il titolo del post, il comportamento di WPF è in parte una feature, quando inibisce il round trip del binding two way sul componente attivo (la textbox di cui stiamo editando il contenuto) perché evita di andare in loop e di modificarmi sotto il naso il valore che sto editando, e IMHO un errore quando uscendo dal componente il valore non viene aggiornato al valore bindato.

Julio in un suo commento alla II° parte del mio post mi chiede come avrei fatto io. Semplice: poichè il componente con il focus riceve comunque l'evento NotifyPropertyChanged e lo ignora (giustamente visto che ha il focus), WPF potrebbe fare in due modi:

1. Quando perde il focus, in ogni caso andare a leggere il valore bindato (nel nostro caso la proprietà Codice dell'oggetto Prodotto). E' vero che potrebbe fare un "giro" inutile, perchè magari non ha mai ricevuto l'evento NotifyPropertyChanged e quindi il valore bindato non è cambiato, ma almeno viene sempre rispettato il contratto di binding che noi abbiamo dichiarativamente richiesto;
2. In modo più efficente, il controllo potrebbe porre a true una proprietà bool NotifyPropertyChangedReceived, in cui mettere in stand by l'evento ricevuto, ed eseguire le operazioni di aggiornamento del binding quando il controllo perde il focus.

In ogni caso, rimane fermo un punto incontrovertibile: usando l'XAML, noi dichiariamo un binding two way, e così facendo non dovremmo occuparci di come WPF lo fa. Sono cavoli suoi. Il fatto che io usi una interfaccia grafica per così dire curiosa o strampalata, perchè faccio una formattazione del valore che si sta editando non significa nulla. Il Framework DEVE gestire anche questa modalità (o impedirla del tutto, se ve n'è motivo). Di fatto la mia applicazione dimostra che senza l'uso del workaround si finisce in uno stato in cui il campo mostra un valore che non è quello della proprietà bindata, quindi WPF non onora la nostra dichiarazione di binding two way.

E questo, parafrasando GhostBuster, è male!

-----------------------------------------------------------------------------

Egon: Mai incrociare i flussi!
Peter: Perché?
Egon: Sarebbe male.
Peter: Faccio sempre confusione tra il bene e il male, che intendi per male?
Egon: Immagina che la vita come tu la conosci si fermi istantaneamente e ogni molecola del tuo corpo esploda alla velocità della luce.
Ray: Inversione protonica totale!
Peter: E quello è male... Ok è un importante ragguaglio, grazie Egon!