MultiBinding == Worst Practice?
Justin Angel (SILVERLIGHT)
Hi,
As follow up to a thread on the Silverlight forums (http://silverlight.net/forums/p/92028/212232.aspx#212232) I wanted to get your opinion on –
MultiBindings are they the 3rd horse rider of the XAML apocalypse or not?
In our MVVM sensitive world frame, I'll go as far as suggesting that if you have more than a single data source for the same UIElement à You're doing it wrong.
Why on earth would you have a control that needs more than the VM of its container?
Or even outside the MVVM architecture when you're Databinding to straight CLR Classes, why on earth would you Databinding to completely 2 separate classes?
If myControl needs information from both myFirstBusinessClass and mySecondBusinessClass doesn't that mean there's a business relation here?
When I googled for "WPF MultiBinding" I got some bad samples for real world code.
1. http://www.stackenbloggen.de/PermaLink,guid,ce63f9a5-ccaa-4777-bf3d-d54e69eadec9.aspx
No no no! You've Got Red, Green and Blue! Obviously there's a business correlation here between them. Why on earth is it expressed as a UI effect?
2. http://www.switchonthecode.com/tutorials/wpf-tutorial-using-multibindings
Oh yeah, I often thought to myself "Hey, I've got some UIElements here and I'd like to AVG they're value. I know, Let's do that in the UI!".
F***ing hell, he's doing a math function between user input, this is the most textbox business logic sample I've ever seen.
The data is visualized for some reason, right? It has some significance? And obviously the developer is going to duplicate it elsewhere? So just put it in the business objects.
3. http://www.developingfor.net/wpf/multibinding-in-wpf.html
Really? There's a UI piece there called "SelectedItemIndexIsNotLastToBoolean", and people can't see this maybe has something to do with business logic?
Summing it upm I'm not seeing any valid real-world application building usage for multi bindings.
There are (however) some valid scenarios when building custom controls.
-- Justin
(Architecture makes me mad. And non-fizzy soda too.)
Mark Smith
Mike Brown
Eric Burke
From: Mike Brown <mbro...@gmail.com>
To: wpf-di...@googlegroups.com
Sent: Monday, April 27, 2009 11:34:07 PM
Subject: [WPF Disciples] Re: MultiBinding == Worst Practice?
Colin Eberhardt
stick!
I think the main problem is that they were just bad examples. The code
for averaging 3 scrollbars was far too contrived. It gives the read an
idea about what MultiBindings are, but no hint about where you might
really use them in you application. Personally I don't think the RGB
example is so bad. I can imagine this encapsulated within a custom
control that exposes R, G and B properties.
The problem is that when you are writing a blog post that highlights
some framework feature or something which you have developed, you want
the blog post to be focussed so that people take home the right
message. Adding MVVM into the mix can dilute your message.
I was going to point out that I found MultiBindings to be very useful
for creating a Bullet Graph control:
http://www.codeproject.com/KB/WPF/WpfWinFormsBulletGraphs.aspx
Where I have a converter that takes max, value and range from a
multibinding. However, I see you let custom control developers off the
hook! Which surprises me a little, especially if you view controls as
MVVM patterns in miniature.
I guess that if multibindings only really make sense in purely UI
binding scenarious, then they are no great loss in Silverlight where
purely UI binding is not provided by the framework.
Regards,
Colin E.
On Apr 28, 12:56 am, "Justin Angel (SILVERLIGHT)"
<Justin.An...@microsoft.com> wrote:
> Hi,
>
> As follow up to a thread on the Silverlight forums (http://silverlight.net/forums/p/92028/212232.aspx#212232) I wanted to get your opinion on -
>
> Or even outside the MVVM architecture when you're Databinding to straight CLR Classes, why on earth would you Databinding to completely 2 separate classes?
> If myControl needs information from both myFirstBusinessClass and mySecondBusinessClass doesn't that mean there's a business relation here?
>
> When I googled for "WPF MultiBinding" I got some bad samples for real world code.
>
>
> F***ing hell, he's doing a math function between user input, this is the most textbox business logic sample I've ever seen.
> The data is visualized for some reason, right? It has some significance? And obviously the developer is going to duplicate it elsewhere? So just put it in the business objects.
>
![Laurent Bugnion, GalaSoft [MVP, MCP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUZ1C0QF1G84zUk-Bh1HAUf-2r0XJ2I0-e64mZ_kPpVPghO3A=s40-c)
Laurent Bugnion, GalaSoft [MVP, MCP]
Element binding exists on SL3.
I find multibinding useful sometimes when i need reference to more than onw
UI element, or to trigger a calculation based on some changes in the UI. For
example, i had one case where i used a multibinding to trigger a calculation
when the window's size changed. I didn't use the ActualWidth value in the
converter at all, but when the value changed, the binding was 'triggered'.
So yes, they can be useful, but i agree with Justin, if they are used to
bond to multiple data elements, it kind of smells...
Laurent
-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Colin Eberhardt
Sent: Tuesday, April 28, 2009 7:17 AM
To: WPF Disciples
Subject: [WPF Disciples] Re: MultiBinding == Worst Practice?
Karl Shifflett
I use MultiBinding on my FormNotification control.
I need to merge error messages that have different origins.
The FormNotification control merges validation messages reported via
IDataErrorInfo and binding exceptions from the UI.
I've used it a few other places, just don't remember the exact case.
Karl
Paul Stovell
I think multi bindings have their place. And I also think the suggestion that they can be replaced with MVVM is just one of the many interpretations of "MVVM" that abound.
For example, I once built a scheduling view that showed timesheet entries for a person over the course of a week. So I had an object like this:
class Entry
{
DateTime Start { get; set; }
DateTime End { get; set; }
}
I was displaying them in a <Grid/>, so my plan was to convert the Start into a Grid.Row and the difference into a Grid.RowSpan. My ViewModel contained an offset date (e.g., first day of the month), which I'd use to figure out what the starting row should be.
In one interpretation of MVVM, I could have wrapped every entry and done the calculations in code. This would mean that the ViewModel knows a *lot* about how it is displayed. Some people like this level of coupling between the V and VM.
Personally, I'd like the "VM" to represent the state of the view, without being tightly coupled to how the view actually views things. So I did this:
<Grid.Row>
<MultiBinding Converter="{...}">
<Binding Path="Start" />
<Binding RelativeSource.... Path="Offset" />
Here, the MultiBinding did the offset. This allowed my VM to represent the "state" of the view, and my view to figure out how to render stuff. I prefer this interpretation of MVVM, though some do not.
>> In our MVVM sensitive world frame, I'll go as far as suggesting that if you have more than a single data source for the same UIElement à You're doing it wrong.
Paul
Paul Stovell
http://www.paulstovell.com
Bill Kempf
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
Mike Brown
Paul Stovell
Paul
Paul Stovell
http://www.paulstovell.net
Justin Angel (SILVERLIGHT)
Yikes! Sorry about the insanely long reply time folks, someone has to build the framework you know J (well, "a" framework that is)
Colin
Right, I did kinda pick on those useless examples for MultiBinding in those articles.
Reason being that I'm a firm believer in: "If you can't show me a real world use case for what it's good for – it isn't good for anything."
I'm a very pragmatic developer.
When Control authoring is kinda sorta OK in my world to do some unholy things.
Reason being, most of the WPF/Silverlight framework IMO was built for control authors.
But, it's a case by case basis.
Luarent
" I find multibinding useful sometimes when i need reference to more than onw UI element"
Every time you say something like that – a WPF architect is spinning in his office chair and we harness him/her for electricity.
If you need to reference more than one UI element in a binding – that's some seriously messed up logic you're introducing into your XAML.
That's the point when you look back for a second and realize that what you need isn't a bigger hammer but a screwdriver.
If 2+ UI Controls impact another UI control à UI Logic. But this in your VM and be done with it. No need for fancy XAML tricks.
Karl
"I use MultiBinding on my FormNotification control."
Right, Control authors can't really use ViewModels like god intended.
Unless you expose a FooControl.FooViewModel property and TemplateBind to it, which just feels too Java Swing to me.
So – for you and other control authors – I absolve you from perdition for using MultiBinding.
Though, honestly, merging error messages has the element of sorting, which is getting pretty close to serious UI logic.
Maybe you should consider alternatives.
Mike + Eric
I almost buy the String.Format excuse. Almost.
But it's pure and simple UI logic.
1. You shouldn't hardcode strings in XAML In a globalized app – ever.
2.
If you're globalizing
string literals you're probably globalizing the entire sentence construct.
Different languages place different type of words (noun, verbs, adjs, etc) elsewhere
in the sentence.
Unfortunately I speak 9 languages so I'm very much aware of linguistically differences between languages.
This:
<TextBlock>
<TextBlock.Text Foreground="Green" FontFamily="{StaticResource LabelInstructionsFont}">
<MultiBinding Format="{}Age must be between {0} and {1}).">
<Binding Path="MinAge" />
<Binding Path="MaxAge" />
</MultiBinding>
</TextBlock.Text>
</TextBlock>
Should be:
<TextBlock Foreground="Green" FontFamily="{StaticResource LabelInstructionsFont}" Text="{Binding ViewModel.AgeWarning}" />
public class FooViewModel
{
public string AgeWarning
{
return string.Format("Age must be between {0} and {1}", Model.MinAge, Model.MaxAge);
// or more globalized: return string.Format(Resources.AgeWarning, Model.MinAge, Model.MaxAge);
}
}
Don't see why we need fancy XAML everywhere that introduces fancy problems where 1 readonly property in the viewmodel solves it much better.
Paul + Bill
Right, I don't want to go into theological debates over the place of a ViewModel.
Something somewhere needs to be able to do the UI logic in a way that's strong coupled to the UI.
XAML isn't built for that IMO. Trying to cheat your way into solving a massive behavioral problem with MultiBindings just creates more problems than you ended up solving.
XAML is good for Layout, data representation, visuals and some light hearted behavior.
But, once you try and force business logic (or 'business' UI logic) into XAML you'll get a serious push back from it.
I'm with Bill here, something needs to be strong coupled to the UI that does the heavy lifting for UI logic in code.
Call it a ViewModel, Call it Behaviors, call it code behind/beside/near/nextto/just-take-a-left-at-the-third-light, whatever.
But whatever that thing is – it should do whatever multibindings do for you. i.e. UI Logic.
-- Justin
(Making friends wherever I go J)
From:
wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On
Behalf Of Bill Kempf
Sent: Monday, May 04, 2009 4:48 AM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: MultiBinding == Worst Practice?
I agree with a lot of what you say, but there were two things that stood out. The first was "This would mean that the ViewModel knows a *lot* about how it is displayed. Some people like this level of coupling between the V and VM." I actually adhere to this viewpoint. The VM is just that... a model of the view. As such, it's very tightly coupled to the view. That doesn't mean I want to go out of my way to make the coupling tighter (for instance, for UI specific stuff I prefer to use behaviors, converters and attached properties when possible), but I'm not going to have ANY heartburn over adding state to the VM to provide richer state for the View.
Next, "The WPF MVVM Toolkit worries me, because we now have a Microsoft(R) Offical(TM) Way To Architect Your App(TM)." That doesn't really worry me that much (though I've not yet had the chance to look at the toolkit). Good developers now there's more than one way. Bad developers aren't really any worse off, unless the "One Way" is generally bad. If you believe otherwise, than MS sh
ould give up now, because no matter what they do, they'll be "enabling bad developers".
On Sun, May 3, 2009 at 11:44 PM, Paul Stovell <sto...@gmail.com> wrote:
Hi Justin,
I think multi bindings have their place. And I also think the suggestion that
they can be replaced with MVVM is just one of the many interpretations of
"MVVM" that abound.
For example, I once built a scheduling view that showed timesheet entries for a
person over the course of a week. So I had an object like this:
class Entry
{
DateTime Start { get; set; }
DateTime End { get; set; }
}
I was displaying them in a <Grid/>, so my plan was to convert the Start
into a Grid.Row and the difference into a Grid.RowSpan. My ViewModel contained
an offset date (e.g., first day of the month), which I'd use to figure out what
the starting row should be.
In one interpretation of MVVM, I could have wrapped every entry and done the
calculations in code. This would mean that the ViewModel knows a *lot* about
how it is displayed. Some people like this level of coupling between the V and
VM.
Personally, I'd like the "VM" to represent the state of the view,
without being tightly coupled to how the view actually views things. So I did
this:
<Grid.Row>
<MultiBinding Converter="{...}">
<Binding Path="Start" />
<Binding RelativeSource....
Path="Offset" />
Here, the MultiBinding did the offset. This allowed my VM to represent the
"state" of the view, and my view to figure out how to render stuff. I
prefer this interpretation of MVVM, though some do not.
>> In our MVVM sensitive world frame, I'll go as far as suggesting that
if you have more than a single data source for the same UIElement à You're doing it wrong.
As an architect, if you say there's only one way to do
something, you're doing it wrong :-) The WPF MVVM Toolkit worries me, because
we now have a Microsoft(R) Offical(TM) Way To Architect Your App(TM). So all
other interpretations of the pattern are out.
Paul
From:
wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On
Behalf Of Eric Burke
Sent: Monday, April 27, 2009 8:45 PM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: MultiBinding == Worst Practice?
MultiBinding is key to proper localization because different languages rearrange words. In English it might read "{0} does something to {1}" but in German it could be "{1} has something done to it by {0}". The translators may completely change the wording to make it clearer to the user, you never know.
You need a StringFormat because you can't do it all in XAML. For instance, if you had this:
<TextBlock>
<TextBlock Text="{Binding Value1}"/>
<Run Text=" does something to "/>
<TextBlock Text="{Binding Value2}"/>
</TextBlock>
not only is it impossible to translate properly (unless you wanted to stick it in a resource DLL, which gets tedious real fast), but the translators (who are often 3rd party people who know squat about programming) look at it and go, "Huh?!?!".
However, it is simple to teach them that {0}, {1}, {2} are words that get filled in later, and put comments as to what they represent in the code or in your translation system or whatever the translator actually sees, and tell them to please not change the {0}, {1}, {2} but feel free to move them around.
[Also, 3rd party translators get paid by the word, and the more times they kick things back to you incorrectly, the more it costs you. ;)]
From: Mike Brown <mbro...@gmail.com>
To: wpf-di...@googlegroups.com
Sent: Monday, April 27, 2009 11:34:07 PM
Subject: [WPF Disciples] Re: MultiBinding == Worst Practice?
Laurent Bugnion [MVP]
Hey Justin,
Well, you do need electricity, right? ;)
I must admit that the last time I used a multibinding is quite some time ago. It is possible that there was another, more elegant solution.
If your question is “Do you want Multibinding in Silverlight, or can you live without it”, I would probably say that it is not the highest concern on my list, not by a far cry.
If you ask “Should we remove multibinding from WPF”, then I would say no, don’t remove it, because I am sure that there are applications who depend on it for probably a good reason. Would it be possible to implement another, more elegant solution? Well probably.
Does that make sense? Or are more architects spinning?
Laurent
Justin Angel (SILVERLIGHT)
LOL, No, I'm definitely not asking about that J
I just hate multi bindings. Plain and simple.
On the other hand I also hate: Triggers, DateTemplateSelector, ValueConverters, manually coding XAML and things-that-when-you-give-them-a-good-Thump!-still-don't-work.
-- Justin
Laurent Bugnion
Cheers,
Laurent
--
Sent from mobile
-original message-
Subject: [WPF Disciples] Re: MultiBinding == Worst Practice?
From: "Justin Angel (SILVERLIGHT)" <Justin...@microsoft.com>
Date: 09.05.2009 00:37
LOL, No, I'm definitely not asking about that :)
I just hate multi bindings. Plain and simple.
On the other hand I also hate: Triggers, DateTemplateSelector, ValueConverters, manually coding XAML and things-that-when-you-give-them-a-good-Thump!-still-don't-work.
-- Justin
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Laurent Bugnion [MVP]
Sent: Wednesday, May 06, 2009 12:08 PM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: MultiBinding == Worst Practice?
Hey Justin,
Well, you do need electricity, right? ;)
I must admit that the last time I used a multibinding is quite some time ago. It is possible that there was another, more elegant solution.
If your question is "Do you want Multibinding in Silverlight, or can you live without it", I would probably say that it is not the highest concern on my list, not by a far cry.
If you ask "Should we remove multibinding from WPF", then I would say no, don't remove it, because I am sure that there are applications who depend on it for probably a good reason. Would it be possible to implement another, more elegant solution? Well probably.
Does that make sense? Or are more architects spinning?
Laurent
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Justin Angel (SILVERLIGHT)
Sent: Wednesday, May 06, 2009 8:52 PM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: MultiBinding == Worst Practice?
Yikes! Sorry about the insanely long reply time folks, someone has to build the framework you know :) (well, "a" framework that is)
Colin
Right, I did kinda pick on those useless examples for MultiBinding in those articles.
Reason being that I'm a firm believer in: "If you can't show me a real world use case for what it's good for - it isn't good for anything."
I'm a very pragmatic developer.
When Control authoring is kinda sorta OK in my world to do some unholy things.
Reason being, most of the WPF/Silverlight framework IMO was built for control authors.
But, it's a case by case basis.
Luarent
" I find multibinding useful sometimes when i need reference to more than onw UI element"
Every time you say something like that - a WPF architect is spinning in his office chair and we harness him/her for electricity.
If you need to reference more than one UI element in a binding - that's some seriously messed up logic you're introducing into your XAML.
That's the point when you look back for a second and realize that what you need isn't a bigger hammer but a screwdriver.
If 2+ UI Controls impact another UI control --> UI Logic. But this in your VM and be done with it. No need for fancy XAML tricks.
Karl
"I use MultiBinding on my FormNotification control."
Right, Control authors can't really use ViewModels like god intended.
Unless you expose a FooControl.FooViewModel property and TemplateBind to it, which just feels too Java Swing to me.
So - for you and other control authors - I absolve you from perdition for using MultiBinding.
Though, honestly, merging error messages has the element of sorting, which is getting pretty close to serious UI logic.
Maybe you should consider alternatives.
Mike + Eric
I almost buy the String.Format excuse. Almost.
But it's pure and simple UI logic.
1. You shouldn't hardcode strings in XAML In a globalized app - ever.
}
}
But whatever that thing is - it should do whatever multibindings do for you. i.e. UI Logic.
-- Justin
(Making friends wherever I go :))
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Bill Kempf
Sent: Monday, May 04, 2009 4:48 AM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: MultiBinding == Worst Practice?
I agree with a lot of what you say, but there were two things that stood out. The first was "This would mean that the ViewModel knows a *lot* about how it is displayed. Some people like this level of coupling between the V and VM." I actually adhere to this viewpoint. The VM is just that... a model of the view. As such, it's very tightly coupled to the view. That doesn't mean I want to go out of my way to make the coupling tighter (for instance, for UI specific stuff I prefer to use behaviors, converters and attached properties when possible), but I'm not going to have ANY heartburn over adding state to the VM to provide richer state for the View.
Next, "The WPF MVVM Toolkit worries me, because we now have a Microsoft(R) Offical(TM) Way To Architect Your App(TM)." That doesn't really worry me that much (though I've not yet had the chance to look at the toolkit). Good developers now there's more than one way. Bad developers aren't really any worse off, unless the "One Way" is generally bad. If you believe otherwise, than MS sh
ould give up now, because no matter what they do, they'll be "enabling bad developers".
On Sun, May 3, 2009 at 11:44 PM, Paul Stovell <sto...@gmail.com<mailto:sto...@gmail.com>> wrote:
Hi Justin,
I think multi bindings have their place. And I also think the suggestion that they can be replaced with MVVM is just one of the many interpretations of "MVVM" that abound.
For example, I once built a scheduling view that showed timesheet entries for a person over the course of a week. So I had an object like this:
class Entry
{
DateTime Start { get; set; }
DateTime End { get; set; }
}
I was displaying them in a <Grid/>, so my plan was to convert the Start into a Grid.Row and the difference into a Grid.RowSpan. My ViewModel contained an offset date (e.g., first day of the month), which I'd use to figure out what the starting row should be.
In one interpretation of MVVM, I could have wrapped every entry and done the calculations in code. This would mean that the ViewModel knows a *lot* about how it is displayed. Some people like this level of coupling between the V and VM.
Personally, I'd like the "VM" to represent the state of the view, without being tightly coupled to how the view actually views things. So I did this:
<Grid.Row>
<MultiBinding Converter="{...}">
<Binding Path="Start" />
<Binding RelativeSource.... Path="Offset" />
Here, the MultiBinding did the offset. This allowed my VM to represent the "state" of the view, and my view to figure out how to render stuff. I prefer this interpretation of MVVM, though some do not.
>> In our MVVM sensitive world frame, I'll go as far as suggesting that if you have more than a single data source for the same UIElement --> You're doing it wrong.
As an architect, if you say there's only one way to do something, you're doing it wrong :-) The WPF MVVM Toolkit worries me, because we now have a Microsoft(R) Offical(TM) Way To Architect Your App(TM). So all other interpretations of the pattern are out.
Paul
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Eric Burke
Sent: Monday, April 27, 2009 8:45 PM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: MultiBinding == Worst Practice?
MultiBinding is key to proper localization because different languages rearrange words. In English it might read "{0} does something to {1}" but in German it could be "{1} has something done to it by {0}". The translators may completely change the wording to make it clearer to the user, you never know.
You need a StringFormat because you can't do it all in XAML. For instance, if you had this:
<TextBlock>
<TextBlock Text="{Binding Value1}"/>
<Run Text=" does something to "/>
<TextBlock Text="{Binding Value2}"/>
</TextBlock>
not only is it impossible to translate properly (unless you wanted to stick it in a resource DLL, which gets tedious real fast), but the translators (who are often 3rd party people who know squat about programming) look at it and go, "Huh?!?!".
However, it is simple to teach them that {0}, {1}, {2} are words that get filled in later, and put comments as to what they represent in the code or in your translation system or whatever the translator actually sees, and tell them to please not change the {0}, {1}, {2} but feel free to move them around.
[Also, 3rd party translators get paid by the word, and the more times they kick things back to you incorrectly, the more it costs you. ;)]
________________________________
From: Mike Brown <mbro...@gmail.com>
To: wpf-di...@googlegroups.com
Sent: Monday, April 27, 2009 11:34:07 PM
Subject: [WPF Disciples] Re: MultiBinding == Worst Practice?
I don't think there's anything inherently wrong with Multi-binding...it's just difficult to come up with a real world usage for it. It's like Generics...I've seen a bunch of examples of generics that plain inheritance couldn't have handled. I doubt anyone would argue generics are useless. In the same regard, a few bad examples doesn't invalidate the utility of multi-binding.
Justin,
Karl
-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
To: wpf-di...@googlegroups.com
Hi,
Laurent
-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
To: WPF Disciples
http://www.codeproject.com/KB/WPF/WpfWinFormsBulletGraphs.aspx
Regards,
Colin E.
