The problem with WPF ...

Started by
3 comments, last by jwezorek 11 years, 1 month ago

... is that you can't bind a XAML property to an arbitrary expression.

I understand the idea of separating presentation from business logic but presentation and business logic eventually do have to meet in some way. WPF as I understand it only allows this binding to happen using C# properties of a class instance that is a data context ... but C# properties are extremely blunt tools -- basically, if we forget OOP for a minute, C# properties are variables i.e. named values. Every programming language in recent times has offered various ways to access values beyond simple names precisely because simple names are often not rich enough for common use cases e.g. arrays let you access values with a name and an index, etc.

Advertisement

Vanilla (non-implicit) C# properties have nothing to do with variables, they're simply syntactic sugar to replace the ugly get/set methods of older languages. We naturally associate them with variables because get and set methods usually are, but you can always have a read-only property whose getter returns "x * y".

If you want to bind your WPF to an expression, simply create a read-only property whose getter returns your expression. If you implement INotifyPropertyChange and fire it whenever something causes the result of your expression to change, your object should be properly refreshed in the UI. This is the basis of Microsoft's MVVM design pattern, the pattern we're supposed to follow when using WPF.

Also, WPF bindings are actually powerful enough to allow searching through arrays and other collections. (Including dictionaries.) You can also bind to XML files.

If you want to bind your WPF to an expression, simply create a read-only property whose getter returns your expression.

yes, but a lot of times the expression isn't something you want to name with specific parameters; maybe a name would make sense with unspecified parameters i.e. maybe it would make more sense for it to be a method.

vanilla (non-implicit) C# properties have nothing to do with variables

I meant implicit ones are member variables with the language automatically providing a getter and a setter. They are named values associated with an object. But yeah.

How does binding to XML files work?

If you want to bind your WPF to an expression, simply create a read-only property whose getter returns your expression.

yes, but a lot of times the expression isn't something you want to name with specific parameters; maybe a name would make sense with unspecified parameters i.e. maybe it would make more sense for it to be a method.

In that case you have to resort to using a custom converter with a Convert method that does the call for you. This is the part where WPF can get annoying, especially if it's just for little things like "value - 10." If you have a lot of things like that to bind, you can easily find yourself with over 20 converter classes just for simple expressions. Fortunately, custom converters are pretty straightforwards and you can give your converter properties that hold the method's argument. Since object parameters can be set in XAML, it allows you to set the called method arguments in XAML. As long as you don't want to use a binding to set the arguments, it's not that bad.

How does binding to XML files work?

I haven't used it myself so I don't know how well (or bad) it works, but look up XmlDataProvider on MSDN. Basically, it's a data provider just like a normal database data providers, except that instead of binding to a database, it binds to XML. It looks like you can use XPath to search through the file.

In that case you have to resort to using a custom converter with a Convert method that does the call for you. This is the part where WPF can get annoying, especially if it's just for little things like "value - 10." If you have a lot of things like that to bind, you can easily find yourself with over 20 converter classes just for simple expressions. Fortunately, custom converters are pretty straightforwards and you can give your converter properties that hold the method's argument. Since object parameters can be set in XAML, it allows you to set the called method arguments in XAML. As long as you don't want to use a binding to set the arguments, it's not that bad.

I've used custom converters before but never thought about it like this. You know, you're right ... custom converters essentially allow you to bind to functions. I wonder if there would be some way to genericize this idea a little ... Need to think about it.

This topic is closed to new replies.

Advertisement