I always said that I like my views to be like a stereotypical cheerleader: dumb and pretty. Note I said "stereotypical" I know that not all cheerleaders are dumb or even pretty for that matter. The same can be said for UI.
On Mon, Dec 1, 2008 at 3:55 PM, Josh Smith <flappleja...@gmail.com> wrote: > Great feedback, Laurent. Looking forward to your upcoming blog post about > your experience with taking other approaches. ;)
> I sense that I'm the odd man out in this discussion. I'm very curious to > know what concrete advantages others have gained by treating the VM as > something clearly distinct and separate from the View. What do you really > gain from using value converters and code-behind logic, as opposed to > putting that stuff into the VM? I'm not opposed to that approach, it's just > not how I've done MVVM so far. While working on Crack.NET I created very > dumb, passive Views and smart, demanding ViewModels. I know that the good > Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love > to hear his thoughts on this.
> josh
> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] > <laur...@galasoft.ch> wrote:
>> I want to chime in on that one.
>> Yes, patterns are guidelines more than rules. I followed that discussion >> with very much interest and can't wait to try some of that in my next app, >> and it's really interesting to see the different streams of thoughts. So far >> I think I see two major variations in the exposed practices, one which >> considers that VM is a kind of replacement for code-behind (let's call it a >> top-down approach) and thus a VM is very tightly bound to a View. The other >> is rather a bottom-up approach and puts the VM as an extension of the model, >> but formatted for the View.
>> In the project I worked last, we took a very pragmatic approach, and used >> VM for various reasons, the most important being avoiding that our designers >> have to write any code. Josh's point is really valid, designers should not >> have to worry about code, period. It's not their job. My role as an >> integrator (IM calls that "Interactive Developer") was to specifically avoid >> designers to have that kind of problems. This results in a series of >> roundtrips between developers and designers coordinated by the integrator. >> In that sense, a well thought VM can avoid a number of roundtrips. To me, >> this is the most important aspect of the VM, because every roundtrip costs a >> lot of money, and designers are damn expensive in a project.
>> When I say we were pragmatic, I mean that because some in the team were >> quite unexperienced, we ended up having quite some code in the code-behind. >> If I had to do it again today, I would probably be stricter about that. But >> on the other hand, I saw another team take a much stricter approach (Josh: >> That was Linus' team, you probably remember him from our memorable dinner in >> NY) and they spent a lot more time on some details than we did. Also, some >> of the development was done in India, and their strict approach cost quite a >> lot of time round tripping between India and Switzerland, or worse, having >> to refactor much of the code that the Indian team delivered.
>> Anyway… my next project should be a much smaller one (Silverlight), and I >> want to apply MVVM in a stricter way there. That should be interesting J
>> *From:* wpf-disciples@googlegroups.com [mailto: >> wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith >> *Sent:* Monday, December 01, 2008 9:03 PM >> *To:* wpf-disciples@googlegroups.com >> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >> for ValueConverters
>> Suppose you're working in the designer-developer workflow. Should the >> designers have to write the value converters? What if they don't know how >> to write some of them? I think it's easier to have the VM expose the >> properties that they need to bind against, instead of having the designers >> ask the developers to write a bunch of one-off converters for them.
>> At the end of the day, MVVM (like any other pattern) is a set of >> guidelines, not rules. So, as long as using the pattern makes your >> application better, development easier, and testing more thorough, it's all >> good.
>> Josh
>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli <corradocava...@gmail.com> >> wrote:
>> I'm with Marlon on this, while I agree that the VM can eliminate all >> converters I don't like the idea of having a ViewModel too tied to the view >> and, after all, converters are very reusable J.
>> Just had a look at Silverlight validation model, think there's a lot of >> work to do to fit it in a M-V-VM environment…
>> -Corrado
>> *From:* wpf-disciples@googlegroups.com [mailto: >> wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech >> *Sent:* lunedì 1 dicembre 2008 20:16
>> *To:* wpf-disciples@googlegroups.com >> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >> for ValueConverters
>> I also think that this should be 50% 50%... If there is something strongly >> UI coupled then I would probably put it in a ValueConverter...
>> yet I must say I hate those creatures so called IValueConverters :/
>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> >> wrote:
>> A ViewModel is basically a value converter on steroids. I takes "raw" >> data and converts it into something presentation-friendly, and vice-versa. >> If you ever find yourself binding an element's property to a ViewModel's >> property, and you're using a value converter, stop! Why not just create a >> property on the ViewModel that exposes the "formatted" data, and then drop >> the value converter altogether?
>> The only place I can see a use for value converters in an MVVM >> architecture is cross-element bindings. If I'm binding the Visibility of a >> panel to the IsChecked of a CheckBox, then I will need to use the >> BooleanToVisibilityConverter. But, perhaps even in that case I should take >> the "high road" and bind the IsChecked to a property on the ViewModel, and >> then have a SomePanelVisibility property on the VM, to which the Panel is >> bound.
I think that in the series that Dan Crevier wrote, he definitely viewed the ViewModel as a "Model of the View". The domain model itself is where the logic of your application belongs. The ViewModel to me should indeed be just that.
On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP]
<laur...@galasoft.ch> wrote: > I want to chime in on that one.
> Yes, patterns are guidelines more than rules. I followed that discussion > with very much interest and can't wait to try some of that in my next app, > and it's really interesting to see the different streams of thoughts. So far > I think I see two major variations in the exposed practices, one which > considers that VM is a kind of replacement for code-behind (let's call it a > top-down approach) and thus a VM is very tightly bound to a View. The other > is rather a bottom-up approach and puts the VM as an extension of the model, > but formatted for the View.
> In the project I worked last, we took a very pragmatic approach, and used > VM for various reasons, the most important being avoiding that our designers > have to write any code. Josh's point is really valid, designers should not > have to worry about code, period. It's not their job. My role as an > integrator (IM calls that "Interactive Developer") was to specifically avoid > designers to have that kind of problems. This results in a series of > roundtrips between developers and designers coordinated by the integrator. > In that sense, a well thought VM can avoid a number of roundtrips. To me, > this is the most important aspect of the VM, because every roundtrip costs a > lot of money, and designers are damn expensive in a project.
> When I say we were pragmatic, I mean that because some in the team were > quite unexperienced, we ended up having quite some code in the code-behind. > If I had to do it again today, I would probably be stricter about that. But > on the other hand, I saw another team take a much stricter approach (Josh: > That was Linus' team, you probably remember him from our memorable dinner in > NY) and they spent a lot more time on some details than we did. Also, some > of the development was done in India, and their strict approach cost quite a > lot of time round tripping between India and Switzerland, or worse, having > to refactor much of the code that the Indian team delivered.
> Anyway… my next project should be a much smaller one (Silverlight), and I > want to apply MVVM in a stricter way there. That should be interesting J
> *From:* wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith > *Sent:* Monday, December 01, 2008 9:03 PM > *To:* wpf-disciples@googlegroups.com > *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > for ValueConverters
> Suppose you're working in the designer-developer workflow. Should the > designers have to write the value converters? What if they don't know how > to write some of them? I think it's easier to have the VM expose the > properties that they need to bind against, instead of having the designers > ask the developers to write a bunch of one-off converters for them.
> At the end of the day, MVVM (like any other pattern) is a set of > guidelines, not rules. So, as long as using the pattern makes your > application better, development easier, and testing more thorough, it's all > good.
> Josh
> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli <corradocava...@gmail.com> > wrote:
> I'm with Marlon on this, while I agree that the VM can eliminate all > converters I don't like the idea of having a ViewModel too tied to the view > and, after all, converters are very reusable J.
> Just had a look at Silverlight validation model, think there's a lot of > work to do to fit it in a M-V-VM environment…
> -Corrado
> *From:* wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech > *Sent:* lunedì 1 dicembre 2008 20:16
> *To:* wpf-disciples@googlegroups.com > *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > for ValueConverters
> I also think that this should be 50% 50%... If there is something strongly > UI coupled then I would probably put it in a ValueConverter...
> yet I must say I hate those creatures so called IValueConverters :/
> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> > wrote:
> A ViewModel is basically a value converter on steroids. I takes "raw" data > and converts it into something presentation-friendly, and vice-versa. If > you ever find yourself binding an element's property to a ViewModel's > property, and you're using a value converter, stop! Why not just create a > property on the ViewModel that exposes the "formatted" data, and then drop > the value converter altogether?
> The only place I can see a use for value converters in an MVVM architecture > is cross-element bindings. If I'm binding the Visibility of a panel to the > IsChecked of a CheckBox, then I will need to use the > BooleanToVisibilityConverter. But, perhaps even in that case I should take > the "high road" and bind the IsChecked to a property on the ViewModel, and > then have a SomePanelVisibility property on the VM, to which the Panel is > bound.
I agree with you on that, Mike. Code-behind is where you handle events of controls in the View, and maybe update/call the VM in certain situations. VM is where you store view state, handle user interactions, and indirectly manipulate the UI elements. Model is for domain "stuff." That's my way of seeing it, these days.
On Mon, Dec 1, 2008 at 3:59 PM, Mike Brown <mbrow...@gmail.com> wrote: > I think that in the series that Dan Crevier wrote, he definitely viewed the > ViewModel as a "Model of the View". The domain model itself is where the > logic of your application belongs. The ViewModel to me should indeed be just > that.
> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] > <laur...@galasoft.ch> wrote:
>> I want to chime in on that one.
>> Yes, patterns are guidelines more than rules. I followed that discussion >> with very much interest and can't wait to try some of that in my next app, >> and it's really interesting to see the different streams of thoughts. So far >> I think I see two major variations in the exposed practices, one which >> considers that VM is a kind of replacement for code-behind (let's call it a >> top-down approach) and thus a VM is very tightly bound to a View. The other >> is rather a bottom-up approach and puts the VM as an extension of the model, >> but formatted for the View.
>> In the project I worked last, we took a very pragmatic approach, and used >> VM for various reasons, the most important being avoiding that our designers >> have to write any code. Josh's point is really valid, designers should not >> have to worry about code, period. It's not their job. My role as an >> integrator (IM calls that "Interactive Developer") was to specifically avoid >> designers to have that kind of problems. This results in a series of >> roundtrips between developers and designers coordinated by the integrator. >> In that sense, a well thought VM can avoid a number of roundtrips. To me, >> this is the most important aspect of the VM, because every roundtrip costs a >> lot of money, and designers are damn expensive in a project.
>> When I say we were pragmatic, I mean that because some in the team were >> quite unexperienced, we ended up having quite some code in the code-behind. >> If I had to do it again today, I would probably be stricter about that. But >> on the other hand, I saw another team take a much stricter approach (Josh: >> That was Linus' team, you probably remember him from our memorable dinner in >> NY) and they spent a lot more time on some details than we did. Also, some >> of the development was done in India, and their strict approach cost quite a >> lot of time round tripping between India and Switzerland, or worse, having >> to refactor much of the code that the Indian team delivered.
>> Anyway… my next project should be a much smaller one (Silverlight), and I >> want to apply MVVM in a stricter way there. That should be interesting J
>> *From:* wpf-disciples@googlegroups.com [mailto: >> wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith >> *Sent:* Monday, December 01, 2008 9:03 PM >> *To:* wpf-disciples@googlegroups.com >> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >> for ValueConverters
>> Suppose you're working in the designer-developer workflow. Should the >> designers have to write the value converters? What if they don't know how >> to write some of them? I think it's easier to have the VM expose the >> properties that they need to bind against, instead of having the designers >> ask the developers to write a bunch of one-off converters for them.
>> At the end of the day, MVVM (like any other pattern) is a set of >> guidelines, not rules. So, as long as using the pattern makes your >> application better, development easier, and testing more thorough, it's all >> good.
>> Josh
>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli <corradocava...@gmail.com> >> wrote:
>> I'm with Marlon on this, while I agree that the VM can eliminate all >> converters I don't like the idea of having a ViewModel too tied to the view >> and, after all, converters are very reusable J.
>> Just had a look at Silverlight validation model, think there's a lot of >> work to do to fit it in a M-V-VM environment…
>> -Corrado
>> *From:* wpf-disciples@googlegroups.com [mailto: >> wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech >> *Sent:* lunedì 1 dicembre 2008 20:16
>> *To:* wpf-disciples@googlegroups.com >> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >> for ValueConverters
>> I also think that this should be 50% 50%... If there is something strongly >> UI coupled then I would probably put it in a ValueConverter...
>> yet I must say I hate those creatures so called IValueConverters :/
>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> >> wrote:
>> A ViewModel is basically a value converter on steroids. I takes "raw" >> data and converts it into something presentation-friendly, and vice-versa. >> If you ever find yourself binding an element's property to a ViewModel's >> property, and you're using a value converter, stop! Why not just create a >> property on the ViewModel that exposes the "formatted" data, and then drop >> the value converter altogether?
>> The only place I can see a use for value converters in an MVVM >> architecture is cross-element bindings. If I'm binding the Visibility of a >> panel to the IsChecked of a CheckBox, then I will need to use the >> BooleanToVisibilityConverter. But, perhaps even in that case I should take >> the "high road" and bind the IsChecked to a property on the ViewModel, and >> then have a SomePanelVisibility property on the VM, to which the Panel is >> bound.
On Mon, Dec 1, 2008 at 4:07 PM, Josh Smith <flappleja...@gmail.com> wrote: > I agree with you on that, Mike. Code-behind is where you handle events of > controls in the View, and maybe update/call the VM in certain situations. > VM is where you store view state, handle user interactions, and indirectly > manipulate the UI elements. Model is for domain "stuff." That's my way of > seeing it, these days.
> Josh
> On Mon, Dec 1, 2008 at 3:59 PM, Mike Brown <mbrow...@gmail.com> wrote:
>> I think that in the series that Dan Crevier wrote, he definitely viewed >> the ViewModel as a "Model of the View". The domain model itself is where the >> logic of your application belongs. The ViewModel to me should indeed be just >> that.
>> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] >> <laur...@galasoft.ch> wrote:
>>> I want to chime in on that one.
>>> Yes, patterns are guidelines more than rules. I followed that discussion >>> with very much interest and can't wait to try some of that in my next app, >>> and it's really interesting to see the different streams of thoughts. So far >>> I think I see two major variations in the exposed practices, one which >>> considers that VM is a kind of replacement for code-behind (let's call it a >>> top-down approach) and thus a VM is very tightly bound to a View. The other >>> is rather a bottom-up approach and puts the VM as an extension of the model, >>> but formatted for the View.
>>> In the project I worked last, we took a very pragmatic approach, and used >>> VM for various reasons, the most important being avoiding that our designers >>> have to write any code. Josh's point is really valid, designers should not >>> have to worry about code, period. It's not their job. My role as an >>> integrator (IM calls that "Interactive Developer") was to specifically avoid >>> designers to have that kind of problems. This results in a series of >>> roundtrips between developers and designers coordinated by the integrator. >>> In that sense, a well thought VM can avoid a number of roundtrips. To me, >>> this is the most important aspect of the VM, because every roundtrip costs a >>> lot of money, and designers are damn expensive in a project.
>>> When I say we were pragmatic, I mean that because some in the team were >>> quite unexperienced, we ended up having quite some code in the code-behind. >>> If I had to do it again today, I would probably be stricter about that. But >>> on the other hand, I saw another team take a much stricter approach (Josh: >>> That was Linus' team, you probably remember him from our memorable dinner in >>> NY) and they spent a lot more time on some details than we did. Also, some >>> of the development was done in India, and their strict approach cost quite a >>> lot of time round tripping between India and Switzerland, or worse, having >>> to refactor much of the code that the Indian team delivered.
>>> Anyway… my next project should be a much smaller one (Silverlight), and I >>> want to apply MVVM in a stricter way there. That should be interesting J
>>> From: wpf-disciples@googlegroups.com >>> [mailto:wpf-disciples@googlegroups.com] On Behalf Of Josh Smith >>> Sent: Monday, December 01, 2008 9:03 PM
>>> To: wpf-disciples@googlegroups.com >>> Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need for >>> ValueConverters
>>> Suppose you're working in the designer-developer workflow. Should the >>> designers have to write the value converters? What if they don't know how >>> to write some of them? I think it's easier to have the VM expose the >>> properties that they need to bind against, instead of having the designers >>> ask the developers to write a bunch of one-off converters for them.
>>> At the end of the day, MVVM (like any other pattern) is a set of >>> guidelines, not rules. So, as long as using the pattern makes your >>> application better, development easier, and testing more thorough, it's all >>> good.
>>> Josh
>>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli >>> <corradocava...@gmail.com> wrote:
>>> I'm with Marlon on this, while I agree that the VM can eliminate all >>> converters I don't like the idea of having a ViewModel too tied to the view >>> and, after all, converters are very reusable J.
>>> Just had a look at Silverlight validation model, think there's a lot of >>> work to do to fit it in a M-V-VM environment…
>>> -Corrado
>>> From: wpf-disciples@googlegroups.com >>> [mailto:wpf-disciples@googlegroups.com] On Behalf Of Marlon Grech >>> Sent: lunedì 1 dicembre 2008 20:16
>>> To: wpf-disciples@googlegroups.com >>> Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need for >>> ValueConverters
>>> I also think that this should be 50% 50%... If there is something >>> strongly UI coupled then I would probably put it in a ValueConverter...
>>> yet I must say I hate those creatures so called IValueConverters :/
>>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> >>> wrote:
>>> A ViewModel is basically a value converter on steroids. I takes "raw" >>> data and converts it into something presentation-friendly, and vice-versa. >>> If you ever find yourself binding an element's property to a ViewModel's >>> property, and you're using a value converter, stop! Why not just create a >>> property on the ViewModel that exposes the "formatted" data, and then drop >>> the value converter altogether?
>>> The only place I can see a use for value converters in an MVVM >>> architecture is cross-element bindings. If I'm binding the Visibility of a >>> panel to the IsChecked of a CheckBox, then I will need to use the >>> BooleanToVisibilityConverter. But, perhaps even in that case I should take >>> the "high road" and bind the IsChecked to a property on the ViewModel, and >>> then have a SomePanelVisibility property on the VM, to which the Panel is >>> bound.
>>> Do you agree???
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
If there is a one-to-one relationship between a ViewModel and a View, I don't see why tight-coupling is a concern. If we're talking about "ModelViews" instead, as per my previous post, then I can see how the coupling issue becomes more important. Do you agree?
On Mon, Dec 1, 2008 at 4:09 PM, Bill Kempf <weke...@gmail.com> wrote:
> Again, though, just because your view is dumb doesn't mean your view > model should be doing "presentation work" that tightly couples it.
> On Mon, Dec 1, 2008 at 4:07 PM, Josh Smith <flappleja...@gmail.com> wrote: > > I agree with you on that, Mike. Code-behind is where you handle events > of > > controls in the View, and maybe update/call the VM in certain situations. > > VM is where you store view state, handle user interactions, and > indirectly > > manipulate the UI elements. Model is for domain "stuff." That's my way > of > > seeing it, these days.
> > Josh
> > On Mon, Dec 1, 2008 at 3:59 PM, Mike Brown <mbrow...@gmail.com> wrote:
> >> I think that in the series that Dan Crevier wrote, he definitely viewed > >> the ViewModel as a "Model of the View". The domain model itself is where > the > >> logic of your application belongs. The ViewModel to me should indeed be > just > >> that.
> >> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] > >> <laur...@galasoft.ch> wrote:
> >>> I want to chime in on that one.
> >>> Yes, patterns are guidelines more than rules. I followed that > discussion > >>> with very much interest and can't wait to try some of that in my next > app, > >>> and it's really interesting to see the different streams of thoughts. > So far > >>> I think I see two major variations in the exposed practices, one which > >>> considers that VM is a kind of replacement for code-behind (let's call > it a > >>> top-down approach) and thus a VM is very tightly bound to a View. The > other > >>> is rather a bottom-up approach and puts the VM as an extension of the > model, > >>> but formatted for the View.
> >>> In the project I worked last, we took a very pragmatic approach, and > used > >>> VM for various reasons, the most important being avoiding that our > designers > >>> have to write any code. Josh's point is really valid, designers should > not > >>> have to worry about code, period. It's not their job. My role as an > >>> integrator (IM calls that "Interactive Developer") was to specifically > avoid > >>> designers to have that kind of problems. This results in a series of > >>> roundtrips between developers and designers coordinated by the > integrator. > >>> In that sense, a well thought VM can avoid a number of roundtrips. To > me, > >>> this is the most important aspect of the VM, because every roundtrip > costs a > >>> lot of money, and designers are damn expensive in a project.
> >>> When I say we were pragmatic, I mean that because some in the team were > >>> quite unexperienced, we ended up having quite some code in the > code-behind. > >>> If I had to do it again today, I would probably be stricter about that. > But > >>> on the other hand, I saw another team take a much stricter approach > (Josh: > >>> That was Linus' team, you probably remember him from our memorable > dinner in > >>> NY) and they spent a lot more time on some details than we did. Also, > some > >>> of the development was done in India, and their strict approach cost > quite a > >>> lot of time round tripping between India and Switzerland, or worse, > having > >>> to refactor much of the code that the Indian team delivered.
> >>> Anyway… my next project should be a much smaller one (Silverlight), and > I > >>> want to apply MVVM in a stricter way there. That should be interesting > J
> >>> From: wpf-disciples@googlegroups.com > >>> [mailto:wpf-disciples@googlegroups.com] On Behalf Of Josh Smith > >>> Sent: Monday, December 01, 2008 9:03 PM
> >>> To: wpf-disciples@googlegroups.com > >>> Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > for > >>> ValueConverters
> >>> Suppose you're working in the designer-developer workflow. Should the > >>> designers have to write the value converters? What if they don't know > how > >>> to write some of them? I think it's easier to have the VM expose the > >>> properties that they need to bind against, instead of having the > designers > >>> ask the developers to write a bunch of one-off converters for them.
> >>> At the end of the day, MVVM (like any other pattern) is a set of > >>> guidelines, not rules. So, as long as using the pattern makes your > >>> application better, development easier, and testing more thorough, it's > all > >>> good.
> >>> Josh
> >>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli > >>> <corradocava...@gmail.com> wrote:
> >>> I'm with Marlon on this, while I agree that the VM can eliminate all > >>> converters I don't like the idea of having a ViewModel too tied to the > view > >>> and, after all, converters are very reusable J.
> >>> Just had a look at Silverlight validation model, think there's a lot of > >>> work to do to fit it in a M-V-VM environment…
> >>> -Corrado
> >>> From: wpf-disciples@googlegroups.com > >>> [mailto:wpf-disciples@googlegroups.com] On Behalf Of Marlon Grech > >>> Sent: lunedì 1 dicembre 2008 20:16
> >>> To: wpf-disciples@googlegroups.com > >>> Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > for > >>> ValueConverters
> >>> I also think that this should be 50% 50%... If there is something > >>> strongly UI coupled then I would probably put it in a ValueConverter...
> >>> yet I must say I hate those creatures so called IValueConverters :/
> >>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> > >>> wrote:
> >>> A ViewModel is basically a value converter on steroids. I takes "raw" > >>> data and converts it into something presentation-friendly, and > vice-versa. > >>> If you ever find yourself binding an element's property to a > ViewModel's > >>> property, and you're using a value converter, stop! Why not just > create a > >>> property on the ViewModel that exposes the "formatted" data, and then > drop > >>> the value converter altogether?
> >>> The only place I can see a use for value converters in an MVVM > >>> architecture is cross-element bindings. If I'm binding the Visibility > of a > >>> panel to the IsChecked of a CheckBox, then I will need to use the > >>> BooleanToVisibilityConverter. But, perhaps even in that case I should > take > >>> the "high road" and bind the IsChecked to a property on the ViewModel, > and > >>> then have a SomePanelVisibility property on the VM, to which the Panel > is > >>> bound.
> >>> Do you agree???
> -- > Quidquid latine dictum sit, altum sonatur. > - Whatever is said in Latin sounds profound.
> War is peace. Freedom is slavery. Bugs are features.
Not really. Even if I'm only ever going to have one view, that view is likely to still be fluid in nature. What I mean by that is the design of the view will go through many iterations throughout the lifetime of the application, and tight coupling means changes to the view also require changes to the view model.
On Mon, Dec 1, 2008 at 4:11 PM, Josh Smith <flappleja...@gmail.com> wrote: > If there is a one-to-one relationship between a ViewModel and a View, I > don't see why tight-coupling is a concern. If we're talking about > "ModelViews" instead, as per my previous post, then I can see how the > coupling issue becomes more important. Do you agree?
> Josh
> On Mon, Dec 1, 2008 at 4:09 PM, Bill Kempf <weke...@gmail.com> wrote:
>> Again, though, just because your view is dumb doesn't mean your view >> model should be doing "presentation work" that tightly couples it.
>> On Mon, Dec 1, 2008 at 4:07 PM, Josh Smith <flappleja...@gmail.com> wrote: >> > I agree with you on that, Mike. Code-behind is where you handle events >> > of >> > controls in the View, and maybe update/call the VM in certain >> > situations. >> > VM is where you store view state, handle user interactions, and >> > indirectly >> > manipulate the UI elements. Model is for domain "stuff." That's my way >> > of >> > seeing it, these days.
>> > Josh
>> > On Mon, Dec 1, 2008 at 3:59 PM, Mike Brown <mbrow...@gmail.com> wrote:
>> >> I think that in the series that Dan Crevier wrote, he definitely viewed >> >> the ViewModel as a "Model of the View". The domain model itself is >> >> where the >> >> logic of your application belongs. The ViewModel to me should indeed be >> >> just >> >> that.
>> >> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] >> >> <laur...@galasoft.ch> wrote:
>> >>> I want to chime in on that one.
>> >>> Yes, patterns are guidelines more than rules. I followed that >> >>> discussion >> >>> with very much interest and can't wait to try some of that in my next >> >>> app, >> >>> and it's really interesting to see the different streams of thoughts. >> >>> So far >> >>> I think I see two major variations in the exposed practices, one which >> >>> considers that VM is a kind of replacement for code-behind (let's call >> >>> it a >> >>> top-down approach) and thus a VM is very tightly bound to a View. The >> >>> other >> >>> is rather a bottom-up approach and puts the VM as an extension of the >> >>> model, >> >>> but formatted for the View.
>> >>> In the project I worked last, we took a very pragmatic approach, and >> >>> used >> >>> VM for various reasons, the most important being avoiding that our >> >>> designers >> >>> have to write any code. Josh's point is really valid, designers should >> >>> not >> >>> have to worry about code, period. It's not their job. My role as an >> >>> integrator (IM calls that "Interactive Developer") was to specifically >> >>> avoid >> >>> designers to have that kind of problems. This results in a series of >> >>> roundtrips between developers and designers coordinated by the >> >>> integrator. >> >>> In that sense, a well thought VM can avoid a number of roundtrips. To >> >>> me, >> >>> this is the most important aspect of the VM, because every roundtrip >> >>> costs a >> >>> lot of money, and designers are damn expensive in a project.
>> >>> When I say we were pragmatic, I mean that because some in the team >> >>> were >> >>> quite unexperienced, we ended up having quite some code in the >> >>> code-behind. >> >>> If I had to do it again today, I would probably be stricter about >> >>> that. But >> >>> on the other hand, I saw another team take a much stricter approach >> >>> (Josh: >> >>> That was Linus' team, you probably remember him from our memorable >> >>> dinner in >> >>> NY) and they spent a lot more time on some details than we did. Also, >> >>> some >> >>> of the development was done in India, and their strict approach cost >> >>> quite a >> >>> lot of time round tripping between India and Switzerland, or worse, >> >>> having >> >>> to refactor much of the code that the Indian team delivered.
>> >>> Anyway… my next project should be a much smaller one (Silverlight), >> >>> and I >> >>> want to apply MVVM in a stricter way there. That should be interesting >> >>> J
>> >>> From: wpf-disciples@googlegroups.com >> >>> [mailto:wpf-disciples@googlegroups.com] On Behalf Of Josh Smith >> >>> Sent: Monday, December 01, 2008 9:03 PM
>> >>> To: wpf-disciples@googlegroups.com >> >>> Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >> >>> for >> >>> ValueConverters
>> >>> Suppose you're working in the designer-developer workflow. Should the >> >>> designers have to write the value converters? What if they don't know >> >>> how >> >>> to write some of them? I think it's easier to have the VM expose the >> >>> properties that they need to bind against, instead of having the >> >>> designers >> >>> ask the developers to write a bunch of one-off converters for them.
>> >>> At the end of the day, MVVM (like any other pattern) is a set of >> >>> guidelines, not rules. So, as long as using the pattern makes your >> >>> application better, development easier, and testing more thorough, >> >>> it's all >> >>> good.
>> >>> Josh
>> >>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli >> >>> <corradocava...@gmail.com> wrote:
>> >>> I'm with Marlon on this, while I agree that the VM can eliminate all >> >>> converters I don't like the idea of having a ViewModel too tied to >> >>> the view >> >>> and, after all, converters are very reusable J.
>> >>> Just had a look at Silverlight validation model, think there's a lot >> >>> of >> >>> work to do to fit it in a M-V-VM environment…
>> >>> -Corrado
>> >>> From: wpf-disciples@googlegroups.com >> >>> [mailto:wpf-disciples@googlegroups.com] On Behalf Of Marlon Grech >> >>> Sent: lunedì 1 dicembre 2008 20:16
>> >>> To: wpf-disciples@googlegroups.com >> >>> Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >> >>> for >> >>> ValueConverters
>> >>> I also think that this should be 50% 50%... If there is something >> >>> strongly UI coupled then I would probably put it in a >> >>> ValueConverter...
>> >>> yet I must say I hate those creatures so called IValueConverters :/
>> >>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> >> >>> wrote:
>> >>> A ViewModel is basically a value converter on steroids. I takes "raw" >> >>> data and converts it into something presentation-friendly, and >> >>> vice-versa. >> >>> If you ever find yourself binding an element's property to a >> >>> ViewModel's >> >>> property, and you're using a value converter, stop! Why not just >> >>> create a >> >>> property on the ViewModel that exposes the "formatted" data, and then >> >>> drop >> >>> the value converter altogether?
>> >>> The only place I can see a use for value converters in an MVVM >> >>> architecture is cross-element bindings. If I'm binding the Visibility >> >>> of a >> >>> panel to the IsChecked of a CheckBox, then I will need to use the >> >>> BooleanToVisibilityConverter. But, perhaps even in that case I should >> >>> take >> >>> the "high road" and bind the IsChecked to a property on the ViewModel, >> >>> and >> >>> then have a SomePanelVisibility property on the VM, to which the Panel >> >>> is >> >>> bound.
>> >>> Do you agree???
>> -- >> Quidquid latine dictum sit, altum sonatur. >> - Whatever is said in Latin sounds profound.
>> War is peace. Freedom is slavery. Bugs are features.
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
Josh,
From my point of view, converters become part of a common library i
can share among projects, at least most commons (e.g:
BooleanToVisibility for SL projects), of course I won't ask a designer
to write code, but normally i create a very dumb preview, then
designer kicks in and does the rest, this when designer is involved,
and believe me, not many customer have designers.
Let's say you have a IsAvailable property on VM that you want to use
both Visibility trigger and Enabled property, your approach is to add
an additional property of type Visibility and this "doubling" must be
done for every VM while i can avoid this using a converter.
About testing: why do i have to test "Visibility" issues? my VM should
tell me that an item IsAvailable then its the view responsability to
convert that info in visibility (today, tomorrow it might change, and
i don't want to modify my VM for the new UI needs)
-Corrado
On Dec 1, 9:02 pm, "Josh Smith" <flappleja...@gmail.com> wrote:
> Suppose you're working in the designer-developer workflow. Should the
> designers have to write the value converters? What if they don't know how
> to write some of them? I think it's easier to have the VM expose the
> properties that they need to bind against, instead of having the designers
> ask the developers to write a bunch of one-off converters for them.
> At the end of the day, MVVM (like any other pattern) is a set of guidelines,
> not rules. So, as long as using the pattern makes your application better,
> development easier, and testing more thorough, it's all good.
> Josh
> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli <corradocava...@gmail.com>wrote:
> > I'm with Marlon on this, while I agree that the VM can eliminate all
> > converters I don't like the idea of having a ViewModel too tied to the view
> > and, after all, converters are very reusable J.
> > Just had a look at Silverlight validation model, think there's a lot of
> > work to do to fit it in a M-V-VM environment…
> > -Corrado
> > *From:* wpf-disciples@googlegroups.com [mailto:
> > wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech
> > *Sent:* lunedì 1 dicembre 2008 20:16
> > *To:* wpf-disciples@googlegroups.com
> > *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need
> > for ValueConverters
> > I also think that this should be 50% 50%... If there is something strongly
> > UI coupled then I would probably put it in a ValueConverter...
> > yet I must say I hate those creatures so called IValueConverters :/
> > On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com>
> > wrote:
> > A ViewModel is basically a value converter on steroids. I takes "raw" data
> > and converts it into something presentation-friendly, and vice-versa. If
> > you ever find yourself binding an element's property to a ViewModel's
> > property, and you're using a value converter, stop! Why not just create a
> > property on the ViewModel that exposes the "formatted" data, and then drop
> > the value converter altogether?
> > The only place I can see a use for value converters in an MVVM architecture
> > is cross-element bindings. If I'm binding the Visibility of a panel to the
> > IsChecked of a CheckBox, then I will need to use the
> > BooleanToVisibilityConverter. But, perhaps even in that case I should take
> > the "high road" and bind the IsChecked to a property on the ViewModel, and
> > then have a SomePanelVisibility property on the VM, to which the Panel is
> > bound.
Thanks Corrado. I get where you're coming from with this, but I'm still unsure of where the "boundary" is. One could take this reasoning and push it to the extreme by stating "Why bother with a ViewModel at all? Why not just bind directly to the Model and use Value Converters to handle all other transformations that need to be applied to make the Model show up in the UI correctly?"
Clearly, I know that nobody here is promoting that idea. The balance of power, so to speak, between ViewModel and View is a spectrum in which I lean toward the left and many others seem to lean more toward the right. I'm wondering what guiding principles one should use to find the sweet spot between the two opposing forces.
On Mon, Dec 1, 2008 at 4:32 PM, <corradocava...@gmail.com> wrote:
> Josh, > From my point of view, converters become part of a common library i > can share among projects, at least most commons (e.g: > BooleanToVisibility for SL projects), of course I won't ask a designer > to write code, but normally i create a very dumb preview, then > designer kicks in and does the rest, this when designer is involved, > and believe me, not many customer have designers. > Let's say you have a IsAvailable property on VM that you want to use > both Visibility trigger and Enabled property, your approach is to add > an additional property of type Visibility and this "doubling" must be > done for every VM while i can avoid this using a converter. > About testing: why do i have to test "Visibility" issues? my VM should > tell me that an item IsAvailable then its the view responsability to > convert that info in visibility (today, tomorrow it might change, and > i don't want to modify my VM for the new UI needs)
> -Corrado
> On Dec 1, 9:02 pm, "Josh Smith" <flappleja...@gmail.com> wrote: > > Suppose you're working in the designer-developer workflow. Should the > > designers have to write the value converters? What if they don't know > how > > to write some of them? I think it's easier to have the VM expose the > > properties that they need to bind against, instead of having the > designers > > ask the developers to write a bunch of one-off converters for them.
> > At the end of the day, MVVM (like any other pattern) is a set of > guidelines, > > not rules. So, as long as using the pattern makes your application > better, > > development easier, and testing more thorough, it's all good.
> > Josh
> > On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli < > corradocava...@gmail.com>wrote:
> > > I'm with Marlon on this, while I agree that the VM can eliminate all > > > converters I don't like the idea of having a ViewModel too tied to the > view > > > and, after all, converters are very reusable J.
> > > Just had a look at Silverlight validation model, think there's a lot of > > > work to do to fit it in a M-V-VM environment…
> > > -Corrado
> > > *From:* wpf-disciples@googlegroups.com [mailto: > > > wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech > > > *Sent:* lunedì 1 dicembre 2008 20:16 > > > *To:* wpf-disciples@googlegroups.com > > > *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > > > for ValueConverters
> > > I also think that this should be 50% 50%... If there is something > strongly > > > UI coupled then I would probably put it in a ValueConverter...
> > > yet I must say I hate those creatures so called IValueConverters :/
> > > On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> > > > wrote:
> > > A ViewModel is basically a value converter on steroids. I takes "raw" > data > > > and converts it into something presentation-friendly, and vice-versa. > If > > > you ever find yourself binding an element's property to a ViewModel's > > > property, and you're using a value converter, stop! Why not just > create a > > > property on the ViewModel that exposes the "formatted" data, and then > drop > > > the value converter altogether?
> > > The only place I can see a use for value converters in an MVVM > architecture > > > is cross-element bindings. If I'm binding the Visibility of a panel to > the > > > IsChecked of a CheckBox, then I will need to use the > > > BooleanToVisibilityConverter. But, perhaps even in that case I should > take > > > the "high road" and bind the IsChecked to a property on the ViewModel, > and > > > then have a SomePanelVisibility property on the VM, to which the Panel > is > > > bound.
Crack.NET has been one of my bases of learning MVVM. I think the typed datatemplate resources feel very natural and lets the View be as only intelligent as it needs to be. As you remember, this is where I was sorta getting pattern gun-shy in SL, given lack of built in support. At this moment, I'm a proponent of the ViewModel-data/type-driven View which you mentioned here. Before, in SL, I was initializing the VM in the codebehind and clearly it was more spaghettified if my goal was to *fly the whole plane *from the VM.
As far as ValueConverters go, I would say I'm guilty of having my VM pander the View a little bit. I would also add that I don't enjoy making VCs that much...but just like home-owners-associations, they are a necessary evil. Most cases I would assume it's fine to have View friendly properties...but when you start getting over run by redundant properties (in other formats) is when I may consider a VC.
Just my 2cents as a newbie ;). It does feel good to be able to follow these conversations now though...
On Mon, Dec 1, 2008 at 12:55 PM, Josh Smith <flappleja...@gmail.com> wrote: > Great feedback, Laurent. Looking forward to your upcoming blog post about > your experience with taking other approaches. ;)
> I sense that I'm the odd man out in this discussion. I'm very curious to > know what concrete advantages others have gained by treating the VM as > something clearly distinct and separate from the View. What do you really > gain from using value converters and code-behind logic, as opposed to > putting that stuff into the VM? I'm not opposed to that approach, it's just > not how I've done MVVM so far. While working on Crack.NET I created very > dumb, passive Views and smart, demanding ViewModels. I know that the good > Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love > to hear his thoughts on this.
> josh
> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] > <laur...@galasoft.ch> wrote:
>> I want to chime in on that one.
>> Yes, patterns are guidelines more than rules. I followed that discussion >> with very much interest and can't wait to try some of that in my next app, >> and it's really interesting to see the different streams of thoughts. So far >> I think I see two major variations in the exposed practices, one which >> considers that VM is a kind of replacement for code-behind (let's call it a >> top-down approach) and thus a VM is very tightly bound to a View. The other >> is rather a bottom-up approach and puts the VM as an extension of the model, >> but formatted for the View.
>> In the project I worked last, we took a very pragmatic approach, and used >> VM for various reasons, the most important being avoiding that our designers >> have to write any code. Josh's point is really valid, designers should not >> have to worry about code, period. It's not their job. My role as an >> integrator (IM calls that "Interactive Developer") was to specifically avoid >> designers to have that kind of problems. This results in a series of >> roundtrips between developers and designers coordinated by the integrator. >> In that sense, a well thought VM can avoid a number of roundtrips. To me, >> this is the most important aspect of the VM, because every roundtrip costs a >> lot of money, and designers are damn expensive in a project.
>> When I say we were pragmatic, I mean that because some in the team were >> quite unexperienced, we ended up having quite some code in the code-behind. >> If I had to do it again today, I would probably be stricter about that. But >> on the other hand, I saw another team take a much stricter approach (Josh: >> That was Linus' team, you probably remember him from our memorable dinner in >> NY) and they spent a lot more time on some details than we did. Also, some >> of the development was done in India, and their strict approach cost quite a >> lot of time round tripping between India and Switzerland, or worse, having >> to refactor much of the code that the Indian team delivered.
>> Anyway… my next project should be a much smaller one (Silverlight), and I >> want to apply MVVM in a stricter way there. That should be interesting J
>> *From:* wpf-disciples@googlegroups.com [mailto: >> wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith >> *Sent:* Monday, December 01, 2008 9:03 PM >> *To:* wpf-disciples@googlegroups.com >> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >> for ValueConverters
>> Suppose you're working in the designer-developer workflow. Should the >> designers have to write the value converters? What if they don't know how >> to write some of them? I think it's easier to have the VM expose the >> properties that they need to bind against, instead of having the designers >> ask the developers to write a bunch of one-off converters for them.
>> At the end of the day, MVVM (like any other pattern) is a set of >> guidelines, not rules. So, as long as using the pattern makes your >> application better, development easier, and testing more thorough, it's all >> good.
>> Josh
>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli <corradocava...@gmail.com> >> wrote:
>> I'm with Marlon on this, while I agree that the VM can eliminate all >> converters I don't like the idea of having a ViewModel too tied to the view >> and, after all, converters are very reusable J.
>> Just had a look at Silverlight validation model, think there's a lot of >> work to do to fit it in a M-V-VM environment…
>> -Corrado
>> *From:* wpf-disciples@googlegroups.com [mailto: >> wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech >> *Sent:* lunedì 1 dicembre 2008 20:16
>> *To:* wpf-disciples@googlegroups.com >> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >> for ValueConverters
>> I also think that this should be 50% 50%... If there is something strongly >> UI coupled then I would probably put it in a ValueConverter...
>> yet I must say I hate those creatures so called IValueConverters :/
>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> >> wrote:
>> A ViewModel is basically a value converter on steroids. I takes "raw" >> data and converts it into something presentation-friendly, and vice-versa. >> If you ever find yourself binding an element's property to a ViewModel's >> property, and you're using a value converter, stop! Why not just create a >> property on the ViewModel that exposes the "formatted" data, and then drop >> the value converter altogether?
>> The only place I can see a use for value converters in an MVVM >> architecture is cross-element bindings. If I'm binding the Visibility of a >> panel to the IsChecked of a CheckBox, then I will need to use the >> BooleanToVisibilityConverter. But, perhaps even in that case I should take >> the "high road" and bind the IsChecked to a property on the ViewModel, and >> then have a SomePanelVisibility property on the VM, to which the Panel is >> bound.
I love this kind of discussions they helps spreading opinions and helps me (and hope others) play better with this “quite young” but promising pattern.
I’m not absolutely saying your solution is bad, e.g. I use it when I need to enable an element as result of a complex condition (DataTrigger/Multibinding? No thanks! J) and, my point of view is that patterns are ‘indications’ and I feel free to adapt them in the way the best fits my solution.
Unfortunately I keep seeing architects that apply patterns “as-is” even if that results in more complex code.
-Corrado
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Josh Smith Sent: lunedì 1 dicembre 2008 22:41 To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need for ValueConverters
Thanks Corrado. I get where you're coming from with this, but I'm still unsure of where the "boundary" is. One could take this reasoning and push it to the extreme by stating "Why bother with a ViewModel at all? Why not just bind directly to the Model and use Value Converters to handle all other transformations that need to be applied to make the Model show up in the UI correctly?"
Clearly, I know that nobody here is promoting that idea. The balance of power, so to speak, between ViewModel and View is a spectrum in which I lean toward the left and many others seem to lean more toward the right. I'm wondering what guiding principles one should use to find the sweet spot between the two opposing forces.
Josh
On Mon, Dec 1, 2008 at 4:32 PM, <corradocava...@gmail.com> wrote:
Josh, From my point of view, converters become part of a common library i can share among projects, at least most commons (e.g: BooleanToVisibility for SL projects), of course I won't ask a designer to write code, but normally i create a very dumb preview, then designer kicks in and does the rest, this when designer is involved, and believe me, not many customer have designers. Let's say you have a IsAvailable property on VM that you want to use both Visibility trigger and Enabled property, your approach is to add an additional property of type Visibility and this "doubling" must be done for every VM while i can avoid this using a converter. About testing: why do i have to test "Visibility" issues? my VM should tell me that an item IsAvailable then its the view responsability to convert that info in visibility (today, tomorrow it might change, and i don't want to modify my VM for the new UI needs)
-Corrado
On Dec 1, 9:02 pm, "Josh Smith" <flappleja...@gmail.com> wrote:
> Suppose you're working in the designer-developer workflow. Should the > designers have to write the value converters? What if they don't know how > to write some of them? I think it's easier to have the VM expose the > properties that they need to bind against, instead of having the designers > ask the developers to write a bunch of one-off converters for them.
> At the end of the day, MVVM (like any other pattern) is a set of guidelines, > not rules. So, as long as using the pattern makes your application better, > development easier, and testing more thorough, it's all good.
> > I'm with Marlon on this, while I agree that the VM can eliminate all > > converters I don't like the idea of having a ViewModel too tied to the view > > and, after all, converters are very reusable J.
> > Just had a look at Silverlight validation model, think there's a lot of > > work to do to fit it in a M-V-VM environment…
> > -Corrado
> > *From:* wpf-disciples@googlegroups.com [mailto: > > wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech > > *Sent:* lunedì 1 dicembre 2008 20:16 > > *To:* wpf-disciples@googlegroups.com > > *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > > for ValueConverters
> > I also think that this should be 50% 50%... If there is something strongly > > UI coupled then I would probably put it in a ValueConverter...
> > yet I must say I hate those creatures so called IValueConverters :/
> > On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> > > wrote:
> > A ViewModel is basically a value converter on steroids. I takes "raw" data > > and converts it into something presentation-friendly, and vice-versa. If > > you ever find yourself binding an element's property to a ViewModel's > > property, and you're using a value converter, stop! Why not just create a > > property on the ViewModel that exposes the "formatted" data, and then drop > > the value converter altogether?
> > The only place I can see a use for value converters in an MVVM architecture > > is cross-element bindings. If I'm binding the Visibility of a panel to the > > IsChecked of a CheckBox, then I will need to use the > > BooleanToVisibilityConverter. But, perhaps even in that case I should take > > the "high road" and bind the IsChecked to a property on the ViewModel, and > > then have a SomePanelVisibility property on the VM, to which the Panel is > > bound.
Me too, Corrado. Having discussions like this really help open new horizons for me.
>> Unfortunately I keep seeing architects that apply patterns "as-is" even
if that results in more complex code.
I'd take complex code over complex XAML any day! As you pointed out, hanging a property off the VM which returns a complex calculated value is definitely easier to maintain than a fat chunk of XAML using MultiBindings and a MultiConverter.
Josh
On Mon, Dec 1, 2008 at 5:08 PM, Corrado Cavalli <corradocava...@gmail.com>wrote:
> I love this kind of discussions they helps spreading opinions and helps > me (and hope others) play better with this "quite young" but promising > pattern.
> I'm not absolutely saying your solution is bad, e.g. I use it when I need > to enable an element as result of a complex condition > (DataTrigger/Multibinding? No thanks! J) and, my point of view is that > patterns are 'indications' and I feel free to adapt them in the way the best > fits my solution.
> Unfortunately I keep seeing architects that apply patterns "as-is" even if > that results in more complex code.
> -Corrado
> *From:* wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith > *Sent:* lunedì 1 dicembre 2008 22:41 > *To:* wpf-disciples@googlegroups.com > *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > for ValueConverters
> Thanks Corrado. I get where you're coming from with this, but I'm still > unsure of where the "boundary" is. One could take this reasoning and push > it to the extreme by stating "Why bother with a ViewModel at all? Why not > just bind directly to the Model and use Value Converters to handle all other > transformations that need to be applied to make the Model show up in the UI > correctly?"
> Clearly, I know that nobody here is promoting that idea. The balance of > power, so to speak, between ViewModel and View is a spectrum in which I lean > toward the left and many others seem to lean more toward the right. I'm > wondering what guiding principles one should use to find the sweet spot > between the two opposing forces.
> Josh
> On Mon, Dec 1, 2008 at 4:32 PM, <corradocava...@gmail.com> wrote:
> Josh, > From my point of view, converters become part of a common library i > can share among projects, at least most commons (e.g: > BooleanToVisibility for SL projects), of course I won't ask a designer > to write code, but normally i create a very dumb preview, then > designer kicks in and does the rest, this when designer is involved, > and believe me, not many customer have designers. > Let's say you have a IsAvailable property on VM that you want to use > both Visibility trigger and Enabled property, your approach is to add > an additional property of type Visibility and this "doubling" must be > done for every VM while i can avoid this using a converter. > About testing: why do i have to test "Visibility" issues? my VM should > tell me that an item IsAvailable then its the view responsability to > convert that info in visibility (today, tomorrow it might change, and > i don't want to modify my VM for the new UI needs)
> -Corrado
> On Dec 1, 9:02 pm, "Josh Smith" <flappleja...@gmail.com> wrote: > > Suppose you're working in the designer-developer workflow. Should the > > designers have to write the value converters? What if they don't know > how > > to write some of them? I think it's easier to have the VM expose the > > properties that they need to bind against, instead of having the > designers > > ask the developers to write a bunch of one-off converters for them.
> > At the end of the day, MVVM (like any other pattern) is a set of > guidelines, > > not rules. So, as long as using the pattern makes your application > better, > > development easier, and testing more thorough, it's all good.
> > Josh
> > On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli < > corradocava...@gmail.com>wrote:
> > > I'm with Marlon on this, while I agree that the VM can eliminate all > > > converters I don't like the idea of having a ViewModel too tied to the > view > > > and, after all, converters are very reusable J.
> > > Just had a look at Silverlight validation model, think there's a lot of > > > work to do to fit it in a M-V-VM environment…
> > > -Corrado
> > > *From:* wpf-disciples@googlegroups.com [mailto: > > > wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech > > > *Sent:* lunedì 1 dicembre 2008 20:16 > > > *To:* wpf-disciples@googlegroups.com > > > *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > > > for ValueConverters
> > > I also think that this should be 50% 50%... If there is something > strongly > > > UI coupled then I would probably put it in a ValueConverter...
> > > yet I must say I hate those creatures so called IValueConverters :/
> > > On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com>
> > > wrote:
> > > A ViewModel is basically a value converter on steroids. I takes "raw" > data > > > and converts it into something presentation-friendly, and vice-versa. > If > > > you ever find yourself binding an element's property to a ViewModel's > > > property, and you're using a value converter, stop! Why not just > create a > > > property on the ViewModel that exposes the "formatted" data, and then > drop > > > the value converter altogether?
> > > The only place I can see a use for value converters in an MVVM > architecture > > > is cross-element bindings. If I'm binding the Visibility of a panel to > the > > > IsChecked of a CheckBox, then I will need to use the > > > BooleanToVisibilityConverter. But, perhaps even in that case I should > take > > > the "high road" and bind the IsChecked to a property on the ViewModel, > and > > > then have a SomePanelVisibility property on the VM, to which the Panel > is > > > bound.
> Crack.NET has been one of my bases of learning MVVM. I think the typed > datatemplate resources feel very natural and lets the View be as only > intelligent as it needs to be. As you remember, this is where I was sorta > getting pattern gun-shy in SL, given lack of built in support. At this > moment, I'm a proponent of the ViewModel-data/type-driven View which you > mentioned here. Before, in SL, I was initializing the VM in the codebehind > and clearly it was more spaghettified if my goal was to *fly the whole > plane *from the VM.
> As far as ValueConverters go, I would say I'm guilty of having my VM pander > the View a little bit. I would also add that I don't enjoy making VCs that > much...but just like home-owners-associations, they are a necessary evil. > Most cases I would assume it's fine to have View friendly properties...but > when you start getting over run by redundant properties (in other formats) > is when I may consider a VC.
> Just my 2cents as a newbie ;). It does feel good to be able to follow > these conversations now though...
> -Jer
> On Mon, Dec 1, 2008 at 12:55 PM, Josh Smith <flappleja...@gmail.com>wrote:
>> Great feedback, Laurent. Looking forward to your upcoming blog post about >> your experience with taking other approaches. ;)
>> I sense that I'm the odd man out in this discussion. I'm very curious to >> know what concrete advantages others have gained by treating the VM as >> something clearly distinct and separate from the View. What do you really >> gain from using value converters and code-behind logic, as opposed to >> putting that stuff into the VM? I'm not opposed to that approach, it's just >> not how I've done MVVM so far. While working on Crack.NET I created very >> dumb, passive Views and smart, demanding ViewModels. I know that the good >> Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love >> to hear his thoughts on this.
>> josh
>> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] >> <laur...@galasoft.ch> wrote:
>>> I want to chime in on that one.
>>> Yes, patterns are guidelines more than rules. I followed that discussion >>> with very much interest and can't wait to try some of that in my next app, >>> and it's really interesting to see the different streams of thoughts. So far >>> I think I see two major variations in the exposed practices, one which >>> considers that VM is a kind of replacement for code-behind (let's call it a >>> top-down approach) and thus a VM is very tightly bound to a View. The other >>> is rather a bottom-up approach and puts the VM as an extension of the model, >>> but formatted for the View.
>>> In the project I worked last, we took a very pragmatic approach, and used >>> VM for various reasons, the most important being avoiding that our designers >>> have to write any code. Josh's point is really valid, designers should not >>> have to worry about code, period. It's not their job. My role as an >>> integrator (IM calls that "Interactive Developer") was to specifically avoid >>> designers to have that kind of problems. This results in a series of >>> roundtrips between developers and designers coordinated by the integrator. >>> In that sense, a well thought VM can avoid a number of roundtrips. To me, >>> this is the most important aspect of the VM, because every roundtrip costs a >>> lot of money, and designers are damn expensive in a project.
>>> When I say we were pragmatic, I mean that because some in the team were >>> quite unexperienced, we ended up having quite some code in the code-behind. >>> If I had to do it again today, I would probably be stricter about that. But >>> on the other hand, I saw another team take a much stricter approach (Josh: >>> That was Linus' team, you probably remember him from our memorable dinner in >>> NY) and they spent a lot more time on some details than we did. Also, some >>> of the development was done in India, and their strict approach cost quite a >>> lot of time round tripping between India and Switzerland, or worse, having >>> to refactor much of the code that the Indian team delivered.
>>> Anyway… my next project should be a much smaller one (Silverlight), and I >>> want to apply MVVM in a stricter way there. That should be interesting J
>>> *From:* wpf-disciples@googlegroups.com [mailto: >>> wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith >>> *Sent:* Monday, December 01, 2008 9:03 PM >>> *To:* wpf-disciples@googlegroups.com >>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >>> for ValueConverters
>>> Suppose you're working in the designer-developer workflow. Should the >>> designers have to write the value converters? What if they don't know how >>> to write some of them? I think it's easier to have the VM expose the >>> properties that they need to bind against, instead of having the designers >>> ask the developers to write a bunch of one-off converters for them.
>>> At the end of the day, MVVM (like any other pattern) is a set of >>> guidelines, not rules. So, as long as using the pattern makes your >>> application better, development easier, and testing more thorough, it's all >>> good.
>>> Josh
>>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli < >>> corradocava...@gmail.com> wrote:
>>> I'm with Marlon on this, while I agree that the VM can eliminate all >>> converters I don't like the idea of having a ViewModel too tied to the view >>> and, after all, converters are very reusable J.
>>> Just had a look at Silverlight validation model, think there's a lot of >>> work to do to fit it in a M-V-VM environment…
>>> -Corrado
>>> *From:* wpf-disciples@googlegroups.com [mailto: >>> wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech >>> *Sent:* lunedì 1 dicembre 2008 20:16
>>> *To:* wpf-disciples@googlegroups.com >>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >>> for ValueConverters
>>> I also think that this should be 50% 50%... If there is something >>> strongly UI coupled then I would probably put it in a ValueConverter...
>>> yet I must say I hate those creatures so called IValueConverters :/
>>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> >>> wrote:
>>> A ViewModel is basically a value converter on steroids. I takes "raw" >>> data and converts it into something presentation-friendly, and vice-versa. >>> If you ever find yourself binding an element's property to a ViewModel's >>> property, and you're using a value converter, stop! Why not just create a >>> property on the ViewModel that exposes the "formatted" data, and then drop >>> the value converter altogether?
>>> The only place I can see a use for value converters in an MVVM >>> architecture is cross-element bindings. If I'm binding the Visibility of a >>> panel to the IsChecked of a CheckBox, then I will need to use the >>> BooleanToVisibilityConverter. But, perhaps even in that case I should take >>> the "high road" and bind the IsChecked to a property on the ViewModel, and >>> then have a SomePanelVisibility property on the VM, to which the Panel is >>> bound.
On Mon, Dec 1, 2008 at 2:13 PM, Josh Smith <flappleja...@gmail.com> wrote: > Jer,
> I'm glad Crack has had the fringe benefit of being educational! That's > great news for me!! :)
> Josh
> On Mon, Dec 1, 2008 at 5:02 PM, Jeremiah Morrill < > jeremiah.morr...@gmail.com> wrote:
>> Josh,
>> Crack.NET has been one of my bases of learning MVVM. I think the typed >> datatemplate resources feel very natural and lets the View be as only >> intelligent as it needs to be. As you remember, this is where I was sorta >> getting pattern gun-shy in SL, given lack of built in support. At this >> moment, I'm a proponent of the ViewModel-data/type-driven View which you >> mentioned here. Before, in SL, I was initializing the VM in the codebehind >> and clearly it was more spaghettified if my goal was to *fly the whole >> plane *from the VM.
>> As far as ValueConverters go, I would say I'm guilty of having my VM >> pander the View a little bit. I would also add that I don't enjoy making >> VCs that much...but just like home-owners-associations, they are a necessary >> evil. Most cases I would assume it's fine to have View friendly >> properties...but when you start getting over run by redundant properties (in >> other formats) is when I may consider a VC.
>> Just my 2cents as a newbie ;). It does feel good to be able to follow >> these conversations now though...
>> -Jer
>> On Mon, Dec 1, 2008 at 12:55 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>> Great feedback, Laurent. Looking forward to your upcoming blog post >>> about your experience with taking other approaches. ;)
>>> I sense that I'm the odd man out in this discussion. I'm very curious to >>> know what concrete advantages others have gained by treating the VM as >>> something clearly distinct and separate from the View. What do you really >>> gain from using value converters and code-behind logic, as opposed to >>> putting that stuff into the VM? I'm not opposed to that approach, it's just >>> not how I've done MVVM so far. While working on Crack.NET I created very >>> dumb, passive Views and smart, demanding ViewModels. I know that the good >>> Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love >>> to hear his thoughts on this.
>>> josh
>>> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] >>> <laur...@galasoft.ch> wrote:
>>>> I want to chime in on that one.
>>>> Yes, patterns are guidelines more than rules. I followed that discussion >>>> with very much interest and can't wait to try some of that in my next app, >>>> and it's really interesting to see the different streams of thoughts. So far >>>> I think I see two major variations in the exposed practices, one which >>>> considers that VM is a kind of replacement for code-behind (let's call it a >>>> top-down approach) and thus a VM is very tightly bound to a View. The other >>>> is rather a bottom-up approach and puts the VM as an extension of the model, >>>> but formatted for the View.
>>>> In the project I worked last, we took a very pragmatic approach, and >>>> used VM for various reasons, the most important being avoiding that our >>>> designers have to write any code. Josh's point is really valid, designers >>>> should not have to worry about code, period. It's not their job. My role as >>>> an integrator (IM calls that "Interactive Developer") was to specifically >>>> avoid designers to have that kind of problems. This results in a series of >>>> roundtrips between developers and designers coordinated by the integrator. >>>> In that sense, a well thought VM can avoid a number of roundtrips. To me, >>>> this is the most important aspect of the VM, because every roundtrip costs a >>>> lot of money, and designers are damn expensive in a project.
>>>> When I say we were pragmatic, I mean that because some in the team were >>>> quite unexperienced, we ended up having quite some code in the code-behind. >>>> If I had to do it again today, I would probably be stricter about that. But >>>> on the other hand, I saw another team take a much stricter approach (Josh: >>>> That was Linus' team, you probably remember him from our memorable dinner in >>>> NY) and they spent a lot more time on some details than we did. Also, some >>>> of the development was done in India, and their strict approach cost quite a >>>> lot of time round tripping between India and Switzerland, or worse, having >>>> to refactor much of the code that the Indian team delivered.
>>>> Anyway… my next project should be a much smaller one (Silverlight), and >>>> I want to apply MVVM in a stricter way there. That should be interesting >>>> J
>>>> *From:* wpf-disciples@googlegroups.com [mailto: >>>> wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith >>>> *Sent:* Monday, December 01, 2008 9:03 PM >>>> *To:* wpf-disciples@googlegroups.com >>>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >>>> for ValueConverters
>>>> Suppose you're working in the designer-developer workflow. Should the >>>> designers have to write the value converters? What if they don't know how >>>> to write some of them? I think it's easier to have the VM expose the >>>> properties that they need to bind against, instead of having the designers >>>> ask the developers to write a bunch of one-off converters for them.
>>>> At the end of the day, MVVM (like any other pattern) is a set of >>>> guidelines, not rules. So, as long as using the pattern makes your >>>> application better, development easier, and testing more thorough, it's all >>>> good.
>>>> Josh
>>>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli < >>>> corradocava...@gmail.com> wrote:
>>>> I'm with Marlon on this, while I agree that the VM can eliminate all >>>> converters I don't like the idea of having a ViewModel too tied to the view >>>> and, after all, converters are very reusable J.
>>>> Just had a look at Silverlight validation model, think there's a lot of >>>> work to do to fit it in a M-V-VM environment…
>>>> -Corrado
>>>> *From:* wpf-disciples@googlegroups.com [mailto: >>>> wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech >>>> *Sent:* lunedì 1 dicembre 2008 20:16
>>>> *To:* wpf-disciples@googlegroups.com >>>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >>>> for ValueConverters
>>>> I also think that this should be 50% 50%... If there is something >>>> strongly UI coupled then I would probably put it in a ValueConverter...
>>>> yet I must say I hate those creatures so called IValueConverters :/
>>>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> >>>> wrote:
>>>> A ViewModel is basically a value converter on steroids. I takes "raw" >>>> data and converts it into something presentation-friendly, and vice-versa. >>>> If you ever find yourself binding an element's property to a ViewModel's >>>> property, and you're using a value converter, stop! Why not just create a >>>> property on the ViewModel that exposes the "formatted" data, and then drop >>>> the value converter altogether?
>>>> The only place I can see a use for value converters in an MVVM >>>> architecture is cross-element bindings. If I'm binding the Visibility of a >>>> panel to the IsChecked of a CheckBox, then I will need to use the >>>> BooleanToVisibilityConverter. But, perhaps even in that case I should take >>>> the "high road" and bind the IsChecked to a property on the ViewModel, and >>>> then have a SomePanelVisibility property on the VM, to which the Panel is >>>> bound.
You know, thinking about what I wrote earlier, I think that the “sweet balance” really depends on a lot of factors.
- Does your project have designers or not?
- How experienced is your team?
- How much unit testing do you do (don’t laugh, I love unit tests but many managers hate it and don’t see the value of it, true story)
- What is your model made of and where does it come from?
- and of course personal preferences.
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Josh Smith Sent: Monday, December 01, 2008 10:41 PM To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need for ValueConverters
Thanks Corrado. I get where you're coming from with this, but I'm still unsure of where the "boundary" is. One could take this reasoning and push it to the extreme by stating "Why bother with a ViewModel at all? Why not just bind directly to the Model and use Value Converters to handle all other transformations that need to be applied to make the Model show up in the UI correctly?"
Clearly, I know that nobody here is promoting that idea. The balance of power, so to speak, between ViewModel and View is a spectrum in which I lean toward the left and many others seem to lean more toward the right. I'm wondering what guiding principles one should use to find the sweet spot between the two opposing forces.
Josh
On Mon, Dec 1, 2008 at 4:32 PM, <corradocava...@gmail.com> wrote:
Josh, From my point of view, converters become part of a common library i can share among projects, at least most commons (e.g: BooleanToVisibility for SL projects), of course I won't ask a designer to write code, but normally i create a very dumb preview, then designer kicks in and does the rest, this when designer is involved, and believe me, not many customer have designers. Let's say you have a IsAvailable property on VM that you want to use both Visibility trigger and Enabled property, your approach is to add an additional property of type Visibility and this "doubling" must be done for every VM while i can avoid this using a converter. About testing: why do i have to test "Visibility" issues? my VM should tell me that an item IsAvailable then its the view responsability to convert that info in visibility (today, tomorrow it might change, and i don't want to modify my VM for the new UI needs)
-Corrado
On Dec 1, 9:02 pm, "Josh Smith" <flappleja...@gmail.com> wrote:
> Suppose you're working in the designer-developer workflow. Should the > designers have to write the value converters? What if they don't know how > to write some of them? I think it's easier to have the VM expose the > properties that they need to bind against, instead of having the designers > ask the developers to write a bunch of one-off converters for them.
> At the end of the day, MVVM (like any other pattern) is a set of guidelines, > not rules. So, as long as using the pattern makes your application better, > development easier, and testing more thorough, it's all good.
> > I'm with Marlon on this, while I agree that the VM can eliminate all > > converters I don't like the idea of having a ViewModel too tied to the view > > and, after all, converters are very reusable J.
> > Just had a look at Silverlight validation model, think there's a lot of > > work to do to fit it in a M-V-VM environment…
> > -Corrado
> > *From:* wpf-disciples@googlegroups.com [mailto: > > wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech > > *Sent:* lunedì 1 dicembre 2008 20:16 > > *To:* wpf-disciples@googlegroups.com > > *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > > for ValueConverters
> > I also think that this should be 50% 50%... If there is something strongly > > UI coupled then I would probably put it in a ValueConverter...
> > yet I must say I hate those creatures so called IValueConverters :/
> > On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> > > wrote:
> > A ViewModel is basically a value converter on steroids. I takes "raw" data > > and converts it into something presentation-friendly, and vice-versa. If > > you ever find yourself binding an element's property to a ViewModel's > > property, and you're using a value converter, stop! Why not just create a > > property on the ViewModel that exposes the "formatted" data, and then drop > > the value converter altogether?
> > The only place I can see a use for value converters in an MVVM architecture > > is cross-element bindings. If I'm binding the Visibility of a panel to the > > IsChecked of a CheckBox, then I will need to use the > > BooleanToVisibilityConverter. But, perhaps even in that case I should take > > the "high road" and bind the IsChecked to a property on the ViewModel, and > > then have a SomePanelVisibility property on the VM, to which the Panel is > > bound.
One question, about creating a life cycle for a VM, is what mechanism would you use in SL to do this? I was hoping not to have to do anything with the VM in the code-behind as this would create too much coupling (for my liking).
On Mon, Dec 1, 2008 at 2:02 PM, Jeremiah Morrill <jeremiah.morr...@gmail.com
> Crack.NET has been one of my bases of learning MVVM. I think the typed > datatemplate resources feel very natural and lets the View be as only > intelligent as it needs to be. As you remember, this is where I was sorta > getting pattern gun-shy in SL, given lack of built in support. At this > moment, I'm a proponent of the ViewModel-data/type-driven View which you > mentioned here. Before, in SL, I was initializing the VM in the codebehind > and clearly it was more spaghettified if my goal was to *fly the whole > plane *from the VM.
> As far as ValueConverters go, I would say I'm guilty of having my VM pander > the View a little bit. I would also add that I don't enjoy making VCs that > much...but just like home-owners-associations, they are a necessary evil. > Most cases I would assume it's fine to have View friendly properties...but > when you start getting over run by redundant properties (in other formats) > is when I may consider a VC.
> Just my 2cents as a newbie ;). It does feel good to be able to follow > these conversations now though...
> -Jer
> On Mon, Dec 1, 2008 at 12:55 PM, Josh Smith <flappleja...@gmail.com>wrote:
>> Great feedback, Laurent. Looking forward to your upcoming blog post about >> your experience with taking other approaches. ;)
>> I sense that I'm the odd man out in this discussion. I'm very curious to >> know what concrete advantages others have gained by treating the VM as >> something clearly distinct and separate from the View. What do you really >> gain from using value converters and code-behind logic, as opposed to >> putting that stuff into the VM? I'm not opposed to that approach, it's just >> not how I've done MVVM so far. While working on Crack.NET I created very >> dumb, passive Views and smart, demanding ViewModels. I know that the good >> Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love >> to hear his thoughts on this.
>> josh
>> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] >> <laur...@galasoft.ch> wrote:
>>> I want to chime in on that one.
>>> Yes, patterns are guidelines more than rules. I followed that discussion >>> with very much interest and can't wait to try some of that in my next app, >>> and it's really interesting to see the different streams of thoughts. So far >>> I think I see two major variations in the exposed practices, one which >>> considers that VM is a kind of replacement for code-behind (let's call it a >>> top-down approach) and thus a VM is very tightly bound to a View. The other >>> is rather a bottom-up approach and puts the VM as an extension of the model, >>> but formatted for the View.
>>> In the project I worked last, we took a very pragmatic approach, and used >>> VM for various reasons, the most important being avoiding that our designers >>> have to write any code. Josh's point is really valid, designers should not >>> have to worry about code, period. It's not their job. My role as an >>> integrator (IM calls that "Interactive Developer") was to specifically avoid >>> designers to have that kind of problems. This results in a series of >>> roundtrips between developers and designers coordinated by the integrator. >>> In that sense, a well thought VM can avoid a number of roundtrips. To me, >>> this is the most important aspect of the VM, because every roundtrip costs a >>> lot of money, and designers are damn expensive in a project.
>>> When I say we were pragmatic, I mean that because some in the team were >>> quite unexperienced, we ended up having quite some code in the code-behind. >>> If I had to do it again today, I would probably be stricter about that. But >>> on the other hand, I saw another team take a much stricter approach (Josh: >>> That was Linus' team, you probably remember him from our memorable dinner in >>> NY) and they spent a lot more time on some details than we did. Also, some >>> of the development was done in India, and their strict approach cost quite a >>> lot of time round tripping between India and Switzerland, or worse, having >>> to refactor much of the code that the Indian team delivered.
>>> Anyway… my next project should be a much smaller one (Silverlight), and I >>> want to apply MVVM in a stricter way there. That should be interesting J
>>> *From:* wpf-disciples@googlegroups.com [mailto: >>> wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith >>> *Sent:* Monday, December 01, 2008 9:03 PM >>> *To:* wpf-disciples@googlegroups.com >>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >>> for ValueConverters
>>> Suppose you're working in the designer-developer workflow. Should the >>> designers have to write the value converters? What if they don't know how >>> to write some of them? I think it's easier to have the VM expose the >>> properties that they need to bind against, instead of having the designers >>> ask the developers to write a bunch of one-off converters for them.
>>> At the end of the day, MVVM (like any other pattern) is a set of >>> guidelines, not rules. So, as long as using the pattern makes your >>> application better, development easier, and testing more thorough, it's all >>> good.
>>> Josh
>>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli < >>> corradocava...@gmail.com> wrote:
>>> I'm with Marlon on this, while I agree that the VM can eliminate all >>> converters I don't like the idea of having a ViewModel too tied to the view >>> and, after all, converters are very reusable J.
>>> Just had a look at Silverlight validation model, think there's a lot of >>> work to do to fit it in a M-V-VM environment…
>>> -Corrado
>>> *From:* wpf-disciples@googlegroups.com [mailto: >>> wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech >>> *Sent:* lunedì 1 dicembre 2008 20:16
>>> *To:* wpf-disciples@googlegroups.com >>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >>> for ValueConverters
>>> I also think that this should be 50% 50%... If there is something >>> strongly UI coupled then I would probably put it in a ValueConverter...
>>> yet I must say I hate those creatures so called IValueConverters :/
>>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> >>> wrote:
>>> A ViewModel is basically a value converter on steroids. I takes "raw" >>> data and converts it into something presentation-friendly, and vice-versa. >>> If you ever find yourself binding an element's property to a ViewModel's >>> property, and you're using a value converter, stop! Why not just create a >>> property on the ViewModel that exposes the "formatted" data, and then drop >>> the value converter altogether?
>>> The only place I can see a use for value converters in an MVVM >>> architecture is cross-element bindings. If I'm binding the Visibility of a >>> panel to the IsChecked of a CheckBox, then I will need to use the >>> BooleanToVisibilityConverter. But, perhaps even in that case I should take >>> the "high road" and bind the IsChecked to a property on the ViewModel, and >>> then have a SomePanelVisibility property on the VM, to which the Panel is >>> bound.
> wrote: > Don't want to inflate your ego dude, but if code was porn, the Crack.NET > source would be illegal in all 50 states! Too hot!
> Many thanks though.
> -Jer
> On Mon, Dec 1, 2008 at 2:13 PM, Josh Smith <flappleja...@gmail.com> wrote:
>> Jer,
>> I'm glad Crack has had the fringe benefit of being educational! That's >> great news for me!! :)
>> Josh
>> On Mon, Dec 1, 2008 at 5:02 PM, Jeremiah Morrill < >> jeremiah.morr...@gmail.com> wrote:
>>> Josh,
>>> Crack.NET has been one of my bases of learning MVVM. I think the typed >>> datatemplate resources feel very natural and lets the View be as only >>> intelligent as it needs to be. As you remember, this is where I was sorta >>> getting pattern gun-shy in SL, given lack of built in support. At this >>> moment, I'm a proponent of the ViewModel-data/type-driven View which you >>> mentioned here. Before, in SL, I was initializing the VM in the codebehind >>> and clearly it was more spaghettified if my goal was to *fly the whole >>> plane *from the VM.
>>> As far as ValueConverters go, I would say I'm guilty of having my VM >>> pander the View a little bit. I would also add that I don't enjoy making >>> VCs that much...but just like home-owners-associations, they are a necessary >>> evil. Most cases I would assume it's fine to have View friendly >>> properties...but when you start getting over run by redundant properties (in >>> other formats) is when I may consider a VC.
>>> Just my 2cents as a newbie ;). It does feel good to be able to follow >>> these conversations now though...
>>> -Jer
>>> On Mon, Dec 1, 2008 at 12:55 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>> Great feedback, Laurent. Looking forward to your upcoming blog post >>>> about your experience with taking other approaches. ;)
>>>> I sense that I'm the odd man out in this discussion. I'm very curious >>>> to know what concrete advantages others have gained by treating the VM as >>>> something clearly distinct and separate from the View. What do you really >>>> gain from using value converters and code-behind logic, as opposed to >>>> putting that stuff into the VM? I'm not opposed to that approach, it's just >>>> not how I've done MVVM so far. While working on Crack.NET I created very >>>> dumb, passive Views and smart, demanding ViewModels. I know that the good >>>> Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love >>>> to hear his thoughts on this.
>>>> josh
>>>> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] >>>> <laur...@galasoft.ch> wrote:
>>>>> I want to chime in on that one.
>>>>> Yes, patterns are guidelines more than rules. I followed that >>>>> discussion with very much interest and can't wait to try some of that in my >>>>> next app, and it's really interesting to see the different streams of >>>>> thoughts. So far I think I see two major variations in the exposed >>>>> practices, one which considers that VM is a kind of replacement for >>>>> code-behind (let's call it a top-down approach) and thus a VM is very >>>>> tightly bound to a View. The other is rather a bottom-up approach and puts >>>>> the VM as an extension of the model, but formatted for the View.
>>>>> In the project I worked last, we took a very pragmatic approach, and >>>>> used VM for various reasons, the most important being avoiding that our >>>>> designers have to write any code. Josh's point is really valid, designers >>>>> should not have to worry about code, period. It's not their job. My role as >>>>> an integrator (IM calls that "Interactive Developer") was to specifically >>>>> avoid designers to have that kind of problems. This results in a series of >>>>> roundtrips between developers and designers coordinated by the integrator. >>>>> In that sense, a well thought VM can avoid a number of roundtrips. To me, >>>>> this is the most important aspect of the VM, because every roundtrip costs a >>>>> lot of money, and designers are damn expensive in a project.
>>>>> When I say we were pragmatic, I mean that because some in the team were >>>>> quite unexperienced, we ended up having quite some code in the code-behind. >>>>> If I had to do it again today, I would probably be stricter about that. But >>>>> on the other hand, I saw another team take a much stricter approach (Josh: >>>>> That was Linus' team, you probably remember him from our memorable dinner in >>>>> NY) and they spent a lot more time on some details than we did. Also, some >>>>> of the development was done in India, and their strict approach cost quite a >>>>> lot of time round tripping between India and Switzerland, or worse, having >>>>> to refactor much of the code that the Indian team delivered.
>>>>> Anyway… my next project should be a much smaller one (Silverlight), and >>>>> I want to apply MVVM in a stricter way there. That should be interesting >>>>> J
>>>>> *From:* wpf-disciples@googlegroups.com [mailto: >>>>> wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith >>>>> *Sent:* Monday, December 01, 2008 9:03 PM >>>>> *To:* wpf-disciples@googlegroups.com >>>>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the >>>>> need for ValueConverters
>>>>> Suppose you're working in the designer-developer workflow. Should the >>>>> designers have to write the value converters? What if they don't know how >>>>> to write some of them? I think it's easier to have the VM expose the >>>>> properties that they need to bind against, instead of having the designers >>>>> ask the developers to write a bunch of one-off converters for them.
>>>>> At the end of the day, MVVM (like any other pattern) is a set of >>>>> guidelines, not rules. So, as long as using the pattern makes your >>>>> application better, development easier, and testing more thorough, it's all >>>>> good.
>>>>> Josh
>>>>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli < >>>>> corradocava...@gmail.com> wrote:
>>>>> I'm with Marlon on this, while I agree that the VM can eliminate all >>>>> converters I don't like the idea of having a ViewModel too tied to the view >>>>> and, after all, converters are very reusable J.
>>>>> Just had a look at Silverlight validation model, think there's a lot of >>>>> work to do to fit it in a M-V-VM environment…
>>>>> -Corrado
>>>>> *From:* wpf-disciples@googlegroups.com [mailto: >>>>> wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech >>>>> *Sent:* lunedì 1 dicembre 2008 20:16
>>>>> *To:* wpf-disciples@googlegroups.com >>>>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the >>>>> need for ValueConverters
>>>>> I also think that this should be 50% 50%... If there is something >>>>> strongly UI coupled then I would probably put it in a ValueConverter...
>>>>> yet I must say I hate those creatures so called IValueConverters :/
>>>>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> >>>>> wrote:
>>>>> A ViewModel is basically a value converter on steroids. I takes "raw" >>>>> data and converts it into something presentation-friendly, and vice-versa. >>>>> If you ever find yourself binding an element's property to a ViewModel's >>>>> property, and you're using a value converter, stop! Why not just create a >>>>> property on the ViewModel that exposes the "formatted" data, and then drop >>>>> the value converter altogether?
>>>>> The only place I can see a use for value converters in an MVVM >>>>> architecture is cross-element bindings. If I'm binding the Visibility of a >>>>> panel to the IsChecked of a CheckBox, then I will need to use the >>>>> BooleanToVisibilityConverter. But, perhaps even in that case I should take >>>>> the "high road" and bind the IsChecked to a property on the ViewModel, and >>>>> then have a SomePanelVisibility property on the VM, to which the Panel is >>>>> bound.
<laur...@galasoft.ch> wrote: > You know, thinking about what I wrote earlier, I think that the "sweet > balance" really depends on a lot of factors.
> - Does your project have designers or not?
> - How experienced is your team?
> - How much unit testing do you do (don't laugh, I love unit tests but many > managers hate it and don't see the value of it, true story)
> - What is your model made of and where does it come from?
> - and of course personal preferences.
> *From:* wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith > *Sent:* Monday, December 01, 2008 10:41 PM
> *To:* wpf-disciples@googlegroups.com > *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > for ValueConverters
> Thanks Corrado. I get where you're coming from with this, but I'm still > unsure of where the "boundary" is. One could take this reasoning and push > it to the extreme by stating "Why bother with a ViewModel at all? Why not > just bind directly to the Model and use Value Converters to handle all other > transformations that need to be applied to make the Model show up in the UI > correctly?"
> Clearly, I know that nobody here is promoting that idea. The balance of > power, so to speak, between ViewModel and View is a spectrum in which I lean > toward the left and many others seem to lean more toward the right. I'm > wondering what guiding principles one should use to find the sweet spot > between the two opposing forces.
> Josh
> On Mon, Dec 1, 2008 at 4:32 PM, <corradocava...@gmail.com> wrote:
> Josh, > From my point of view, converters become part of a common library i > can share among projects, at least most commons (e.g: > BooleanToVisibility for SL projects), of course I won't ask a designer > to write code, but normally i create a very dumb preview, then > designer kicks in and does the rest, this when designer is involved, > and believe me, not many customer have designers. > Let's say you have a IsAvailable property on VM that you want to use > both Visibility trigger and Enabled property, your approach is to add > an additional property of type Visibility and this "doubling" must be > done for every VM while i can avoid this using a converter. > About testing: why do i have to test "Visibility" issues? my VM should > tell me that an item IsAvailable then its the view responsability to > convert that info in visibility (today, tomorrow it might change, and > i don't want to modify my VM for the new UI needs)
> -Corrado
> On Dec 1, 9:02 pm, "Josh Smith" <flappleja...@gmail.com> wrote: > > Suppose you're working in the designer-developer workflow. Should the > > designers have to write the value converters? What if they don't know > how > > to write some of them? I think it's easier to have the VM expose the > > properties that they need to bind against, instead of having the > designers > > ask the developers to write a bunch of one-off converters for them.
> > At the end of the day, MVVM (like any other pattern) is a set of > guidelines, > > not rules. So, as long as using the pattern makes your application > better, > > development easier, and testing more thorough, it's all good.
> > Josh
> > On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli < > corradocava...@gmail.com>wrote:
> > > I'm with Marlon on this, while I agree that the VM can eliminate all > > > converters I don't like the idea of having a ViewModel too tied to the > view > > > and, after all, converters are very reusable J.
> > > Just had a look at Silverlight validation model, think there's a lot of > > > work to do to fit it in a M-V-VM environment…
> > > -Corrado
> > > *From:* wpf-disciples@googlegroups.com [mailto: > > > wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech > > > *Sent:* lunedì 1 dicembre 2008 20:16 > > > *To:* wpf-disciples@googlegroups.com > > > *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > > > for ValueConverters
> > > I also think that this should be 50% 50%... If there is something > strongly > > > UI coupled then I would probably put it in a ValueConverter...
> > > yet I must say I hate those creatures so called IValueConverters :/
> > > On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com>
> > > wrote:
> > > A ViewModel is basically a value converter on steroids. I takes "raw" > data > > > and converts it into something presentation-friendly, and vice-versa. > If > > > you ever find yourself binding an element's property to a ViewModel's > > > property, and you're using a value converter, stop! Why not just > create a > > > property on the ViewModel that exposes the "formatted" data, and then > drop > > > the value converter altogether?
> > > The only place I can see a use for value converters in an MVVM > architecture > > > is cross-element bindings. If I'm binding the Visibility of a panel to > the > > > IsChecked of a CheckBox, then I will need to use the > > > BooleanToVisibilityConverter. But, perhaps even in that case I should > take > > > the "high road" and bind the IsChecked to a property on the ViewModel, > and > > > then have a SomePanelVisibility property on the VM, to which the Panel > is > > > bound.
> wrote: > One question, about creating a life cycle for a VM, is what mechanism would > you use in SL to do this? I was hoping not to have to do anything with the > VM in the code-behind as this would create too much coupling (for my > liking).
> On Mon, Dec 1, 2008 at 2:02 PM, Jeremiah Morrill < > jeremiah.morr...@gmail.com> wrote:
>> Josh,
>> Crack.NET has been one of my bases of learning MVVM. I think the typed >> datatemplate resources feel very natural and lets the View be as only >> intelligent as it needs to be. As you remember, this is where I was sorta >> getting pattern gun-shy in SL, given lack of built in support. At this >> moment, I'm a proponent of the ViewModel-data/type-driven View which you >> mentioned here. Before, in SL, I was initializing the VM in the codebehind >> and clearly it was more spaghettified if my goal was to *fly the whole >> plane *from the VM.
>> As far as ValueConverters go, I would say I'm guilty of having my VM >> pander the View a little bit. I would also add that I don't enjoy making >> VCs that much...but just like home-owners-associations, they are a necessary >> evil. Most cases I would assume it's fine to have View friendly >> properties...but when you start getting over run by redundant properties (in >> other formats) is when I may consider a VC.
>> Just my 2cents as a newbie ;). It does feel good to be able to follow >> these conversations now though...
>> -Jer
>> On Mon, Dec 1, 2008 at 12:55 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>> Great feedback, Laurent. Looking forward to your upcoming blog post >>> about your experience with taking other approaches. ;)
>>> I sense that I'm the odd man out in this discussion. I'm very curious to >>> know what concrete advantages others have gained by treating the VM as >>> something clearly distinct and separate from the View. What do you really >>> gain from using value converters and code-behind logic, as opposed to >>> putting that stuff into the VM? I'm not opposed to that approach, it's just >>> not how I've done MVVM so far. While working on Crack.NET I created very >>> dumb, passive Views and smart, demanding ViewModels. I know that the good >>> Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love >>> to hear his thoughts on this.
>>> josh
>>> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] >>> <laur...@galasoft.ch> wrote:
>>>> I want to chime in on that one.
>>>> Yes, patterns are guidelines more than rules. I followed that discussion >>>> with very much interest and can't wait to try some of that in my next app, >>>> and it's really interesting to see the different streams of thoughts. So far >>>> I think I see two major variations in the exposed practices, one which >>>> considers that VM is a kind of replacement for code-behind (let's call it a >>>> top-down approach) and thus a VM is very tightly bound to a View. The other >>>> is rather a bottom-up approach and puts the VM as an extension of the model, >>>> but formatted for the View.
>>>> In the project I worked last, we took a very pragmatic approach, and >>>> used VM for various reasons, the most important being avoiding that our >>>> designers have to write any code. Josh's point is really valid, designers >>>> should not have to worry about code, period. It's not their job. My role as >>>> an integrator (IM calls that "Interactive Developer") was to specifically >>>> avoid designers to have that kind of problems. This results in a series of >>>> roundtrips between developers and designers coordinated by the integrator. >>>> In that sense, a well thought VM can avoid a number of roundtrips. To me, >>>> this is the most important aspect of the VM, because every roundtrip costs a >>>> lot of money, and designers are damn expensive in a project.
>>>> When I say we were pragmatic, I mean that because some in the team were >>>> quite unexperienced, we ended up having quite some code in the code-behind. >>>> If I had to do it again today, I would probably be stricter about that. But >>>> on the other hand, I saw another team take a much stricter approach (Josh: >>>> That was Linus' team, you probably remember him from our memorable dinner in >>>> NY) and they spent a lot more time on some details than we did. Also, some >>>> of the development was done in India, and their strict approach cost quite a >>>> lot of time round tripping between India and Switzerland, or worse, having >>>> to refactor much of the code that the Indian team delivered.
>>>> Anyway… my next project should be a much smaller one (Silverlight), and >>>> I want to apply MVVM in a stricter way there. That should be interesting >>>> J
>>>> *From:* wpf-disciples@googlegroups.com [mailto: >>>> wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith >>>> *Sent:* Monday, December 01, 2008 9:03 PM >>>> *To:* wpf-disciples@googlegroups.com >>>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >>>> for ValueConverters
>>>> Suppose you're working in the designer-developer workflow. Should the >>>> designers have to write the value converters? What if they don't know how >>>> to write some of them? I think it's easier to have the VM expose the >>>> properties that they need to bind against, instead of having the designers >>>> ask the developers to write a bunch of one-off converters for them.
>>>> At the end of the day, MVVM (like any other pattern) is a set of >>>> guidelines, not rules. So, as long as using the pattern makes your >>>> application better, development easier, and testing more thorough, it's all >>>> good.
>>>> Josh
>>>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli < >>>> corradocava...@gmail.com> wrote:
>>>> I'm with Marlon on this, while I agree that the VM can eliminate all >>>> converters I don't like the idea of having a ViewModel too tied to the view >>>> and, after all, converters are very reusable J.
>>>> Just had a look at Silverlight validation model, think there's a lot of >>>> work to do to fit it in a M-V-VM environment…
>>>> -Corrado
>>>> *From:* wpf-disciples@googlegroups.com [mailto: >>>> wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech >>>> *Sent:* lunedì 1 dicembre 2008 20:16
>>>> *To:* wpf-disciples@googlegroups.com >>>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >>>> for ValueConverters
>>>> I also think that this should be 50% 50%... If there is something >>>> strongly UI coupled then I would probably put it in a ValueConverter...
>>>> yet I must say I hate those creatures so called IValueConverters :/
>>>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> >>>> wrote:
>>>> A ViewModel is basically a value converter on steroids. I takes "raw" >>>> data and converts it into something presentation-friendly, and vice-versa. >>>> If you ever find yourself binding an element's property to a ViewModel's >>>> property, and you're using a value converter, stop! Why not just create a >>>> property on the ViewModel that exposes the "formatted" data, and then drop >>>> the value converter altogether?
>>>> The only place I can see a use for value converters in an MVVM >>>> architecture is cross-element bindings. If I'm binding the Visibility of a >>>> panel to the IsChecked of a CheckBox, then I will need to use the >>>> BooleanToVisibilityConverter. But, perhaps even in that case I should take >>>> the "high road" and bind the IsChecked to a property on the ViewModel, and >>>> then have a SomePanelVisibility property on the VM, to which the Panel is >>>> bound.
Ah ha! I was under the impression that you guys were talking about running an initialize on the View's loaded event...which I haven't had a need for thus far. I know as this project gets bigger, I may need, or decided I need some sort of life-cycle in the VM..so I'm trying to sneak in as many questions now as possible :)
> * // This method call does not exist... > workspace.Dispose();* > }
> Josh
> On Mon, Dec 1, 2008 at 5:13 PM, Jeremiah Morrill < > jeremiah.morr...@gmail.com> wrote:
>> One question, about creating a life cycle for a VM, is what mechanism >> would you use in SL to do this? I was hoping not to have to do anything >> with the VM in the code-behind as this would create too much coupling (for >> my liking).
>> On Mon, Dec 1, 2008 at 2:02 PM, Jeremiah Morrill < >> jeremiah.morr...@gmail.com> wrote:
>>> Josh,
>>> Crack.NET has been one of my bases of learning MVVM. I think the typed >>> datatemplate resources feel very natural and lets the View be as only >>> intelligent as it needs to be. As you remember, this is where I was sorta >>> getting pattern gun-shy in SL, given lack of built in support. At this >>> moment, I'm a proponent of the ViewModel-data/type-driven View which you >>> mentioned here. Before, in SL, I was initializing the VM in the codebehind >>> and clearly it was more spaghettified if my goal was to *fly the whole >>> plane *from the VM.
>>> As far as ValueConverters go, I would say I'm guilty of having my VM >>> pander the View a little bit. I would also add that I don't enjoy making >>> VCs that much...but just like home-owners-associations, they are a necessary >>> evil. Most cases I would assume it's fine to have View friendly >>> properties...but when you start getting over run by redundant properties (in >>> other formats) is when I may consider a VC.
>>> Just my 2cents as a newbie ;). It does feel good to be able to follow >>> these conversations now though...
>>> -Jer
>>> On Mon, Dec 1, 2008 at 12:55 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>> Great feedback, Laurent. Looking forward to your upcoming blog post >>>> about your experience with taking other approaches. ;)
>>>> I sense that I'm the odd man out in this discussion. I'm very curious >>>> to know what concrete advantages others have gained by treating the VM as >>>> something clearly distinct and separate from the View. What do you really >>>> gain from using value converters and code-behind logic, as opposed to >>>> putting that stuff into the VM? I'm not opposed to that approach, it's just >>>> not how I've done MVVM so far. While working on Crack.NET I created very >>>> dumb, passive Views and smart, demanding ViewModels. I know that the good >>>> Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love >>>> to hear his thoughts on this.
>>>> josh
>>>> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] >>>> <laur...@galasoft.ch> wrote:
>>>>> I want to chime in on that one.
>>>>> Yes, patterns are guidelines more than rules. I followed that >>>>> discussion with very much interest and can't wait to try some of that in my >>>>> next app, and it's really interesting to see the different streams of >>>>> thoughts. So far I think I see two major variations in the exposed >>>>> practices, one which considers that VM is a kind of replacement for >>>>> code-behind (let's call it a top-down approach) and thus a VM is very >>>>> tightly bound to a View. The other is rather a bottom-up approach and puts >>>>> the VM as an extension of the model, but formatted for the View.
>>>>> In the project I worked last, we took a very pragmatic approach, and >>>>> used VM for various reasons, the most important being avoiding that our >>>>> designers have to write any code. Josh's point is really valid, designers >>>>> should not have to worry about code, period. It's not their job. My role as >>>>> an integrator (IM calls that "Interactive Developer") was to specifically >>>>> avoid designers to have that kind of problems. This results in a series of >>>>> roundtrips between developers and designers coordinated by the integrator. >>>>> In that sense, a well thought VM can avoid a number of roundtrips. To me, >>>>> this is the most important aspect of the VM, because every roundtrip costs a >>>>> lot of money, and designers are damn expensive in a project.
>>>>> When I say we were pragmatic, I mean that because some in the team were >>>>> quite unexperienced, we ended up having quite some code in the code-behind. >>>>> If I had to do it again today, I would probably be stricter about that. But >>>>> on the other hand, I saw another team take a much stricter approach (Josh: >>>>> That was Linus' team, you probably remember him from our memorable dinner in >>>>> NY) and they spent a lot more time on some details than we did. Also, some >>>>> of the development was done in India, and their strict approach cost quite a >>>>> lot of time round tripping between India and Switzerland, or worse, having >>>>> to refactor much of the code that the Indian team delivered.
>>>>> Anyway… my next project should be a much smaller one (Silverlight), and >>>>> I want to apply MVVM in a stricter way there. That should be interesting >>>>> J
>>>>> *From:* wpf-disciples@googlegroups.com [mailto: >>>>> wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith >>>>> *Sent:* Monday, December 01, 2008 9:03 PM >>>>> *To:* wpf-disciples@googlegroups.com >>>>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the >>>>> need for ValueConverters
>>>>> Suppose you're working in the designer-developer workflow. Should the >>>>> designers have to write the value converters? What if they don't know how >>>>> to write some of them? I think it's easier to have the VM expose the >>>>> properties that they need to bind against, instead of having the designers >>>>> ask the developers to write a bunch of one-off converters for them.
>>>>> At the end of the day, MVVM (like any other pattern) is a set of >>>>> guidelines, not rules. So, as long as using the pattern makes your >>>>> application better, development easier, and testing more thorough, it's all >>>>> good.
>>>>> Josh
>>>>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli < >>>>> corradocava...@gmail.com> wrote:
>>>>> I'm with Marlon on this, while I agree that the VM can eliminate all >>>>> converters I don't like the idea of having a ViewModel too tied to the view >>>>> and, after all, converters are very reusable J.
>>>>> Just had a look at Silverlight validation model, think there's a lot of >>>>> work to do to fit it in a M-V-VM environment…
>>>>> -Corrado
>>>>> *From:* wpf-disciples@googlegroups.com [mailto: >>>>> wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech >>>>> *Sent:* lunedì 1 dicembre 2008 20:16
>>>>> *To:* wpf-disciples@googlegroups.com >>>>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the >>>>> need for ValueConverters
>>>>> I also think that this should be 50% 50%... If there is something >>>>> strongly UI coupled then I would probably put it in a ValueConverter...
>>>>> yet I must say I hate those creatures so called IValueConverters :/
>>>>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> >>>>> wrote:
>>>>> A ViewModel is basically a value converter on steroids. I takes "raw" >>>>> data and converts it into something presentation-friendly, and vice-versa. >>>>> If you ever find yourself binding an element's property to a ViewModel's >>>>> property, and you're using a value converter, stop! Why not just create a >>>>> property on the ViewModel that exposes the "formatted" data, and then drop >>>>> the value converter altogether?
>>>>> The only place I can see a use for value converters in an MVVM >>>>> architecture is cross-element bindings. If I'm binding the Visibility of a >>>>> panel to the IsChecked of a CheckBox, then I will need to use the >>>>> BooleanToVisibilityConverter. But, perhaps even in that case I should take >>>>> the "high road" and bind the IsChecked to a property on the ViewModel, and >>>>> then have a SomePanelVisibility property on the VM, to which the Panel is >>>>> bound.
I wasn't referring specifically to the implementation details of how a lifecycle is managed. If people are loading VMs from the View, then it makes sense to manage the lifecycle from the View. In my apps, I load the View in response to putting a VM into the UI, so I manage the lifecycle from the place in my app that creates/loads/removes VM objects.
josh
On Mon, Dec 1, 2008 at 5:48 PM, Jeremiah Morrill <jeremiah.morr...@gmail.com
> wrote: > Ah ha! I was under the impression that you guys were talking about running > an initialize on the View's loaded event...which I haven't had a need for > thus far. I know as this project gets bigger, I may need, or decided I need > some sort of life-cycle in the VM..so I'm trying to sneak in as many > questions now as possible :)
> -Jer
> On Mon, Dec 1, 2008 at 2:36 PM, Josh Smith <flappleja...@gmail.com> wrote:
>> Jer,
>> In Crack.NET there is only the "Initialize" phase of the lifecycle. This >> occurs in InjectedWindowViewModel, as seen below...
>> TWorkspace FindOrCreateWorkspace<TWorkspace>() where TWorkspace : >> WorkspaceViewModel, new() >> { >> TWorkspace workspace = this.Workspaces.FirstOrDefault(ws => ws is >> TWorkspace) as TWorkspace;
>> * // This method call does not exist... >> workspace.Dispose();* >> }
>> Josh
>> On Mon, Dec 1, 2008 at 5:13 PM, Jeremiah Morrill < >> jeremiah.morr...@gmail.com> wrote:
>>> One question, about creating a life cycle for a VM, is what mechanism >>> would you use in SL to do this? I was hoping not to have to do anything >>> with the VM in the code-behind as this would create too much coupling (for >>> my liking).
>>> On Mon, Dec 1, 2008 at 2:02 PM, Jeremiah Morrill < >>> jeremiah.morr...@gmail.com> wrote:
>>>> Josh,
>>>> Crack.NET has been one of my bases of learning MVVM. I think the typed >>>> datatemplate resources feel very natural and lets the View be as only >>>> intelligent as it needs to be. As you remember, this is where I was sorta >>>> getting pattern gun-shy in SL, given lack of built in support. At this >>>> moment, I'm a proponent of the ViewModel-data/type-driven View which you >>>> mentioned here. Before, in SL, I was initializing the VM in the codebehind >>>> and clearly it was more spaghettified if my goal was to *fly the whole >>>> plane *from the VM.
>>>> As far as ValueConverters go, I would say I'm guilty of having my VM >>>> pander the View a little bit. I would also add that I don't enjoy making >>>> VCs that much...but just like home-owners-associations, they are a necessary >>>> evil. Most cases I would assume it's fine to have View friendly >>>> properties...but when you start getting over run by redundant properties (in >>>> other formats) is when I may consider a VC.
>>>> Just my 2cents as a newbie ;). It does feel good to be able to follow >>>> these conversations now though...
>>>> -Jer
>>>> On Mon, Dec 1, 2008 at 12:55 PM, Josh Smith <flappleja...@gmail.com>wrote:
>>>>> Great feedback, Laurent. Looking forward to your upcoming blog post >>>>> about your experience with taking other approaches. ;)
>>>>> I sense that I'm the odd man out in this discussion. I'm very curious >>>>> to know what concrete advantages others have gained by treating the VM as >>>>> something clearly distinct and separate from the View. What do you really >>>>> gain from using value converters and code-behind logic, as opposed to >>>>> putting that stuff into the VM? I'm not opposed to that approach, it's just >>>>> not how I've done MVVM so far. While working on Crack.NET I created very >>>>> dumb, passive Views and smart, demanding ViewModels. I know that the good >>>>> Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love >>>>> to hear his thoughts on this.
>>>>> josh
>>>>> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] >>>>> <laur...@galasoft.ch> wrote:
>>>>>> I want to chime in on that one.
>>>>>> Yes, patterns are guidelines more than rules. I followed that >>>>>> discussion with very much interest and can't wait to try some of that in my >>>>>> next app, and it's really interesting to see the different streams of >>>>>> thoughts. So far I think I see two major variations in the exposed >>>>>> practices, one which considers that VM is a kind of replacement for >>>>>> code-behind (let's call it a top-down approach) and thus a VM is very >>>>>> tightly bound to a View. The other is rather a bottom-up approach and puts >>>>>> the VM as an extension of the model, but formatted for the View.
>>>>>> In the project I worked last, we took a very pragmatic approach, and >>>>>> used VM for various reasons, the most important being avoiding that our >>>>>> designers have to write any code. Josh's point is really valid, designers >>>>>> should not have to worry about code, period. It's not their job. My role as >>>>>> an integrator (IM calls that "Interactive Developer") was to specifically >>>>>> avoid designers to have that kind of problems. This results in a series of >>>>>> roundtrips between developers and designers coordinated by the integrator. >>>>>> In that sense, a well thought VM can avoid a number of roundtrips. To me, >>>>>> this is the most important aspect of the VM, because every roundtrip costs a >>>>>> lot of money, and designers are damn expensive in a project.
>>>>>> When I say we were pragmatic, I mean that because some in the team >>>>>> were quite unexperienced, we ended up having quite some code in the >>>>>> code-behind. If I had to do it again today, I would probably be stricter >>>>>> about that. But on the other hand, I saw another team take a much stricter >>>>>> approach (Josh: That was Linus' team, you probably remember him from our >>>>>> memorable dinner in NY) and they spent a lot more time on some details than >>>>>> we did. Also, some of the development was done in India, and their strict >>>>>> approach cost quite a lot of time round tripping between India and >>>>>> Switzerland, or worse, having to refactor much of the code that the Indian >>>>>> team delivered.
>>>>>> Anyway… my next project should be a much smaller one (Silverlight), >>>>>> and I want to apply MVVM in a stricter way there. That should be interesting >>>>>> J
>>>>>> *From:* wpf-disciples@googlegroups.com [mailto: >>>>>> wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith >>>>>> *Sent:* Monday, December 01, 2008 9:03 PM >>>>>> *To:* wpf-disciples@googlegroups.com >>>>>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the >>>>>> need for ValueConverters
>>>>>> Suppose you're working in the designer-developer workflow. Should the >>>>>> designers have to write the value converters? What if they don't know how >>>>>> to write some of them? I think it's easier to have the VM expose the >>>>>> properties that they need to bind against, instead of having the designers >>>>>> ask the developers to write a bunch of one-off converters for them.
>>>>>> At the end of the day, MVVM (like any other pattern) is a set of >>>>>> guidelines, not rules. So, as long as using the pattern makes your >>>>>> application better, development easier, and testing more thorough, it's all >>>>>> good.
>>>>>> Josh
>>>>>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli < >>>>>> corradocava...@gmail.com> wrote:
>>>>>> I'm with Marlon on this, while I agree that the VM can eliminate all >>>>>> converters I don't like the idea of having a ViewModel too tied to the view >>>>>> and, after all, converters are very reusable J.
>>>>>> Just had a look at Silverlight validation model, think there's a lot >>>>>> of work to do to fit it in a M-V-VM environment…
>>>>>> -Corrado
>>>>>> *From:* wpf-disciples@googlegroups.com [mailto: >>>>>> wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech >>>>>> *Sent:* lunedì 1 dicembre 2008 20:16
>>>>>> *To:* wpf-disciples@googlegroups.com >>>>>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the >>>>>> need for ValueConverters
>>>>>> I also think that this should be 50% 50%... If there is something >>>>>> strongly UI coupled then I would probably put it in a ValueConverter...
>>>>>> yet I must say I hate those creatures so called IValueConverters :/
>>>>>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> >>>>>> wrote:
>>>>>> A ViewModel is basically a value converter on steroids. I takes "raw" >>>>>> data and converts it into something presentation-friendly, and vice-versa. >>>>>> If you ever find yourself binding an element's property to a ViewModel's >>>>>> property, and you're using a value converter, stop! Why not just create a >>>>>> property on the ViewModel that exposes the "formatted" data, and then drop >>>>>> the value converter altogether?
Jer, using the Silverlight toolkit you can now define implicit styles so I *suppose* (but I didn’t try it) that you could also use the ImplicitStyleManager to define a View for a given view model type… interesting thought, I have to try that… tomorrow. ;)
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Jeremiah Morrill Sent: Monday, December 01, 2008 11:02 PM To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need for ValueConverters
Josh,
Crack.NET has been one of my bases of learning MVVM. I think the typed datatemplate resources feel very natural and lets the View be as only intelligent as it needs to be. As you remember, this is where I was sorta getting pattern gun-shy in SL, given lack of built in support. At this moment, I'm a proponent of the ViewModel-data/type-driven View which you mentioned here. Before, in SL, I was initializing the VM in the codebehind and clearly it was more spaghettified if my goal was to fly the whole plane from the VM.
As far as ValueConverters go, I would say I'm guilty of having my VM pander the View a little bit. I would also add that I don't enjoy making VCs that much...but just like home-owners-associations, they are a necessary evil. Most cases I would assume it's fine to have View friendly properties...but when you start getting over run by redundant properties (in other formats) is when I may consider a VC.
Just my 2cents as a newbie ;). It does feel good to be able to follow these conversations now though...
-Jer
On Mon, Dec 1, 2008 at 12:55 PM, Josh Smith <flappleja...@gmail.com> wrote:
Great feedback, Laurent. Looking forward to your upcoming blog post about your experience with taking other approaches. ;)
I sense that I'm the odd man out in this discussion. I'm very curious to know what concrete advantages others have gained by treating the VM as something clearly distinct and separate from the View. What do you really gain from using value converters and code-behind logic, as opposed to putting that stuff into the VM? I'm not opposed to that approach, it's just not how I've done MVVM so far. While working on Crack.NET I created very dumb, passive Views and smart, demanding ViewModels. I know that the good Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love to hear his thoughts on this.
josh
On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP]
Yes, patterns are guidelines more than rules. I followed that discussion with very much interest and can't wait to try some of that in my next app, and it's really interesting to see the different streams of thoughts. So far I think I see two major variations in the exposed practices, one which considers that VM is a kind of replacement for code-behind (let's call it a top-down approach) and thus a VM is very tightly bound to a View. The other is rather a bottom-up approach and puts the VM as an extension of the model, but formatted for the View.
In the project I worked last, we took a very pragmatic approach, and used VM for various reasons, the most important being avoiding that our designers have to write any code. Josh's point is really valid, designers should not have to worry about code, period. It's not their job. My role as an integrator (IM calls that "Interactive Developer") was to specifically avoid designers to have that kind of problems. This results in a series of roundtrips between developers and designers coordinated by the integrator. In that sense, a well thought VM can avoid a number of roundtrips. To me, this is the most important aspect of the VM, because every roundtrip costs a lot of money, and designers are damn expensive in a project.
When I say we were pragmatic, I mean that because some in the team were quite unexperienced, we ended up having quite some code in the code-behind. If I had to do it again today, I would probably be stricter about that. But on the other hand, I saw another team take a much stricter approach (Josh: That was Linus' team, you probably remember him from our memorable dinner in NY) and they spent a lot more time on some details than we did. Also, some of the development was done in India, and their strict approach cost quite a lot of time round tripping between India and Switzerland, or worse, having to refactor much of the code that the Indian team delivered.
Anyway… my next project should be a much smaller one (Silverlight), and I want to apply MVVM in a stricter way there. That should be interesting J
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Josh Smith Sent: Monday, December 01, 2008 9:03 PM
To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need for ValueConverters
Suppose you're working in the designer-developer workflow. Should the designers have to write the value converters? What if they don't know how to write some of them? I think it's easier to have the VM expose the properties that they need to bind against, instead of having the designers ask the developers to write a bunch of one-off converters for them.
At the end of the day, MVVM (like any other pattern) is a set of guidelines, not rules. So, as long as using the pattern makes your application better, development easier, and testing more thorough, it's all good.
Josh
On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli <corradocava...@gmail.com> wrote:
I'm with Marlon on this, while I agree that the VM can eliminate all converters I don't like the idea of having a ViewModel too tied to the view and, after all, converters are very reusable J.
Just had a look at Silverlight validation model, think there's a lot of work to do to fit it in a M-V-VM environment…
-Corrado
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Marlon Grech Sent: lunedì 1 dicembre 2008 20:16
To: wpf-disciples@googlegroups.com Subject: [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need for ValueConverters
I also think that this should be 50% 50%... If there is something strongly UI coupled then I would probably put it in a ValueConverter...
yet I must say I hate those creatures so called IValueConverters :/
On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> wrote:
A ViewModel is basically a value converter on steroids. I takes "raw" data and converts it into something presentation-friendly, and vice-versa. If you ever find yourself binding an element's property to a ViewModel's property, and you're using a value converter, stop! Why not just create a property on the ViewModel that exposes the "formatted" data, and then drop the value converter altogether?
The only place I can see a use for value converters in an MVVM architecture is cross-element bindings. If I'm binding the Visibility of a panel to the IsChecked of a CheckBox, then I will need to use the BooleanToVisibilityConverter. But, perhaps even in that case I should take the "high road" and bind the IsChecked to a property on the ViewModel, and then have a SomePanelVisibility property on the VM, to which the Panel is bound.
I'll have to check it out...Actually, I'm going to check it out right after this email!
I've been using the ResourceSelector from the SL Extensions<http://slextensions.net/showcase.aspx#Page=20>, which is a simple, but very powerful class. Totally makes up for the fact there are no typed datatemplates.
So essentially, I have a VM with a property called CurrentViewModel, of my ViewModelBase type. I just have content control bind it's content to this property, and bind the ContentTemplate to a DataTemplate that uses the ResourceSelector. This way, whatever .NET type my VM is, the View will pick the right datatemplate...just like WPF. Here is the XAML for it. The "x:Key="LoginViewModel", LoginViewModel is the name of my ViewModel type. It also supports the type FullName if you really need.
<laur...@galasoft.ch> wrote: > Jer, using the Silverlight toolkit you can now define implicit styles so > I *suppose* (but I didn't try it) that you could also use the > ImplicitStyleManager to define a View for a given view model type… > interesting thought, I have to try that… tomorrow. ;)
> *From:* wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] *On Behalf Of *Jeremiah Morrill > *Sent:* Monday, December 01, 2008 11:02 PM
> *To:* wpf-disciples@googlegroups.com > *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > for ValueConverters
> Josh,
> Crack.NET has been one of my bases of learning MVVM. I think the typed > datatemplate resources feel very natural and lets the View be as only > intelligent as it needs to be. As you remember, this is where I was sorta > getting pattern gun-shy in SL, given lack of built in support. At this > moment, I'm a proponent of the ViewModel-data/type-driven View which you > mentioned here. Before, in SL, I was initializing the VM in the codebehind > and clearly it was more spaghettified if my goal was to *fly the whole > plane *from the VM.
> As far as ValueConverters go, I would say I'm guilty of having my VM pander > the View a little bit. I would also add that I don't enjoy making VCs that > much...but just like home-owners-associations, they are a necessary evil. > Most cases I would assume it's fine to have View friendly properties...but > when you start getting over run by redundant properties (in other formats) > is when I may consider a VC.
> Just my 2cents as a newbie ;). It does feel good to be able to follow > these conversations now though...
> -Jer
> On Mon, Dec 1, 2008 at 12:55 PM, Josh Smith <flappleja...@gmail.com> > wrote:
> Great feedback, Laurent. Looking forward to your upcoming blog post about > your experience with taking other approaches. ;)
> I sense that I'm the odd man out in this discussion. I'm very curious to > know what concrete advantages others have gained by treating the VM as > something clearly distinct and separate from the View. What do you really > gain from using value converters and code-behind logic, as opposed to > putting that stuff into the VM? I'm not opposed to that approach, it's just > not how I've done MVVM so far. While working on Crack.NET I created very > dumb, passive Views and smart, demanding ViewModels. I know that the good > Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love > to hear his thoughts on this.
> josh
> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] > <laur...@galasoft.ch> wrote:
> I want to chime in on that one.
> Yes, patterns are guidelines more than rules. I followed that discussion > with very much interest and can't wait to try some of that in my next app, > and it's really interesting to see the different streams of thoughts. So far > I think I see two major variations in the exposed practices, one which > considers that VM is a kind of replacement for code-behind (let's call it a > top-down approach) and thus a VM is very tightly bound to a View. The other > is rather a bottom-up approach and puts the VM as an extension of the model, > but formatted for the View.
> In the project I worked last, we took a very pragmatic approach, and used > VM for various reasons, the most important being avoiding that our designers > have to write any code. Josh's point is really valid, designers should not > have to worry about code, period. It's not their job. My role as an > integrator (IM calls that "Interactive Developer") was to specifically avoid > designers to have that kind of problems. This results in a series of > roundtrips between developers and designers coordinated by the integrator. > In that sense, a well thought VM can avoid a number of roundtrips. To me, > this is the most important aspect of the VM, because every roundtrip costs a > lot of money, and designers are damn expensive in a project.
> When I say we were pragmatic, I mean that because some in the team were > quite unexperienced, we ended up having quite some code in the code-behind. > If I had to do it again today, I would probably be stricter about that. But > on the other hand, I saw another team take a much stricter approach (Josh: > That was Linus' team, you probably remember him from our memorable dinner in > NY) and they spent a lot more time on some details than we did. Also, some > of the development was done in India, and their strict approach cost quite a > lot of time round tripping between India and Switzerland, or worse, having > to refactor much of the code that the Indian team delivered.
> Anyway… my next project should be a much smaller one (Silverlight), and I > want to apply MVVM in a stricter way there. That should be interesting J
> *From:* wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith > *Sent:* Monday, December 01, 2008 9:03 PM
> *To:* wpf-disciples@googlegroups.com > *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > for ValueConverters
> Suppose you're working in the designer-developer workflow. Should the > designers have to write the value converters? What if they don't know how > to write some of them? I think it's easier to have the VM expose the > properties that they need to bind against, instead of having the designers > ask the developers to write a bunch of one-off converters for them.
> At the end of the day, MVVM (like any other pattern) is a set of > guidelines, not rules. So, as long as using the pattern makes your > application better, development easier, and testing more thorough, it's all > good.
> Josh
> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli <corradocava...@gmail.com> > wrote:
> I'm with Marlon on this, while I agree that the VM can eliminate all > converters I don't like the idea of having a ViewModel too tied to the view > and, after all, converters are very reusable J.
> Just had a look at Silverlight validation model, think there's a lot of > work to do to fit it in a M-V-VM environment…
> -Corrado
> *From:* wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech > *Sent:* lunedì 1 dicembre 2008 20:16
> *To:* wpf-disciples@googlegroups.com > *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need > for ValueConverters
> I also think that this should be 50% 50%... If there is something strongly > UI coupled then I would probably put it in a ValueConverter...
> yet I must say I hate those creatures so called IValueConverters :/
> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> wrote:
> A ViewModel is basically a value converter on steroids. I takes "raw" data > and converts it into something presentation-friendly, and vice-versa. If > you ever find yourself binding an element's property to a ViewModel's > property, and you're using a value converter, stop! Why not just create a > property on the ViewModel that exposes the "formatted" data, and then drop > the value converter altogether?
> The only place I can see a use for value converters in an MVVM architecture > is cross-element bindings. If I'm binding the Visibility of a panel to the > IsChecked of a CheckBox, then I will need to use the > BooleanToVisibilityConverter. But, perhaps even in that case I should take > the "high road" and bind the IsChecked to a property on the ViewModel, and > then have a SomePanelVisibility property on the VM, to which the Panel is
This ImplicitStyleManager is rad Laurent! It doesn't solve the issue of no typed datatemplates, but it sure fixes other issues..Like no support for merged resource dictionaries...of of course, implicit styles =P
-Jer
On Mon, Dec 1, 2008 at 3:04 PM, Jeremiah Morrill <jeremiah.morr...@gmail.com
> wrote: > I'll have to check it out...Actually, I'm going to check it out right after > this email!
> I've been using the ResourceSelector from the SL Extensions<http://slextensions.net/showcase.aspx#Page=20>, > which is a simple, but very powerful class. Totally makes up for the fact > there are no typed datatemplates.
> So essentially, I have a VM with a property called CurrentViewModel, of my > ViewModelBase type. I just have content control bind it's content to this > property, and bind the ContentTemplate to a DataTemplate that uses the > ResourceSelector. This way, whatever .NET type my VM is, the View will pick > the right datatemplate...just like WPF. Here is the XAML for it. The > "x:Key="LoginViewModel", LoginViewModel is the name of my ViewModel type. > It also supports the type FullName if you really need.
> On Mon, Dec 1, 2008 at 2:52 PM, Laurent Bugnion, GalaSoft [MVP] > <laur...@galasoft.ch> wrote:
>> Jer, using the Silverlight toolkit you can now define implicit styles so >> I *suppose* (but I didn't try it) that you could also use the >> ImplicitStyleManager to define a View for a given view model type… >> interesting thought, I have to try that… tomorrow. ;)
>> *From:* wpf-disciples@googlegroups.com [mailto: >> wpf-disciples@googlegroups.com] *On Behalf Of *Jeremiah Morrill >> *Sent:* Monday, December 01, 2008 11:02 PM
>> *To:* wpf-disciples@googlegroups.com >> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >> for ValueConverters
>> Josh,
>> Crack.NET has been one of my bases of learning MVVM. I think the typed >> datatemplate resources feel very natural and lets the View be as only >> intelligent as it needs to be. As you remember, this is where I was sorta >> getting pattern gun-shy in SL, given lack of built in support. At this >> moment, I'm a proponent of the ViewModel-data/type-driven View which you >> mentioned here. Before, in SL, I was initializing the VM in the codebehind >> and clearly it was more spaghettified if my goal was to *fly the whole >> plane *from the VM.
>> As far as ValueConverters go, I would say I'm guilty of having my VM >> pander the View a little bit. I would also add that I don't enjoy making >> VCs that much...but just like home-owners-associations, they are a necessary >> evil. Most cases I would assume it's fine to have View friendly >> properties...but when you start getting over run by redundant properties (in >> other formats) is when I may consider a VC.
>> Just my 2cents as a newbie ;). It does feel good to be able to follow >> these conversations now though...
>> -Jer
>> On Mon, Dec 1, 2008 at 12:55 PM, Josh Smith <flappleja...@gmail.com> >> wrote:
>> Great feedback, Laurent. Looking forward to your upcoming blog post about >> your experience with taking other approaches. ;)
>> I sense that I'm the odd man out in this discussion. I'm very curious to >> know what concrete advantages others have gained by treating the VM as >> something clearly distinct and separate from the View. What do you really >> gain from using value converters and code-behind logic, as opposed to >> putting that stuff into the VM? I'm not opposed to that approach, it's just >> not how I've done MVVM so far. While working on Crack.NET I created very >> dumb, passive Views and smart, demanding ViewModels. I know that the good >> Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love >> to hear his thoughts on this.
>> josh
>> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] >> <laur...@galasoft.ch> wrote:
>> I want to chime in on that one.
>> Yes, patterns are guidelines more than rules. I followed that discussion >> with very much interest and can't wait to try some of that in my next app, >> and it's really interesting to see the different streams of thoughts. So far >> I think I see two major variations in the exposed practices, one which >> considers that VM is a kind of replacement for code-behind (let's call it a >> top-down approach) and thus a VM is very tightly bound to a View. The other >> is rather a bottom-up approach and puts the VM as an extension of the model, >> but formatted for the View.
>> In the project I worked last, we took a very pragmatic approach, and used >> VM for various reasons, the most important being avoiding that our designers >> have to write any code. Josh's point is really valid, designers should not >> have to worry about code, period. It's not their job. My role as an >> integrator (IM calls that "Interactive Developer") was to specifically avoid >> designers to have that kind of problems. This results in a series of >> roundtrips between developers and designers coordinated by the integrator. >> In that sense, a well thought VM can avoid a number of roundtrips. To me, >> this is the most important aspect of the VM, because every roundtrip costs a >> lot of money, and designers are damn expensive in a project.
>> When I say we were pragmatic, I mean that because some in the team were >> quite unexperienced, we ended up having quite some code in the code-behind. >> If I had to do it again today, I would probably be stricter about that. But >> on the other hand, I saw another team take a much stricter approach (Josh: >> That was Linus' team, you probably remember him from our memorable dinner in >> NY) and they spent a lot more time on some details than we did. Also, some >> of the development was done in India, and their strict approach cost quite a >> lot of time round tripping between India and Switzerland, or worse, having >> to refactor much of the code that the Indian team delivered.
>> Anyway… my next project should be a much smaller one (Silverlight), and I >> want to apply MVVM in a stricter way there. That should be interesting J
>> *From:* wpf-disciples@googlegroups.com [mailto: >> wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith >> *Sent:* Monday, December 01, 2008 9:03 PM
>> *To:* wpf-disciples@googlegroups.com >> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >> for ValueConverters
>> Suppose you're working in the designer-developer workflow. Should the >> designers have to write the value converters? What if they don't know how >> to write some of them? I think it's easier to have the VM expose the >> properties that they need to bind against, instead of having the designers >> ask the developers to write a bunch of one-off converters for them.
>> At the end of the day, MVVM (like any other pattern) is a set of >> guidelines, not rules. So, as long as using the pattern makes your >> application better, development easier, and testing more thorough, it's all >> good.
>> Josh
>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli <corradocava...@gmail.com> >> wrote:
>> I'm with Marlon on this, while I agree that the VM can eliminate all >> converters I don't like the idea of having a ViewModel too tied to the view >> and, after all, converters are very reusable J.
>> Just had a look at Silverlight validation model, think there's a lot of >> work to do to fit it in a M-V-VM environment…
>> -Corrado
>> *From:* wpf-disciples@googlegroups.com [mailto: >> wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech >> *Sent:* lunedì 1 dicembre 2008 20:16
>> *To:* wpf-disciples@googlegroups.com >> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >> for ValueConverters
>> I also think that this should be 50% 50%... If there is something strongly >> UI coupled then I would probably put it in a ValueConverter...
>> yet I must say I hate those creatures so called IValueConverters :/
>> On Mon, Dec 1, 2008 at 5:08 PM, Josh Smith <flappleja...@gmail.com> >> wrote:
>> A ViewModel is basically a value converter on steroids. I takes "raw" >> data and converts it into something presentation-friendly, and vice-versa. >> If you ever find yourself binding an element's property to a ViewModel's >> property, and you're using a value converter,
Prism does a good job at handling all that wiring cruft that you don't want to deal with and I hear that the new version targets SL so that the same VM CAN be used for an SL app as well as a full WPF app. BTW, now that SL will have 3D and hardware acceleration capabilities, is there anything preventing it from being the preferred desktop client framework?
On Mon, Dec 1, 2008 at 6:28 PM, Jeremiah Morrill <jeremiah.morr...@gmail.com
> wrote: > This ImplicitStyleManager is rad Laurent! It doesn't solve the issue of no > typed datatemplates, but it sure fixes other issues..Like no support for > merged resource dictionaries...of of course, implicit styles =P
> -Jer
> On Mon, Dec 1, 2008 at 3:04 PM, Jeremiah Morrill < > jeremiah.morr...@gmail.com> wrote:
>> I'll have to check it out...Actually, I'm going to check it out right >> after this email!
>> I've been using the ResourceSelector from the SL Extensions<http://slextensions.net/showcase.aspx#Page=20>, >> which is a simple, but very powerful class. Totally makes up for the fact >> there are no typed datatemplates.
>> So essentially, I have a VM with a property called CurrentViewModel, of my >> ViewModelBase type. I just have content control bind it's content to this >> property, and bind the ContentTemplate to a DataTemplate that uses the >> ResourceSelector. This way, whatever .NET type my VM is, the View will pick >> the right datatemplate...just like WPF. Here is the XAML for it. The >> "x:Key="LoginViewModel", LoginViewModel is the name of my ViewModel type. >> It also supports the type FullName if you really need.
>> On Mon, Dec 1, 2008 at 2:52 PM, Laurent Bugnion, GalaSoft [MVP] >> <laur...@galasoft.ch> wrote:
>>> Jer, using the Silverlight toolkit you can now define implicit styles >>> so I *suppose* (but I didn't try it) that you could also use the >>> ImplicitStyleManager to define a View for a given view model type… >>> interesting thought, I have to try that… tomorrow. ;)
>>> *From:* wpf-disciples@googlegroups.com [mailto: >>> wpf-disciples@googlegroups.com] *On Behalf Of *Jeremiah Morrill >>> *Sent:* Monday, December 01, 2008 11:02 PM
>>> *To:* wpf-disciples@googlegroups.com >>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >>> for ValueConverters
>>> Josh,
>>> Crack.NET has been one of my bases of learning MVVM. I think the typed >>> datatemplate resources feel very natural and lets the View be as only >>> intelligent as it needs to be. As you remember, this is where I was sorta >>> getting pattern gun-shy in SL, given lack of built in support. At this >>> moment, I'm a proponent of the ViewModel-data/type-driven View which you >>> mentioned here. Before, in SL, I was initializing the VM in the codebehind >>> and clearly it was more spaghettified if my goal was to *fly the whole >>> plane *from the VM.
>>> As far as ValueConverters go, I would say I'm guilty of having my VM >>> pander the View a little bit. I would also add that I don't enjoy making >>> VCs that much...but just like home-owners-associations, they are a necessary >>> evil. Most cases I would assume it's fine to have View friendly >>> properties...but when you start getting over run by redundant properties (in >>> other formats) is when I may consider a VC.
>>> Just my 2cents as a newbie ;). It does feel good to be able to follow >>> these conversations now though...
>>> -Jer
>>> On Mon, Dec 1, 2008 at 12:55 PM, Josh Smith <flappleja...@gmail.com> >>> wrote:
>>> Great feedback, Laurent. Looking forward to your upcoming blog post >>> about your experience with taking other approaches. ;)
>>> I sense that I'm the odd man out in this discussion. I'm very curious to >>> know what concrete advantages others have gained by treating the VM as >>> something clearly distinct and separate from the View. What do you really >>> gain from using value converters and code-behind logic, as opposed to >>> putting that stuff into the VM? I'm not opposed to that approach, it's just >>> not how I've done MVVM so far. While working on Crack.NET I created very >>> dumb, passive Views and smart, demanding ViewModels. I know that the good >>> Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love >>> to hear his thoughts on this.
>>> josh
>>> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] >>> <laur...@galasoft.ch> wrote:
>>> I want to chime in on that one.
>>> Yes, patterns are guidelines more than rules. I followed that discussion >>> with very much interest and can't wait to try some of that in my next app, >>> and it's really interesting to see the different streams of thoughts. So far >>> I think I see two major variations in the exposed practices, one which >>> considers that VM is a kind of replacement for code-behind (let's call it a >>> top-down approach) and thus a VM is very tightly bound to a View. The other >>> is rather a bottom-up approach and puts the VM as an extension of the model, >>> but formatted for the View.
>>> In the project I worked last, we took a very pragmatic approach, and used >>> VM for various reasons, the most important being avoiding that our designers >>> have to write any code. Josh's point is really valid, designers should not >>> have to worry about code, period. It's not their job. My role as an >>> integrator (IM calls that "Interactive Developer") was to specifically avoid >>> designers to have that kind of problems. This results in a series of >>> roundtrips between developers and designers coordinated by the integrator. >>> In that sense, a well thought VM can avoid a number of roundtrips. To me, >>> this is the most important aspect of the VM, because every roundtrip costs a >>> lot of money, and designers are damn expensive in a project.
>>> When I say we were pragmatic, I mean that because some in the team were >>> quite unexperienced, we ended up having quite some code in the code-behind. >>> If I had to do it again today, I would probably be stricter about that. But >>> on the other hand, I saw another team take a much stricter approach (Josh: >>> That was Linus' team, you probably remember him from our memorable dinner in >>> NY) and they spent a lot more time on some details than we did. Also, some >>> of the development was done in India, and their strict approach cost quite a >>> lot of time round tripping between India and Switzerland, or worse, having >>> to refactor much of the code that the Indian team delivered.
>>> Anyway… my next project should be a much smaller one (Silverlight), and I >>> want to apply MVVM in a stricter way there. That should be interesting J
>>> *From:* wpf-disciples@googlegroups.com [mailto: >>> wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith >>> *Sent:* Monday, December 01, 2008 9:03 PM
>>> *To:* wpf-disciples@googlegroups.com >>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >>> for ValueConverters
>>> Suppose you're working in the designer-developer workflow. Should the >>> designers have to write the value converters? What if they don't know how >>> to write some of them? I think it's easier to have the VM expose the >>> properties that they need to bind against, instead of having the designers >>> ask the developers to write a bunch of one-off converters for them.
>>> At the end of the day, MVVM (like any other pattern) is a set of >>> guidelines, not rules. So, as long as using the pattern makes your >>> application better, development easier, and testing more thorough, it's all >>> good.
>>> Josh
>>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli < >>> corradocava...@gmail.com> wrote:
>>> I'm with Marlon on this, while I agree that the VM can eliminate all >>> converters I don't like the idea of having a ViewModel too tied to the view >>> and, after all, converters are very reusable J.
>>> Just had a look at Silverlight validation model, think there's a lot of >>> work to do to fit it in a M-V-VM environment…
>>> -Corrado
>>> *From:* wpf-disciples@googlegroups.com [mailto: >>> wpf-disciples@googlegroups.com] *On Behalf Of *Marlon Grech >>> *Sent:* lunedì 1 dicembre 2008 20:16
>>> *To:* wpf-disciples@googlegroups.com >>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >>> for
>>is there anything preventing it from being the preferred desktop client
framework
Hard to say until we see what the caveats are to 3D and HW acceleration. Flash 10 has those, but it's still neutered and sandboxed.
The apps I usually work on (if they were WPF), are pretty market specific...So I *need* full trust, COM interop, p/invoke, etc. Most biz apps don't need this, but I don't think SL will take down WPF anytime with me ;)
On Mon, Dec 1, 2008 at 3:35 PM, Mike Brown <mbrow...@gmail.com> wrote: > Prism does a good job at handling all that wiring cruft that you don't want > to deal with and I hear that the new version targets SL so that the same VM > CAN be used for an SL app as well as a full WPF app. BTW, now that SL will > have 3D and hardware acceleration capabilities, is there anything preventing > it from being the preferred desktop client framework?
> On Mon, Dec 1, 2008 at 6:28 PM, Jeremiah Morrill < > jeremiah.morr...@gmail.com> wrote:
>> This ImplicitStyleManager is rad Laurent! It doesn't solve the issue of >> no typed datatemplates, but it sure fixes other issues..Like no support for >> merged resource dictionaries...of of course, implicit styles =P
>> -Jer
>> On Mon, Dec 1, 2008 at 3:04 PM, Jeremiah Morrill < >> jeremiah.morr...@gmail.com> wrote:
>>> I'll have to check it out...Actually, I'm going to check it out right >>> after this email!
>>> I've been using the ResourceSelector from the SL Extensions<http://slextensions.net/showcase.aspx#Page=20>, >>> which is a simple, but very powerful class. Totally makes up for the fact >>> there are no typed datatemplates.
>>> So essentially, I have a VM with a property called CurrentViewModel, of >>> my ViewModelBase type. I just have content control bind it's content to >>> this property, and bind the ContentTemplate to a DataTemplate that uses the >>> ResourceSelector. This way, whatever .NET type my VM is, the View will pick >>> the right datatemplate...just like WPF. Here is the XAML for it. The >>> "x:Key="LoginViewModel", LoginViewModel is the name of my ViewModel type. >>> It also supports the type FullName if you really need.
>>> On Mon, Dec 1, 2008 at 2:52 PM, Laurent Bugnion, GalaSoft [MVP] >>> <laur...@galasoft.ch> wrote:
>>>> Jer, using the Silverlight toolkit you can now define implicit styles >>>> so I *suppose* (but I didn't try it) that you could also use the >>>> ImplicitStyleManager to define a View for a given view model type… >>>> interesting thought, I have to try that… tomorrow. ;)
>>>> *From:* wpf-disciples@googlegroups.com [mailto: >>>> wpf-disciples@googlegroups.com] *On Behalf Of *Jeremiah Morrill >>>> *Sent:* Monday, December 01, 2008 11:02 PM
>>>> *To:* wpf-disciples@googlegroups.com >>>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >>>> for ValueConverters
>>>> Josh,
>>>> Crack.NET has been one of my bases of learning MVVM. I think the typed >>>> datatemplate resources feel very natural and lets the View be as only >>>> intelligent as it needs to be. As you remember, this is where I was sorta >>>> getting pattern gun-shy in SL, given lack of built in support. At this >>>> moment, I'm a proponent of the ViewModel-data/type-driven View which you >>>> mentioned here. Before, in SL, I was initializing the VM in the codebehind >>>> and clearly it was more spaghettified if my goal was to *fly the whole >>>> plane *from the VM.
>>>> As far as ValueConverters go, I would say I'm guilty of having my VM >>>> pander the View a little bit. I would also add that I don't enjoy making >>>> VCs that much...but just like home-owners-associations, they are a necessary >>>> evil. Most cases I would assume it's fine to have View friendly >>>> properties...but when you start getting over run by redundant properties (in >>>> other formats) is when I may consider a VC.
>>>> Just my 2cents as a newbie ;). It does feel good to be able to follow >>>> these conversations now though...
>>>> -Jer
>>>> On Mon, Dec 1, 2008 at 12:55 PM, Josh Smith <flappleja...@gmail.com> >>>> wrote:
>>>> Great feedback, Laurent. Looking forward to your upcoming blog post >>>> about your experience with taking other approaches. ;)
>>>> I sense that I'm the odd man out in this discussion. I'm very curious >>>> to know what concrete advantages others have gained by treating the VM as >>>> something clearly distinct and separate from the View. What do you really >>>> gain from using value converters and code-behind logic, as opposed to >>>> putting that stuff into the VM? I'm not opposed to that approach, it's just >>>> not how I've done MVVM so far. While working on Crack.NET I created very >>>> dumb, passive Views and smart, demanding ViewModels. I know that the good >>>> Doctor is quite versed in MVVM, and has reviewed the Crack code, so I'd love >>>> to hear his thoughts on this.
>>>> josh
>>>> On Mon, Dec 1, 2008 at 3:31 PM, Laurent Bugnion, GalaSoft [MVP] >>>> <laur...@galasoft.ch> wrote:
>>>> I want to chime in on that one.
>>>> Yes, patterns are guidelines more than rules. I followed that discussion >>>> with very much interest and can't wait to try some of that in my next app, >>>> and it's really interesting to see the different streams of thoughts. So far >>>> I think I see two major variations in the exposed practices, one which >>>> considers that VM is a kind of replacement for code-behind (let's call it a >>>> top-down approach) and thus a VM is very tightly bound to a View. The other >>>> is rather a bottom-up approach and puts the VM as an extension of the model, >>>> but formatted for the View.
>>>> In the project I worked last, we took a very pragmatic approach, and >>>> used VM for various reasons, the most important being avoiding that our >>>> designers have to write any code. Josh's point is really valid, designers >>>> should not have to worry about code, period. It's not their job. My role as >>>> an integrator (IM calls that "Interactive Developer") was to specifically >>>> avoid designers to have that kind of problems. This results in a series of >>>> roundtrips between developers and designers coordinated by the integrator. >>>> In that sense, a well thought VM can avoid a number of roundtrips. To me, >>>> this is the most important aspect of the VM, because every roundtrip costs a >>>> lot of money, and designers are damn expensive in a project.
>>>> When I say we were pragmatic, I mean that because some in the team were >>>> quite unexperienced, we ended up having quite some code in the code-behind. >>>> If I had to do it again today, I would probably be stricter about that. But >>>> on the other hand, I saw another team take a much stricter approach (Josh: >>>> That was Linus' team, you probably remember him from our memorable dinner in >>>> NY) and they spent a lot more time on some details than we did. Also, some >>>> of the development was done in India, and their strict approach cost quite a >>>> lot of time round tripping between India and Switzerland, or worse, having >>>> to refactor much of the code that the Indian team delivered.
>>>> Anyway… my next project should be a much smaller one (Silverlight), and >>>> I want to apply MVVM in a stricter way there. That should be interesting >>>> J
>>>> *From:* wpf-disciples@googlegroups.com [mailto: >>>> wpf-disciples@googlegroups.com] *On Behalf Of *Josh Smith >>>> *Sent:* Monday, December 01, 2008 9:03 PM
>>>> *To:* wpf-disciples@googlegroups.com >>>> *Subject:* [WPF Disciples] Re: Thought: MVVM eliminates 99% of the need >>>> for ValueConverters
>>>> Suppose you're working in the designer-developer workflow. Should the >>>> designers have to write the value converters? What if they don't know how >>>> to write some of them? I think it's easier to have the VM expose the >>>> properties that they need to bind against, instead of having the designers >>>> ask the developers to write a bunch of one-off converters for them.
>>>> At the end of the day, MVVM (like any other pattern) is a set of >>>> guidelines, not rules. So, as long as using the pattern makes your >>>> application better, development easier, and testing more thorough, it's all >>>> good.
>>>> Josh
>>>> On Mon, Dec 1, 2008 at 2:54 PM, Corrado Cavalli <
