I am writing an app in WPF. It is getting tiresome making all my converters for simple stuff.
I looked around and found WPFix. It seems nice, but has not had any releases in almost a year and is looking abandoned.
Has anyone used this? Is it stable? Does anyone have any recommendations for a different solution to allow Lambdas in XAML (Or otherwise avoid lots of Converter)?
You are correct that there have been no official releases since 2008. However, the last source code check-in was done on October 22, 2009.
To skip to the last part of your question: This is a discussion on WPF Disciples that puts forward the notion that M-V-VM negates most of the need for converters; that the ViewModel should present the data to the View in a way that is appropriate for that View.
Why write a separate class, implement IValueConverter, flesh out the Convert and ConvertBack methods, just to get an Int32 to a Color, when you could just have the VM expose a Color property in the first place, right?
I guess the answer to that depends on how religious you are about separation between the View and the ViewModel... I'm starting to think that the ViewModel should simply present the Model and apply business rules to it, and should be 'View Agnostic', and maybe an intermediary layer is required to manipulate the ViewModel specifically for your View, so if you ever swap out your View (for whatever reasons!) you don't need to rewrite your VM, just the 'intermediary' layer... then it occurred to me that WPF already has such an intermediary in the form of ValueConverters...
So to summarise: You could remove lots of repetitive development of Converters by simply having your VM expose properties of an appropriate type in the first place...
Now you need to decide if you want to...
Just my 2c worth... :)
After looking at the author's examples in his first blog post, i think he has missed the point somewhat with WPF and XAML.
Sure it can be tiresome writing simple converters, but when you embed lambdas into your XAML you are starting down the road of having a monolithic view. To use the author's own example of presenting short dates, as soon as you start doing it with a lambda then you have to change your view when you have a user that requires a different format (i.e. mm/dd/yy, dd/mm/yy, yy/mm/dd). If these were kept as converters then they could be housed with a resource assembly and swapped out at will without changing the view. The same concept goes for anything else that would change due to the culture of the user.
Obviously the WPFix library could be cool for some things, and everybody will have a slightly different opinion on it. But as you write those converters, think of the declarative nature of XAML as a positive instead of a negative - it gives you abstraction between the actual presentation of the data and the preparation of that data for presentation. If you are writing a simple app or a quick prototype then mixing these two together (the View and the ViewModel) might be fine, but for larger scale productions you would find it beneficial to maintain a separation between those two.