[WPF] Feature o bug del Framework? (III° e ultima parte)

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!

posted @ mercoledì 12 novembre 2008 13.09

Print

Comments on this entry:

# re: [WPF] Feature o bug del Framework? (III° e ultima parte)

Left by Leonardo at 12/11/2008 22.37
Gravatar
Per visualizzare il "codice prodotto" formattato senza workaround potesti creare un Converter e impostare l'UpdateSourceTrigger del Codice a LostFocus.

# re: [WPF] Feature o bug del Framework? (III° e ultima parte)

Left by Nicolò Carandini at 13/11/2008 8.16
Gravatar

Qui la questione è più accademica che pratica, e riguarda il fatto che il framework WPF non onora la programmazione dichiarativa del binding two way. Con XAML noi definiamo cosa vogliamo, e WPF (dovrebbe) sapere come implementarlo. Esistono ovviamente molti modi di risolvere la questione, anche modificando l'interfaccia grafica, evitando in qualche modo di trovarsi in una situazione come quella che ho presentato con la mia applicazione. Ad esempio LudovicoVan propone di usare due campi, uno di editing del codice e uno come mostri il valore formattato. Sono tutte soluzioni valide, ma il punto è che io ho creato l'applicazione in questo modo proprio per evidenziare il comportamento IMHO improprio di WPF, non per avere suggerimenti su come cambiare l'applicazione demo!

Cmq grazie mille per il commento e la partecipazione, è molto gradita!

# re: [WPF] Feature o bug del Framework? (III° e ultima parte)

Left by LudovicoVan at 13/11/2008 17.39
Gravatar
Ti dico la mia:

> Qui la questione è più accademica che pratica

Direi che la questione e' piu' funzionale che tecnica. Funzionale qui sta a richiamare user needs, l'aspetto concettuale.

> , e riguarda il fatto che il framework WPF non onora la programmazione dichiarativa del binding two way.

Il framework onora la sua specifica, la quale, mi pare in questo caso, implementa un modello e, piu' in generale, un approccio alquanto canonici.

> Con XAML noi definiamo cosa vogliamo, e WPF (dovrebbe) sapere come implementarlo.

Questo non e' possibile: in generale, il computer intelligente ancora non esiste...

> Esistono ovviamente molti modi di risolvere la questione, anche modificando l'interfaccia grafica, evitando in qualche modo di trovarsi in una situazione come quella che ho presentato con la mia applicazione.

Potrei sbagliarmi, ma il mio era un esempio di un modo "tecnicamente sensato" di implementare una certa funzionalita', nel caso: input di codici semplificati.

L'enfasi restava "accademica", ma nel senso che ponevo l'accento sul "flusso di interfaccia" piuttosto che su un work-around ad un problema che a mio avviso neanche si pone, dato lo user-need in questione.

-LV

# re: [WPF] Feature o bug del Framework? (III° e ultima parte)

Left by Nicolò Carandini at 13/11/2008 23.08
Gravatar
@Julio (aka LudovicoVan): non siamo d'accordo, ma va bene lo stesso! Provo a commentare i tuoi commenti:

> Il framework onora la sua specifica, la quale, mi pare in questo caso, implementa un modello e, piu' in generale, un approccio alquanto canonici.

Non mi pare proprio. Binding two way implica che source e target contengano lo stesso valore. Capisco che non sia possibile farlo durante l'editing, ma usciti dal campo i due valori devono essere uguali. Non perchè lo pretendo io, ma perchè questa è l definizione di binding two way che da la documentazione del framework WPF.

> Questo non e' possibile: in generale, il computer intelligente ancora non esiste...

E dai, questo lo so anch'io! Ma io mi riferisco alla programmazione dichiarativa, fatta in XAML. E in questo caso sono i progettisti del framework che sono intelligenti ad aver realizzato WPF che sa come utilizzare la dichiarazione XAML per generare il codice...

Infine, se il problema non si pone, contento tu contenti tutti (nel senso che io il problema l'ho posto, e rimango dell'idea che sia un problema).

# re: [WPF] Feature o bug del Framework? (III° e ultima parte)

Left by LudovicoVan at 14/11/2008 11.45
Gravatar
Mettiamola cosi': se ci metti anche che al focus il codice viene ritrasformato a codice semplificato (cioe' il simmetrico del tuo lostFocus), allora mi piace, sia come flusso di interfaccia, sia perche' il codice torna ad essere piu' simmetrico.

Ma anche in quel caso, quanto al two-way binding, resto dell'idea che la necessita' di implementare un paio di handler per uno scenario in cui fai un bind "indiretto", con una trasformazione di mezzo e un flusso di nterfaccia ad hoc, non implica alcuna carenza nel motore di binding sottostante, che si colloca ad un livello di responsabilita' piu' basso.

-LV

# re: [WPF] Feature o bug del Framework? (III° e ultima parte)

Left by LudovicoVan at 14/11/2008 11.56
Gravatar
> Binding two way implica che source e target contengano lo stesso valore.

BTW, magari nota che questa definizione non corrisponde a quella fornita dalla specifica, che e' significativamente diversa. Binding two-way implica che ci sia un _trasferimento_ da source a target, o viceversa, _quando_ il source o viceversa il target _cambia_ di valore.

Fra le altre cose, non hai nessuna garanzia che il source e il target contengano lo stesso valore, e meno male, altrimenti lo scenario che proponi non sarebbe proprio stato possibile. Nel tuo esempio, e' il requisito stesso che richiede che questa corrispondenza non venga mantenuta.

-LV

# re: [WPF] Feature o bug del Framework? (III° e ultima parte)

Left by Nicolò Carandini at 14/11/2008 18.20
Gravatar
Ok, mi arrendo!

# re: [WPF] Feature o bug del Framework? (III° e ultima parte)

Left by LudovicoVan at 15/11/2008 3.32
Gravatar
Non tutte le ciambelle riescono col buco.

-LV
Comments have been closed on this topic.