Sign in to follow this  
jwezorek

The problem with WPF ...

Recommended Posts

... 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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Edited by jwezorek

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this