Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Reflections On WPF
Message
Information générale
Forum:
ASP.NET
Catégorie:
Windows Presentation Foundation (WPF)
Divers
Thread ID:
01466107
Message ID:
01466116
Vues:
58
[ ] IMHO, things like bindings and commands should be done in the code behind, because XAML doesn't provide for any logic. While you can declare bindings in the XAML, you can't do it conditionally.

Not sure what you mean on this one. I tend to declare most bindings in XAML - if the binding fails then it fails silently (i.e. no exception is thrown) and that, oddly enough, can be beneficial - if the binding makes sense then it's used; if it doesn't then the control is disabled......you can use that behaviour to your advantage


How would you do this in XAML?
if condition A
  bind to class X
else
  bind to class Y
Again, I think binding is the realm of the developer not the designer, and XAML is the realm of the designer, not the developer. I find it MUCH easier to do things like commands and bindings in the code behind.

While you might be able to do some things like this in XAML you can't do it all, which means some of your logic is now in the XAML and some in C#, which would get ugly fast.

Also, I don't know about you, but I WANT to know when a binding fails. Why would you want a silent failure to go unreported?
Everything makes sense in someone's mind
public class SystemCrasher :ICrashable
In addition, an integer field is not for irrational people
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform