True! I'd prefer to use an enum with that approach, but then writing data triggers against enum values is kinda funky cause you have to import the enum into XAML
I hate converters, I only really use the visibility ones. The people I work with will go out of their way to write really specific converters JUST so they don't have to "pollute" their viewmodel. So we have a library of these wacky converters with really long names. For me, I think its daft. A viewmodel is specifically there to sit between the model and the View to make binding easier! .. so I will have all sorts of stuff on that sucker. Its much easier to code, debug and maintain ... and it performs better.
nice approach and the view looks cleaner, that would be a good video, when muldidatatrigger is worth it, use cases and more tips in your style? i mean "the clever style"
Thanks! I'd almost always prefer using this view model approach instead of a multi data-trigger. A good use case for multi data-triggers is, of course, when you don't have a view model. An example of this would be custom components or styling, such as only applying a style to a list view item when it's not selected and being hovered.
Wouldn't it be cleaner to have a number to color converter? Also, is there any way to have a converter to return a tuple? If so, how do I write the xaml to know which tuple value to use?
That would work but I like to stay away from converters if I can. In this context, the ranges that classify the colors as good, medium, or bad could be considered domain logic. I consider converters to be part of the view layer. I like to keep domain logic at the view model layer or above, preferably in the model layer.
Probably! As for this demo, a single property that could return a good, medium, or bad enum would also work. However, sometimes I don't like working with enums in XAML.
agree, i would probably create a private method that returns a SolidColorBrush and a string, then use properties to transfer those values into xaml; long xaml is the worst nightmare if you forget about it for a week, and then will try to acknowledge it once again
@@burger_flipper code-beind is not forbidden in MVVM. It's forbidden to put business logic there, but I believe using it for complex visual behaviours is actually OK.
you can also use Switch Case and return something like -1, 0, 1 (or enum, or w/e)
saving you 2 properties to update
True! I'd prefer to use an enum with that approach, but then writing data triggers against enum values is kinda funky cause you have to import the enum into XAML
Clever. Bravo. 👏
I hate converters, I only really use the visibility ones. The people I work with will go out of their way to write really specific converters JUST so they don't have to "pollute" their viewmodel. So we have a library of these wacky converters with really long names. For me, I think its daft. A viewmodel is specifically there to sit between the model and the View to make binding easier! .. so I will have all sorts of stuff on that sucker. Its much easier to code, debug and maintain ... and it performs better.
Totally agree!! The worst is when you run into a converter that references and casts some sort of domain object or view model 😬
Thanks InstanceSean :)
nice approach and the view looks cleaner, that would be a good video, when muldidatatrigger is worth it, use cases and more tips in your style? i mean "the clever style"
Thanks! I'd almost always prefer using this view model approach instead of a multi data-trigger.
A good use case for multi data-triggers is, of course, when you don't have a view model. An example of this would be custom components or styling, such as only applying a style to a list view item when it's not selected and being hovered.
Wouldn't it be cleaner to have a number to color converter? Also, is there any way to have a converter to return a tuple? If so, how do I write the xaml to know which tuple value to use?
That would work but I like to stay away from converters if I can. In this context, the ranges that classify the colors as good, medium, or bad could be considered domain logic. I consider converters to be part of the view layer. I like to keep domain logic at the view model layer or above, preferably in the model layer.
@@SingletonSean Thanks for your speedy reply. Is the tuple converter possible?
Is there any way that we could just use one function which set the rate?
Probably! As for this demo, a single property that could return a good, medium, or bad enum would also work. However, sometimes I don't like working with enums in XAML.
An interesting library you can use is DXBinding. You can write C# code in XAML itself
Wouldn't it be actually better and cleaner to handle this stuff in code-behind?
agree, i would probably create a private method that returns a SolidColorBrush and a string, then use properties to transfer those values into xaml; long xaml is the worst nightmare if you forget about it for a week, and then will try to acknowledge it once again
@@hellfim this assumes you have a code behind file.
In this example it's using MVVM so code behind is absolutely forbidden
@@SirBenJamin_ no bro, i mean in the viewmodel file
@@burger_flipper code-beind is not forbidden in MVVM. It's forbidden to put business logic there, but I believe using it for complex visual behaviours is actually OK.