views:

91

answers:

2

I'm a bit confused as to what a viewmodel's role is beyond databinding. I have a menu built in silverlight. The menu has x number of menu items which is determined at runtime. One of the features I would like to add to this is that each menuitem has a different text colour when hovered over.

Is it the role of the view to have a colour selector method or should the view handle this in it's code behind?

+4  A: 

Normally I would keep the coloring/styling in XAML if possible - My view of the ViewModel is that it is responsible for providing all the data (ie. not graphical stuff) from the Model in a manner the View can consume.

If it was complex logic that determined the color and it was to be reused - I might be tempted to put it in the ViewModel tho.

Goblin
I would try to determine what abstract state each color is meant to represent and have the VM execute the logic to generate states, which could then be rendered by triggers or a ValueConverter into colors (which should be in the XAML). A stoplight doesn't display Red/Yellow/Green, it displays Stop/Warning/Go. If it were a more complex color (brightness conveying value?) I'd prefer a parameterized ValueConverter, as that keeps the display logic in the View, even if it's not in the XAML.
Dan Bryant
I am completely with Dan Bryant here.
Andrei Rinea
+1  A: 

The view model is used by the data binding process as a "safe" way to allow you to sort/filter/group the records as seen by a specific control without (necessarily) making changes to the actual bound data set (that is, unless/until you tell it to). (FMI read Bea's article here.)

I agree with Goblin here, in that the presentation aspects like color might be best kept separate in the XAML, for example in the DataTemplate used by that control.

ewall
Two great answers, green tick for links!
DeanMc