I haven't written anything about MVVM in a while because there is so much material already being published. However I have been thinking about what we can do in the platform to make things better and reading a lot of the public stuff, so I thought I'd summarize for my own sake if nothing else:
The state of MVVM reminds me of Peter Naur's classic paper "Programming as Theory Building". He basically says the proper model for computer programming is not engineering but scientific development where you have problem, you develop a hypothesis for how to fix it, you experiment (write code and test it), and then you decide whether you've solved the problem. If not you synthesize a new hypothesis and try again.
MVVM feels more like "science" than anything else I've seen...with lots of authors publishing papers containing their hypotheses and results and suggesting avenues for further research. Some papers are better than others, some are revolutionary and some contain nothing new.
Fundamentally I think the goal of MVVM has still not been clearly stated. I posit some of the goals include: 1) efficiently write rich UI 2) where the code is maintainable 3) the model never needs to be changed to support changes to the view 4) the viewmodel rarely if ever needs to be changed to support changes to the view 5) there can be many views of the same viewmodel 6) the design is as toolable as possible.
To my mind #6 is the most important and perhaps the one we still have made the least progress with. Blend Behaviors are a huge step in the right direction, but we need to go further.
I don't think eliminating all code from the View is part of the goal, though it obviously makes some of the others easier. When it makes them harder though, one should write view code (though whether that means the code behind model or something else is not clear).
Among the next steps, I would like to eliminate the boilerplate code for INotifyPropertyChanged (and eventually eliminate DependencyProperties and DependencyObjects and allow any property on any class to support binding and change notification). Further I would like to bind events in the View directly to Commands on the ViewModel so you can say <Button Click="{Binding SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>. This leads to the question whether ICommand itself is just boilerplate and we can simply remove it with binding directly to methods. The downside being it isn't clear all methods can/should be called from the View in which case it may be useful to have contract (currently offered by the list of properties of type ICommand). On the tooling side I would like to see a UI where you can select a control, see a list of the events it supports and choose which methods on the ViewModel you want them to trigger. This leads in turn to how to handle event arguments like keys. Keybinding is already pretty good, but the syntax should be simple.
On Mon, Feb 1, 2010 at 2:09 PM, John Gossman <gossmans...@gmail.com> wrote: > 6) the design is as toolable as possible.
> To my mind #6 is the most important and perhaps the one we still have made > the least progress with. Blend Behaviors are a huge step in the right > direction, but we need to go further.
This observation is spot on, IMHO.
> I don't think eliminating all code from the View is part of the goal, though > it obviously makes some of the others easier. When it makes them harder > though, one should write view code (though whether that means the code > behind model or something else is not clear).
This one touches on some religious debates. The pragmatist in me agrees entirely, and I write my share of View code (both code behind and "something else" in the form of markup extensions, converters, etc.). However, I still think one of the goals should be to eliminate, as much as possible, the need for View code. View code in all it's forms causes friction for designers. I don't think it's possible to entirely eliminate the need for View code, but simply leaving it out as a goal seems wrong.
> Among the next steps, I would like to eliminate the boilerplate code for > INotifyPropertyChanged (and eventually eliminate DependencyProperties and > DependencyObjects and allow any property on any class to support binding and > change notification).
Wow! I can just imagine the abuse of being able to databind anything to anything. :) Elimination of the INPC boilerplate has been the holy grail of MVVM devs, but I'm fairly convinced this can't be done at the library level. AOP solutions work, but the costs incurred with this approach are too steep for many. I'd love to see some language support here.
> Further I would like to bind events in the View > directly to Commands on the ViewModel so you can say <Button Click="{Binding > SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>.
Why commands? What does a command give you in the MouseRightButtonUp example? I wouldn't expect the button to be disabled if ShowContextCommand indicates it can't be executed. Most of the time I'd rather bind events to an event handler on the ViewModel. Behaviors can allow us to do this today, with slightly uglier syntax. But since Behaviors are designer friendly, the syntax doesn't matter as much. So I'm not as interested in finding a new solution in this particular problem space.
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
I agree very strongly with Bill's comments. John, I think your post is totally going in the right direction. it would be fantastic if the "tricks" proposed by libraries such as my toolkit would disappear eventually because they are not needed anymore.
- Replacing RelayCommand with binding to methods would be cool though I do not mind commands that much. I like to be able to create a simple CanExecute lambda. - Ability to bind any event to a command: Agreed. I never quite understood this restriction actually. I propose a behavior called EventToCommand to bridge that gap. The user can choose to have CanExecute evaluated or not, this is simply a property of the EventToCommand behavior.Something like that could be done with a Binding to a command too, not so much to a method. - Removing the INPC boilerplate, oh yeah... For now all the solutions I saw to that didn't really convince me, apart maybe from Justin's MSIL weaving which should really be built in the framework to start with.
So yeah, I am really pleased by this email and would love to see that happening.
On Behalf Of Bill Kempf Sent: Monday, February 01, 2010 8:31 PM To: wpf-disciples@googlegroups.com Subject: Re: [WPF Disciples] State of MVVM
On Mon, Feb 1, 2010 at 2:09 PM, John Gossman <gossmans...@gmail.com> wrote: > 6) the design is as toolable as possible.
> To my mind #6 is the most important and perhaps the one we still have made > the least progress with. Blend Behaviors are a huge step in the right > direction, but we need to go further.
This observation is spot on, IMHO.
> I don't think eliminating all code from the View is part of the goal, though > it obviously makes some of the others easier. When it makes them harder > though, one should write view code (though whether that means the code > behind model or something else is not clear).
This one touches on some religious debates. The pragmatist in me agrees entirely, and I write my share of View code (both code behind and "something else" in the form of markup extensions, converters, etc.). However, I still think one of the goals should be to eliminate, as much as possible, the need for View code. View code in all it's forms causes friction for designers. I don't think it's possible to entirely eliminate the need for View code, but simply leaving it out as a goal seems wrong.
> Among the next steps, I would like to eliminate the boilerplate code for > INotifyPropertyChanged (and eventually eliminate DependencyProperties and > DependencyObjects and allow any property on any class to support binding and > change notification).
Wow! I can just imagine the abuse of being able to databind anything to anything. :) Elimination of the INPC boilerplate has been the holy grail of MVVM devs, but I'm fairly convinced this can't be done at the library level. AOP solutions work, but the costs incurred with this approach are too steep for many. I'd love to see some language support here.
> Further I would like to bind events in the View > directly to Commands on the ViewModel so you can say <Button Click="{Binding > SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>.
Why commands? What does a command give you in the MouseRightButtonUp example? I wouldn't expect the button to be disabled if ShowContextCommand indicates it can't be executed. Most of the time I'd rather bind events to an event handler on the ViewModel. Behaviors can allow us to do this today, with slightly uglier syntax. But since Behaviors are designer friendly, the syntax doesn't matter as much. So I'm not as interested in finding a new solution in this particular problem space.
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
> I agree very strongly with Bill's comments. John, I think your post is > totally going in the right direction. it would be fantastic if the "tricks" > proposed by libraries such as my toolkit would disappear eventually because > they are not needed anymore.
> - Replacing RelayCommand with binding to methods would be cool though I do > not mind commands that much. I like to be able to create a simple > CanExecute > lambda. > - Ability to bind any event to a command: Agreed. I never quite understood > this restriction actually. I propose a behavior called EventToCommand to > bridge that gap. The user can choose to have CanExecute evaluated or not, > this is simply a property of the EventToCommand behavior.Something like > that > could be done with a Binding to a command too, not so much to a method. > - Removing the INPC boilerplate, oh yeah... For now all the solutions I saw > to that didn't really convince me, apart maybe from Justin's MSIL weaving > which should really be built in the framework to start with.
> So yeah, I am really pleased by this email and would love to see that > happening.
> Cheers, > Laurent
> -----Original Message----- > From: wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] > On Behalf Of Bill Kempf > Sent: Monday, February 01, 2010 8:31 PM > To: wpf-disciples@googlegroups.com > Subject: Re: [WPF Disciples] State of MVVM
> On Mon, Feb 1, 2010 at 2:09 PM, John Gossman <gossmans...@gmail.com> > wrote: > > 6) the design is as toolable as possible.
> > To my mind #6 is the most important and perhaps the one we still have > made > > the least progress with. Blend Behaviors are a huge step in the right > > direction, but we need to go further.
> This observation is spot on, IMHO.
> > I don't think eliminating all code from the View is part of the goal, > though > > it obviously makes some of the others easier. When it makes them harder > > though, one should write view code (though whether that means the code > > behind model or something else is not clear).
> This one touches on some religious debates. The pragmatist in me > agrees entirely, and I write my share of View code (both code behind > and "something else" in the form of markup extensions, converters, > etc.). However, I still think one of the goals should be to eliminate, > as much as possible, the need for View code. View code in all it's > forms causes friction for designers. I don't think it's possible to > entirely eliminate the need for View code, but simply leaving it out > as a goal seems wrong.
> > Among the next steps, I would like to eliminate the boilerplate code for > > INotifyPropertyChanged (and eventually eliminate DependencyProperties and > > DependencyObjects and allow any property on any class to support binding > and > > change notification).
> Wow! I can just imagine the abuse of being able to databind anything > to anything. :) Elimination of the INPC boilerplate has been the holy > grail of MVVM devs, but I'm fairly convinced this can't be done at the > library level. AOP solutions work, but the costs incurred with this > approach are too steep for many. I'd love to see some language support > here.
> > Further I would like to bind events in the View > > directly to Commands on the ViewModel so you can say <Button > Click="{Binding > > SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>.
> Why commands? What does a command give you in the MouseRightButtonUp > example? I wouldn't expect the button to be disabled if > ShowContextCommand indicates it can't be executed. Most of the time > I'd rather bind events to an event handler on the ViewModel. > Behaviors can allow us to do this today, with slightly uglier syntax. > But since Behaviors are designer friendly, the syntax doesn't matter > as much. So I'm not as interested in finding a new solution in this > particular problem space.
> -- > Quidquid latine dictum sit, altum sonatur. > - Whatever is said in Latin sounds profound.
> War is peace. Freedom is slavery. Bugs are features.
There are already several event to command behaviors out there that show it works. And it's blendable, just drag the behavior to whatever object, set the event and name the command. I agree wholeheartedly with what John says though. It seems we have forgotten the "science" in computer science and like to pretend like we are a bunch of magicians summoning mythical creatures with mystic incantations. In reality, we're repeating a lot of the same efforts and the industry is moving much slower than other sciences because we don't take a scientific approach to our work.
This is one of the first steps that need to be taken if our chosen career is going to be taken seriously as a profession. It's something I feel strongly about because quite frankly, I get tired of people who don't know dictating how my job should be performed. You don't see patients telling doctors how long a triple bypass surgery should take. Why are people who are asking our expertise dictating the terms and conditions under which we should perform our craft? Software engineering should not be commoditized on an hourly basis, because there is a lot more value than can be justified in an hourly rate being provided by a good engineer.
I get tired of reading the same thing proposed by someone else 10 years ago being presented as some new and radical idea by someone who either didn't take the time to do his research or is an outright fraud and plagiarist. I especially get tired of the band of merry men that take up this new banner after reading ten sentences from said person's book treating it as the ten commandments of software development.
I get tired of "Teach yourself "X" in a nutshell for dummies in 24 hours" books because they belittle our industry. Again, you don't see "Brain Surgery for Dummies" or "Teach yourself particle physics in 24 hours". I have poured my lifetime into learning my craft. And I dare anyone to pick up a book, read it, and try to do what I do better than me. Just like I'm not going to pick up "Hal Leonard's Guitar Method" and suddenly be on equal footing with Jon Mayer as a guitarist.
Anyway, I'm glad to see discussion around concepts such as MVVM because as John mentioned, it feels like a step in the right direction. For WPF and for the industry as a whole.
On Behalf Of Laurent Bugnion, GalaSoft Sent: Monday, February 01, 2010 2:51 PM To: wpf-disciples@googlegroups.com Subject: RE: [WPF Disciples] State of MVVM
Hey,
I agree very strongly with Bill's comments. John, I think your post is totally going in the right direction. it would be fantastic if the "tricks" proposed by libraries such as my toolkit would disappear eventually because they are not needed anymore.
- Replacing RelayCommand with binding to methods would be cool though I do not mind commands that much. I like to be able to create a simple CanExecute lambda. - Ability to bind any event to a command: Agreed. I never quite understood this restriction actually. I propose a behavior called EventToCommand to bridge that gap. The user can choose to have CanExecute evaluated or not, this is simply a property of the EventToCommand behavior.Something like that could be done with a Binding to a command too, not so much to a method. - Removing the INPC boilerplate, oh yeah... For now all the solutions I saw to that didn't really convince me, apart maybe from Justin's MSIL weaving which should really be built in the framework to start with.
So yeah, I am really pleased by this email and would love to see that happening.
Cheers, Laurent
-----Original Message----- From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Bill Kempf Sent: Monday, February 01, 2010 8:31 PM To: wpf-disciples@googlegroups.com Subject: Re: [WPF Disciples] State of MVVM
On Mon, Feb 1, 2010 at 2:09 PM, John Gossman <gossmans...@gmail.com> wrote: > 6) the design is as toolable as possible.
> To my mind #6 is the most important and perhaps the one we still have > made the least progress with. Blend Behaviors are a huge step in the > right direction, but we need to go further.
This observation is spot on, IMHO.
> I don't think eliminating all code from the View is part of the goal, though > it obviously makes some of the others easier. When it makes them > harder though, one should write view code (though whether that means > the code behind model or something else is not clear).
This one touches on some religious debates. The pragmatist in me agrees entirely, and I write my share of View code (both code behind and "something else" in the form of markup extensions, converters, etc.). However, I still think one of the goals should be to eliminate, as much as possible, the need for View code. View code in all it's forms causes friction for designers. I don't think it's possible to entirely eliminate the need for View code, but simply leaving it out as a goal seems wrong.
> Among the next steps, I would like to eliminate the boilerplate code > for INotifyPropertyChanged (and eventually eliminate > DependencyProperties and DependencyObjects and allow any property on > any class to support binding and > change notification).
Wow! I can just imagine the abuse of being able to databind anything to anything. :) Elimination of the INPC boilerplate has been the holy grail of MVVM devs, but I'm fairly convinced this can't be done at the library level. AOP solutions work, but the costs incurred with this approach are too steep for many. I'd love to see some language support here.
> Further I would like to bind events in the View directly to Commands >on the ViewModel so you can say <Button Click="{Binding > SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>.
Why commands? What does a command give you in the MouseRightButtonUp example? I wouldn't expect the button to be disabled if ShowContextCommand indicates it can't be executed. Most of the time I'd rather bind events to an event handler on the ViewModel. Behaviors can allow us to do this today, with slightly uglier syntax. But since Behaviors are designer friendly, the syntax doesn't matter as much. So I'm not as interested in finding a new solution in this particular problem space.
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
Our job is much more ethereal than your average science. There's nothing anyone can look at, feel, or take apart that makes them realize "oh wow, there's a lot to this stuff!" In fact, I find that the better we do at our job, the simpler the final product looks to anyone on the outside. This fact alone makes things much, much more difficult for us when it comes to wanting to do things right vs. git 'er done. An outsider would have a great deal of difficulty grasping the difference, whereas the difference between a professional musician doing things right (no comment on Jon Mayer ;) ) vs. an amateur just stringing some notes together is obvious to everyone.
That said, I haven't heard of anyone that doesn't take our profession seriously...
I do find it astonishing how frequently the wheel seems to get reinvented, and it does seem lazy/plagiaristic/uninformed at times, but it's insightful to cast the problem in terms of more physical sciences. At a high level, it would seem that the problem of roads, bridges, and sidewalks has long been solved, so why do colleges continue to churn out civil engineers who, then, mysteriously are able to find jobs? The issue is that although higher-order theory and concepts may be common to all roads/bridges/sidewalks, the application of the theories and patterns to a particular situation will be extraordinarily complex and nuanced in a way that needs special attention and decisions to be made in each individual case. Ordinary people respect this because they can see the details without needing an educated understanding... the effects of extreme heat/cold, weight tolerances, erosion, weathering, embankments, etc.
Likewise for computer scientists, many patterns and practices have been well documented and are well understood, but the application of these to a particular project will contain myriad hairy details that need hashing out, and so you'll see lots of similar solutions to the same fundamental problem applied to subtly different situations. But because these details are not *visible*, your average Joe thinks along the lines of (recasting as civil engineer) "Why are you taking so long to design this bridge? Haven't, like, thousands of bridges been made before? Just copy one of them and be done with it!" That kind of unreasonable pressure will lend itself to "teach yourself XYZ in 24 hours!" things, all in the name of just getting through a problem, rather than developing a real understanding of it.
It's an interesting challenge for us, but like I said, in my experience we are definitely taken seriously; I even detect a hint of fear from some people. For me the biggest hurdle is being realistic with myself about how complex things are, and then communicating that to the people who have no way of knowing any more than what I tell them.
-----Original Message----- From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Michael D. Brown Sent: Monday, February 01, 2010 12:38 PM To: wpf-disciples@googlegroups.com Subject: RE: [WPF Disciples] State of MVVM
There are already several event to command behaviors out there that show it works. And it's blendable, just drag the behavior to whatever object, set the event and name the command. I agree wholeheartedly with what John says though. It seems we have forgotten the "science" in computer science and like to pretend like we are a bunch of magicians summoning mythical creatures with mystic incantations. In reality, we're repeating a lot of the same efforts and the industry is moving much slower than other sciences because we don't take a scientific approach to our work.
This is one of the first steps that need to be taken if our chosen career is going to be taken seriously as a profession. It's something I feel strongly about because quite frankly, I get tired of people who don't know dictating how my job should be performed. You don't see patients telling doctors how long a triple bypass surgery should take. Why are people who are asking our expertise dictating the terms and conditions under which we should perform our craft? Software engineering should not be commoditized on an hourly basis, because there is a lot more value than can be justified in an hourly rate being provided by a good engineer.
I get tired of reading the same thing proposed by someone else 10 years ago being presented as some new and radical idea by someone who either didn't take the time to do his research or is an outright fraud and plagiarist. I especially get tired of the band of merry men that take up this new banner after reading ten sentences from said person's book treating it as the ten commandments of software development.
I get tired of "Teach yourself "X" in a nutshell for dummies in 24 hours" books because they belittle our industry. Again, you don't see "Brain Surgery for Dummies" or "Teach yourself particle physics in 24 hours". I have poured my lifetime into learning my craft. And I dare anyone to pick up a book, read it, and try to do what I do better than me. Just like I'm not going to pick up "Hal Leonard's Guitar Method" and suddenly be on equal footing with Jon Mayer as a guitarist.
Anyway, I'm glad to see discussion around concepts such as MVVM because as John mentioned, it feels like a step in the right direction. For WPF and for the industry as a whole.
--Mike
-----Original Message----- From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Laurent Bugnion, GalaSoft Sent: Monday, February 01, 2010 2:51 PM To: wpf-disciples@googlegroups.com Subject: RE: [WPF Disciples] State of MVVM
Hey,
I agree very strongly with Bill's comments. John, I think your post is totally going in the right direction. it would be fantastic if the "tricks" proposed by libraries such as my toolkit would disappear eventually because they are not needed anymore.
- Replacing RelayCommand with binding to methods would be cool though I do not mind commands that much. I like to be able to create a simple CanExecute lambda. - Ability to bind any event to a command: Agreed. I never quite understood this restriction actually. I propose a behavior called EventToCommand to bridge that gap. The user can choose to have CanExecute evaluated or not, this is simply a property of the EventToCommand behavior.Something like that could be done with a Binding to a command too, not so much to a method. - Removing the INPC boilerplate, oh yeah... For now all the solutions I saw to that didn't really convince me, apart maybe from Justin's MSIL weaving which should really be built in the framework to start with.
So yeah, I am really pleased by this email and would love to see that happening.
Cheers, Laurent
-----Original Message----- From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Bill Kempf Sent: Monday, February 01, 2010 8:31 PM To: wpf-disciples@googlegroups.com Subject: Re: [WPF Disciples] State of MVVM
On Mon, Feb 1, 2010 at 2:09 PM, John Gossman <gossmans...@gmail.com> wrote: > 6) the design is as toolable as possible.
> To my mind #6 is the most important and perhaps the one we still have > made the least progress with. Blend Behaviors are a huge step in the > right direction, but we need to go further.
This observation is spot on, IMHO.
> I don't think eliminating all code from the View is part of the goal, though > it obviously makes some of the others easier. When it makes them > harder though, one should write view code (though whether that means > the code behind model or something else is not clear).
This one touches on some religious debates. The pragmatist in me agrees entirely, and I write my share of View code (both code behind and "something else" in the form of markup extensions, converters, etc.). However, I still think one of the goals should be to eliminate, as much as possible, the need for View code. View code in all it's forms causes friction for designers. I don't think it's possible to entirely eliminate the need for View code, but simply leaving it out as a goal seems wrong.
> Among the next steps, I would like to eliminate the boilerplate code > for INotifyPropertyChanged (and eventually eliminate > DependencyProperties and DependencyObjects and allow any property on > any class to support binding and > change notification).
Wow! I can just imagine the abuse of being able to databind anything to anything. :) Elimination of the INPC boilerplate has been the holy grail of MVVM devs, but I'm fairly convinced this can't be done at the library level. AOP solutions work, but the costs incurred with this approach are too steep for many. I'd love to see some language support here.
> Further I would like to bind events in the View directly to Commands >on the ViewModel so you can say <Button Click="{Binding > SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>.
Why commands? What does a command give you in the MouseRightButtonUp example? I wouldn't expect the button to be disabled if ShowContextCommand indicates it can't be executed. Most of the time I'd rather bind events to an event handler on the ViewModel. Behaviors can allow us to do this today, with slightly uglier syntax. But since Behaviors are designer friendly, the syntax doesn't matter as much. So I'm not as interested in finding a new solution in this particular problem space.
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
> > Among the next steps, I would like to eliminate the boilerplate code for > > INotifyPropertyChanged (and eventually eliminate DependencyProperties and > > DependencyObjects and allow any property on any class to support binding and > > change notification).
> Wow! I can just imagine the abuse of being able to databind anything > to anything. :) Elimination of the INPC boilerplate has been the holy > grail of MVVM devs, but I'm fairly convinced this can't be done at the > library level. AOP solutions work, but the costs incurred with this > approach are too steep for many. I'd love to see some language support > here.
Elimination of INPC boiler plate code is the holy grail of MVVM? This one has always baffled me. Yes, it is repetitive boiler plate code, but it doesn't take that long to rivet those plates into place. Seriously, how much of your time do you spend on INPC implementation? And how often have you been handed a bug that was due to incorrect INPC implementation?
If it's boiler plate code you want to eliminate, I'd go for DPs. I think every dev understands how INPC works, but for newcomers to WPF/ Silverlight DPs are something of a dark art. The peculiar relationship between DPs and XAML, does my CLR wrapper get called? If I don't write a CLR wrapper is it a real DP? Can I add logic to CLR wrappers? What's all this metadata about? Does it have to be called FooProperty?
Agreed, language support for INPC would be nice, but language support for DPs would be a whole lot nicer!
MVVM is in a funny state at the moment. A lot of energy, a lot of great ideas and individuality. There is a very interesting, recent post, on the Silverlight forums about MVVM:
The same guy posted pretty much the same rant some time ago. I replied and an interesting discussion ensued, but now I cannot find the thread anymore. Now he comes back with the same message. Honestly if I were that desperate, I would choose another job. I hear that there is no MVVM in PHP. Or, if coding is just too tough, we need people to shovel snow around here.
Coding is hard, boohoo. This falcon guy reminds me so much of some of my coworkers before I moved to IdentityMine (one in particular), who would look in disdain at anything new. How that coworker managed to crawl out of his C++ hole to learn C# is beyond me. I have less patience these days for that attitude. The falcon guy complained that "architects are forcing him to apply that pattern". This was months ago. Dude, if you don't like what the architects are telling you, propose a better architecture. And if the architects are too obtuse to take constructive feedback, then there are many jobs out there for qualified developers. I should know, I get about 1 offer per week these days. So what is the problem, really?
On Behalf Of Colin Eberhardt Sent: Monday, February 01, 2010 11:18 PM To: WPF Disciples Subject: [WPF Disciples] Re: State of MVVM
> > Among the next steps, I would like to eliminate the boilerplate code for > > INotifyPropertyChanged (and eventually eliminate DependencyProperties and > > DependencyObjects and allow any property on any class to support binding and > > change notification).
> Wow! I can just imagine the abuse of being able to databind anything > to anything. :) Elimination of the INPC boilerplate has been the holy > grail of MVVM devs, but I'm fairly convinced this can't be done at the > library level. AOP solutions work, but the costs incurred with this > approach are too steep for many. I'd love to see some language support > here.
Elimination of INPC boiler plate code is the holy grail of MVVM? This one has always baffled me. Yes, it is repetitive boiler plate code, but it doesn't take that long to rivet those plates into place. Seriously, how much of your time do you spend on INPC implementation? And how often have you been handed a bug that was due to incorrect INPC implementation?
If it's boiler plate code you want to eliminate, I'd go for DPs. I think every dev understands how INPC works, but for newcomers to WPF/ Silverlight DPs are something of a dark art. The peculiar relationship between DPs and XAML, does my CLR wrapper get called? If I don't write a CLR wrapper is it a real DP? Can I add logic to CLR wrappers? What's all this metadata about? Does it have to be called FooProperty?
Agreed, language support for INPC would be nice, but language support for DPs would be a whole lot nicer!
MVVM is in a funny state at the moment. A lot of energy, a lot of great ideas and individuality. There is a very interesting, recent post, on the Silverlight forums about MVVM:
On Behalf Of Laurent Bugnion, GalaSoft Sent: Monday, February 01, 2010 11:49 PM To: wpf-disciples@googlegroups.com Subject: RE: [WPF Disciples] Re: State of MVVM
[Moving to private]
The same guy posted pretty much the same rant some time ago. I replied and an interesting discussion ensued, but now I cannot find the thread anymore. Now he comes back with the same message. Honestly if I were that desperate, I would choose another job. I hear that there is no MVVM in PHP. Or, if coding is just too tough, we need people to shovel snow around here.
Coding is hard, boohoo. This falcon guy reminds me so much of some of my coworkers before I moved to IdentityMine (one in particular), who would look in disdain at anything new. How that coworker managed to crawl out of his C++ hole to learn C# is beyond me. I have less patience these days for that attitude. The falcon guy complained that "architects are forcing him to apply that pattern". This was months ago. Dude, if you don't like what the architects are telling you, propose a better architecture. And if the architects are too obtuse to take constructive feedback, then there are many jobs out there for qualified developers. I should know, I get about 1 offer per week these days. So what is the problem, really?
Wow that felt good.
Cheers, Laurent
-----Original Message----- From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Colin Eberhardt Sent: Monday, February 01, 2010 11:18 PM To: WPF Disciples Subject: [WPF Disciples] Re: State of MVVM
> > Among the next steps, I would like to eliminate the boilerplate code for > > INotifyPropertyChanged (and eventually eliminate DependencyProperties and > > DependencyObjects and allow any property on any class to support binding and > > change notification).
> Wow! I can just imagine the abuse of being able to databind anything > to anything. :) Elimination of the INPC boilerplate has been the holy > grail of MVVM devs, but I'm fairly convinced this can't be done at the > library level. AOP solutions work, but the costs incurred with this > approach are too steep for many. I'd love to see some language support > here.
Elimination of INPC boiler plate code is the holy grail of MVVM? This one has always baffled me. Yes, it is repetitive boiler plate code, but it doesn't take that long to rivet those plates into place. Seriously, how much of your time do you spend on INPC implementation? And how often have you been handed a bug that was due to incorrect INPC implementation?
If it's boiler plate code you want to eliminate, I'd go for DPs. I think every dev understands how INPC works, but for newcomers to WPF/ Silverlight DPs are something of a dark art. The peculiar relationship between DPs and XAML, does my CLR wrapper get called? If I don't write a CLR wrapper is it a real DP? Can I add logic to CLR wrappers? What's all this metadata about? Does it have to be called FooProperty?
Agreed, language support for INPC would be nice, but language support for DPs would be a whole lot nicer!
MVVM is in a funny state at the moment. A lot of energy, a lot of great ideas and individuality. There is a very interesting, recent post, on the Silverlight forums about MVVM:
laur...@galasoft.ch> wrote: > And yes I forgot to actually move it to private LOL Never rant while > writing > a book, people.
> Oh well. It had to be said :)
> -----Original Message----- > From: wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] > On Behalf Of Laurent Bugnion, GalaSoft > Sent: Monday, February 01, 2010 11:49 PM > To: wpf-disciples@googlegroups.com > Subject: RE: [WPF Disciples] Re: State of MVVM
> [Moving to private]
> The same guy posted pretty much the same rant some time ago. I replied and > an interesting discussion ensued, but now I cannot find the thread anymore. > Now he comes back with the same message. Honestly if I were that desperate, > I would choose another job. I hear that there is no MVVM in PHP. Or, if > coding is just too tough, we need people to shovel snow around here.
> Coding is hard, boohoo. This falcon guy reminds me so much of some of my > coworkers before I moved to IdentityMine (one in particular), who would > look > in disdain at anything new. How that coworker managed to crawl out of his > C++ hole to learn C# is beyond me. I have less patience these days for that > attitude. The falcon guy complained that "architects are forcing him to > apply that pattern". This was months ago. Dude, if you don't like what the > architects are telling you, propose a better architecture. And if the > architects are too obtuse to take constructive feedback, then there are > many > jobs out there for qualified developers. I should know, I get about 1 offer > per week these days. So what is the problem, really?
> Wow that felt good.
> Cheers, > Laurent
> -----Original Message----- > From: wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] > On Behalf Of Colin Eberhardt > Sent: Monday, February 01, 2010 11:18 PM > To: WPF Disciples > Subject: [WPF Disciples] Re: State of MVVM
> > > Among the next steps, I would like to eliminate the boilerplate code > for > > > INotifyPropertyChanged (and eventually eliminate DependencyProperties > and > > > DependencyObjects and allow any property on any class to support > binding > and > > > change notification).
> > Wow! I can just imagine the abuse of being able to databind anything > > to anything. :) Elimination of the INPC boilerplate has been the holy > > grail of MVVM devs, but I'm fairly convinced this can't be done at the > > library level. AOP solutions work, but the costs incurred with this > > approach are too steep for many. I'd love to see some language support > > here.
> Elimination of INPC boiler plate code is the holy grail of MVVM? This > one has always baffled me. Yes, it is repetitive boiler plate code, > but it doesn't take that long to rivet those plates into place. > Seriously, how much of your time do you spend on INPC implementation? > And how often have you been handed a bug that was due to incorrect > INPC implementation?
> If it's boiler plate code you want to eliminate, I'd go for DPs. I > think every dev understands how INPC works, but for newcomers to WPF/ > Silverlight DPs are something of a dark art. The peculiar relationship > between DPs and XAML, does my CLR wrapper get called? If I don't write > a CLR wrapper is it a real DP? Can I add logic to CLR wrappers? What's > all this metadata about? Does it have to be called FooProperty?
> Agreed, language support for INPC would be nice, but language support > for DPs would be a whole lot nicer!
> MVVM is in a funny state at the moment. A lot of energy, a lot of > great ideas and individuality. There is a very interesting, recent > post, on the Silverlight forums about MVVM:
Wow, 5 months of being unhappy at work. I cannot start to imagine what it must be like.
Cheers,
Laurent
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Jeremiah Morrill Sent: Tuesday, February 02, 2010 1:11 AM To: wpf-disciples@googlegroups.com Subject: Re: [WPF Disciples] Re: State of MVVM
I remember that dude Laurent. He made some valid points about his architects...but now he's just on a crusade.
On Behalf Of Laurent Bugnion, GalaSoft Sent: Monday, February 01, 2010 11:49 PM To: wpf-disciples@googlegroups.com
Subject: RE: [WPF Disciples] Re: State of MVVM
[Moving to private]
The same guy posted pretty much the same rant some time ago. I replied and an interesting discussion ensued, but now I cannot find the thread anymore. Now he comes back with the same message. Honestly if I were that desperate, I would choose another job. I hear that there is no MVVM in PHP. Or, if coding is just too tough, we need people to shovel snow around here.
Coding is hard, boohoo. This falcon guy reminds me so much of some of my coworkers before I moved to IdentityMine (one in particular), who would look in disdain at anything new. How that coworker managed to crawl out of his C++ hole to learn C# is beyond me. I have less patience these days for that attitude. The falcon guy complained that "architects are forcing him to apply that pattern". This was months ago. Dude, if you don't like what the architects are telling you, propose a better architecture. And if the architects are too obtuse to take constructive feedback, then there are many jobs out there for qualified developers. I should know, I get about 1 offer per week these days. So what is the problem, really?
Wow that felt good.
Cheers, Laurent
-----Original Message----- From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Colin Eberhardt Sent: Monday, February 01, 2010 11:18 PM To: WPF Disciples Subject: [WPF Disciples] Re: State of MVVM
> > Among the next steps, I would like to eliminate the boilerplate code for > > INotifyPropertyChanged (and eventually eliminate DependencyProperties and > > DependencyObjects and allow any property on any class to support binding and > > change notification).
> Wow! I can just imagine the abuse of being able to databind anything > to anything. :) Elimination of the INPC boilerplate has been the holy > grail of MVVM devs, but I'm fairly convinced this can't be done at the > library level. AOP solutions work, but the costs incurred with this > approach are too steep for many. I'd love to see some language support > here.
Elimination of INPC boiler plate code is the holy grail of MVVM? This one has always baffled me. Yes, it is repetitive boiler plate code, but it doesn't take that long to rivet those plates into place. Seriously, how much of your time do you spend on INPC implementation? And how often have you been handed a bug that was due to incorrect INPC implementation?
If it's boiler plate code you want to eliminate, I'd go for DPs. I think every dev understands how INPC works, but for newcomers to WPF/ Silverlight DPs are something of a dark art. The peculiar relationship between DPs and XAML, does my CLR wrapper get called? If I don't write a CLR wrapper is it a real DP? Can I add logic to CLR wrappers? What's all this metadata about? Does it have to be called FooProperty?
Agreed, language support for INPC would be nice, but language support for DPs would be a whole lot nicer!
MVVM is in a funny state at the moment. A lot of energy, a lot of great ideas and individuality. There is a very interesting, recent post, on the Silverlight forums about MVVM:
-> Among the next steps, I would like to eliminate the boilerplate code for INotifyPropertyChanged (and eventually eliminate DependencyProperties and DependencyObjects and allow any property on any class to support binding and change notification).
That will be fantastic, but I don't think this will come true in the near future, since Microsoft still has its hard time to implement AOP or other transparent code injection technique in either CLR level (the TP,/ RP stuff is not ideal) or the programming language level, or you guys at MS has any plan for this?
-> MVVM feels more like "science" than anything else I've seen...with lots of authors publishing papers containing their hypotheses and results and suggesting avenues for further research. Some papers are better than others, some are revolutionary and some contain nothing new.
I will regard it as philosophy or even religious belief rather than "science", since most intense / contradictory discussion about UI design pattern is all about the ideological difference in their way of thinking just as the political / ideological difference between Chinese and Americans when it comes to issue of democracy. I will choose whatever it works for me naturally.
-> Wow, 5 months of being unhappy at work. I cannot start to imagine what it must be like.
This is common for me, I seldom feel happy at work, work to me is just a way of earning money to feed my life:)
>> > Among the next steps, I would like to eliminate the boilerplate code for >> > INotifyPropertyChanged (and eventually eliminate DependencyProperties and >> > DependencyObjects and allow any property on any class to support binding and >> > change notification).
>> Wow! I can just imagine the abuse of being able to databind anything >> to anything. :) Elimination of the INPC boilerplate has been the holy >> grail of MVVM devs, but I'm fairly convinced this can't be done at the >> library level. AOP solutions work, but the costs incurred with this >> approach are too steep for many. I'd love to see some language support >> here.
> Elimination of INPC boiler plate code is the holy grail of MVVM? This > one has always baffled me. Yes, it is repetitive boiler plate code, > but it doesn't take that long to rivet those plates into place. > Seriously, how much of your time do you spend on INPC implementation? > And how often have you been handed a bug that was due to incorrect > INPC implementation?
The code is trivial. Hardly worthy of the effort that this interface has been given. So why has it been given so much effort? Because it's fragile. How often have I been handed a bug that was due to incorrect INPC implementation? Way too often. Those stupid magic strings bite me way too often. And considering how many people have tried to fix this problem area, I've got to assume I'm not the only one.
> If it's boiler plate code you want to eliminate, I'd go for DPs. I > think every dev understands how INPC works, but for newcomers to WPF/ > Silverlight DPs are something of a dark art. The peculiar relationship > between DPs and XAML, does my CLR wrapper get called? If I don't write > a CLR wrapper is it a real DP? Can I add logic to CLR wrappers? What's > all this metadata about? Does it have to be called FooProperty?
And yet, despite how much code you have to write to implement a single DP, I've yet to spend any time fixing bugs related to them. Oh, and that boiler plate code is easy to ignore with something as simple as a macro. Not so lucky with INPC.
> Agreed, language support for INPC would be nice, but language support > for DPs would be a whole lot nicer!
Maybe. I don't know, though, I still go back to how often INPC has bitten me.
> MVVM is in a funny state at the moment. A lot of energy, a lot of > great ideas and individuality. There is a very interesting, recent > post, on the Silverlight forums about MVVM:
Haven't read the entire thread, but I must say the original post is pure rubish and ridiculous whining. No one's claimed that MVVM doesn't have some areas where things are actually more difficult to follow the pattern than to not, but his constant harping on "record editing" says more about his understanding of the pattern than it does about the pattern itself.
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
On Behalf Of Colin Eberhardt Sent: Monday, February 01, 2010 5:18 PM To: WPF Disciples Subject: [WPF Disciples] Re: State of MVVM
> > Among the next steps, I would like to eliminate the boilerplate > > code for INotifyPropertyChanged (and eventually eliminate > > DependencyProperties and DependencyObjects and allow any property on > > any class to support binding and change notification).
> Wow! I can just imagine the abuse of being able to databind anything > to anything. :) Elimination of the INPC boilerplate has been the holy > grail of MVVM devs, but I'm fairly convinced this can't be done at the > library level. AOP solutions work, but the costs incurred with this > approach are too steep for many. I'd love to see some language support > here.
Elimination of INPC boiler plate code is the holy grail of MVVM? This one has always baffled me. Yes, it is repetitive boiler plate code, but it doesn't take that long to rivet those plates into place. Seriously, how much of your time do you spend on INPC implementation? And how often have you been handed a bug that was due to incorrect INPC implementation?
If it's boiler plate code you want to eliminate, I'd go for DPs. I think every dev understands how INPC works, but for newcomers to WPF/ Silverlight DPs are something of a dark art. The peculiar relationship between DPs and XAML, does my CLR wrapper get called? If I don't write a CLR wrapper is it a real DP? Can I add logic to CLR wrappers? What's all this metadata about? Does it have to be called FooProperty?
Agreed, language support for INPC would be nice, but language support for DPs would be a whole lot nicer!
MVVM is in a funny state at the moment. A lot of energy, a lot of great ideas and individuality. There is a very interesting, recent post, on the Silverlight forums about MVVM:
BTW, for those exact reasons that this guy whines about is why MVVM is great to me. It makes it easy to isolate the logic that drives your application from the logic that drives your UI. Putting crap like enabling controls when this checkbox is true directly in the code behind is brittle because when the requirements change to "enable this section of the app when the checkbox is true and the value of the publish date is 1970 or earlier" and later changes to "enable this section if the logged in user is an administrator, there's a full moon tonight, and the width of the screen is 800".
The requirements are absurd but that's the great thing. Who gives a damn? You have one place to change that logic and it's all event driven and isolated from the 20 thousand other bits of display logic being juggled around in your UI.
On Behalf Of Michael D. Brown Sent: Monday, February 01, 2010 11:14 PM To: wpf-disciples@googlegroups.com Subject: RE: [WPF Disciples] Re: State of MVVM
On a side note, you guys are referenced up the wazoo on Wikipedia. That's big pimpin'!
-----Original Message----- From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Colin Eberhardt Sent: Monday, February 01, 2010 5:18 PM To: WPF Disciples Subject: [WPF Disciples] Re: State of MVVM
> > Among the next steps, I would like to eliminate the boilerplate > > code for INotifyPropertyChanged (and eventually eliminate > > DependencyProperties and DependencyObjects and allow any property on > > any class to support binding and change notification).
> Wow! I can just imagine the abuse of being able to databind anything > to anything. :) Elimination of the INPC boilerplate has been the holy > grail of MVVM devs, but I'm fairly convinced this can't be done at the > library level. AOP solutions work, but the costs incurred with this > approach are too steep for many. I'd love to see some language support > here.
Elimination of INPC boiler plate code is the holy grail of MVVM? This one has always baffled me. Yes, it is repetitive boiler plate code, but it doesn't take that long to rivet those plates into place. Seriously, how much of your time do you spend on INPC implementation? And how often have you been handed a bug that was due to incorrect INPC implementation?
If it's boiler plate code you want to eliminate, I'd go for DPs. I think every dev understands how INPC works, but for newcomers to WPF/ Silverlight DPs are something of a dark art. The peculiar relationship between DPs and XAML, does my CLR wrapper get called? If I don't write a CLR wrapper is it a real DP? Can I add logic to CLR wrappers? What's all this metadata about? Does it have to be called FooProperty?
Agreed, language support for INPC would be nice, but language support for DPs would be a whole lot nicer!
MVVM is in a funny state at the moment. A lot of energy, a lot of great ideas and individuality. There is a very interesting, recent post, on the Silverlight forums about MVVM:
My vote on this: INPC implementation has never been a problem to me, got some errors due quick renaming but with runtime checking they got spotted immediately, I saw many alternatives, including clever Justin's one but I still prefer the "keep it simple" approach. DPs are instead the black art of WPF/Silverlight, during classes or at customers I keep seeing people that do not understand why they should use a DP and mostly, why in WPF/SL we have such concept. At the end I always suggest them to use Dr.Wpf's snippets but a little help from the language, at least for the most used one: DP+ValueChanged handler would be highly appreciated.
On Behalf Of Colin Eberhardt Sent: lunedì 1 febbraio 2010 23:18 To: WPF Disciples Subject: [WPF Disciples] Re: State of MVVM
> > Among the next steps, I would like to eliminate the boilerplate > > code for INotifyPropertyChanged (and eventually eliminate > > DependencyProperties and DependencyObjects and allow any property on > > any class to support binding and change notification).
> Wow! I can just imagine the abuse of being able to databind anything > to anything. :) Elimination of the INPC boilerplate has been the holy > grail of MVVM devs, but I'm fairly convinced this can't be done at the > library level. AOP solutions work, but the costs incurred with this > approach are too steep for many. I'd love to see some language support > here.
Elimination of INPC boiler plate code is the holy grail of MVVM? This one has always baffled me. Yes, it is repetitive boiler plate code, but it doesn't take that long to rivet those plates into place. Seriously, how much of your time do you spend on INPC implementation? And how often have you been handed a bug that was due to incorrect INPC implementation?
If it's boiler plate code you want to eliminate, I'd go for DPs. I think every dev understands how INPC works, but for newcomers to WPF/ Silverlight DPs are something of a dark art. The peculiar relationship between DPs and XAML, does my CLR wrapper get called? If I don't write a CLR wrapper is it a real DP? Can I add logic to CLR wrappers? What's all this metadata about? Does it have to be called FooProperty?
Agreed, language support for INPC would be nice, but language support for DPs would be a whole lot nicer!
MVVM is in a funny state at the moment. A lot of energy, a lot of great ideas and individuality. There is a very interesting, recent post, on the Silverlight forums about MVVM:
Then you should change work. Where are you located?
Laurent -- Sent from mobile
-original message- Subject: Re: [WPF Disciples] Re: State of MVVM From: Zhou Yong <football...@gmail.com> Date: 02.02.2010 03:24
-> Among the next steps, I would like to eliminate the boilerplate code for INotifyPropertyChanged (and eventually eliminate DependencyProperties and DependencyObjects and allow any property on any class to support binding and change notification).
That will be fantastic, but I don't think this will come true in the near future, since Microsoft still has its hard time to implement AOP or other transparent code injection technique in either CLR level (the TP,/ RP stuff is not ideal) or the programming language level, or you guys at MS has any plan for this?
-> MVVM feels more like "science" than anything else I've seen...with lots of authors publishing papers containing their hypotheses and results and suggesting avenues for further research. Some papers are better than others, some are revolutionary and some contain nothing new.
I will regard it as philosophy or even religious belief rather than "science", since most intense / contradictory discussion about UI design pattern is all about the ideological difference in their way of thinking just as the political / ideological difference between Chinese and Americans when it comes to issue of democracy. I will choose whatever it works for me naturally.
-> Wow, 5 months of being unhappy at work. I cannot start to imagine what it must be like.
This is common for me, I seldom feel happy at work, work to me is just a way of earning money to feed my life:)
All I get out of that guy's post is that he thinks MVVM is for *everything*. I'm guessing he and his bosses have never heard of a template-able control? I think the SilverlightToolkit is using best practices, is testable and there's no MVVM in sight...
Do you guys feel that new-comers to MVVM have a confusion of when to make a View vs. a reusable UI control?
-Jer
On Mon, Feb 1, 2010 at 8:28 PM, Michael D. Brown <mike.br...@azurecoding.net
> wrote: > BTW, for those exact reasons that this guy whines about is why MVVM is > great > to me. It makes it easy to isolate the logic that drives your application > from the logic that drives your UI. Putting crap like enabling controls > when > this checkbox is true directly in the code behind is brittle because when > the requirements change to "enable this section of the app when the > checkbox > is true and the value of the publish date is 1970 or earlier" and later > changes to "enable this section if the logged in user is an administrator, > there's a full moon tonight, and the width of the screen is 800".
> The requirements are absurd but that's the great thing. Who gives a damn? > You have one place to change that logic and it's all event driven and > isolated from the 20 thousand other bits of display logic being juggled > around in your UI.
> -----Original Message----- > From: wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] > On Behalf Of Michael D. Brown > Sent: Monday, February 01, 2010 11:14 PM > To: wpf-disciples@googlegroups.com > Subject: RE: [WPF Disciples] Re: State of MVVM
> On a side note, you guys are referenced up the wazoo on Wikipedia. That's > big pimpin'!
> -----Original Message----- > From: wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] > On Behalf Of Colin Eberhardt > Sent: Monday, February 01, 2010 5:18 PM > To: WPF Disciples > Subject: [WPF Disciples] Re: State of MVVM
> > > Among the next steps, I would like to eliminate the boilerplate > > > code for INotifyPropertyChanged (and eventually eliminate > > > DependencyProperties and DependencyObjects and allow any property on > > > any class to support binding and change notification).
> > Wow! I can just imagine the abuse of being able to databind anything > > to anything. :) Elimination of the INPC boilerplate has been the holy > > grail of MVVM devs, but I'm fairly convinced this can't be done at the > > library level. AOP solutions work, but the costs incurred with this > > approach are too steep for many. I'd love to see some language support > > here.
> Elimination of INPC boiler plate code is the holy grail of MVVM? This one > has always baffled me. Yes, it is repetitive boiler plate code, but it > doesn't take that long to rivet those plates into place. > Seriously, how much of your time do you spend on INPC implementation? > And how often have you been handed a bug that was due to incorrect INPC > implementation?
> If it's boiler plate code you want to eliminate, I'd go for DPs. I think > every dev understands how INPC works, but for newcomers to WPF/ Silverlight > DPs are something of a dark art. The peculiar relationship between DPs and > XAML, does my CLR wrapper get called? If I don't write a CLR wrapper is it > a > real DP? Can I add logic to CLR wrappers? What's all this metadata about? > Does it have to be called FooProperty?
> Agreed, language support for INPC would be nice, but language support for > DPs would be a whole lot nicer!
> MVVM is in a funny state at the moment. A lot of energy, a lot of great > ideas and individuality. There is a very interesting, recent post, on the > Silverlight forums about MVVM:
I get the feeling that people are taking their Win Forms knowledge and trying to apply it to WPF and tacking MVVM on top of it. Which is even worse than if they just used Winforms style programming.
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Jeremiah Morrill Sent: Tuesday, February 02, 2010 3:32 AM To: wpf-disciples@googlegroups.com Subject: Re: [WPF Disciples] Re: State of MVVM
All I get out of that guy's post is that he thinks MVVM is for everything. I'm guessing he and his bosses have never heard of a template-able control? I think the SilverlightToolkit is using best practices, is testable and there's no MVVM in sight...
Do you guys feel that new-comers to MVVM have a confusion of when to make a View vs. a reusable UI control?
BTW, for those exact reasons that this guy whines about is why MVVM is great to me. It makes it easy to isolate the logic that drives your application from the logic that drives your UI. Putting crap like enabling controls when this checkbox is true directly in the code behind is brittle because when the requirements change to "enable this section of the app when the checkbox is true and the value of the publish date is 1970 or earlier" and later changes to "enable this section if the logged in user is an administrator, there's a full moon tonight, and the width of the screen is 800".
The requirements are absurd but that's the great thing. Who gives a damn? You have one place to change that logic and it's all event driven and isolated from the 20 thousand other bits of display logic being juggled around in your UI.
On Behalf Of Michael D. Brown Sent: Monday, February 01, 2010 11:14 PM To: wpf-disciples@googlegroups.com
Subject: RE: [WPF Disciples] Re: State of MVVM
On a side note, you guys are referenced up the wazoo on Wikipedia. That's big pimpin'!
-----Original Message----- From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Colin Eberhardt Sent: Monday, February 01, 2010 5:18 PM To: WPF Disciples Subject: [WPF Disciples] Re: State of MVVM
> > Among the next steps, I would like to eliminate the boilerplate > > code for INotifyPropertyChanged (and eventually eliminate > > DependencyProperties and DependencyObjects and allow any property on > > any class to support binding and change notification).
> Wow! I can just imagine the abuse of being able to databind anything > to anything. :) Elimination of the INPC boilerplate has been the holy > grail of MVVM devs, but I'm fairly convinced this can't be done at the > library level. AOP solutions work, but the costs incurred with this > approach are too steep for many. I'd love to see some language support > here.
Elimination of INPC boiler plate code is the holy grail of MVVM? This one has always baffled me. Yes, it is repetitive boiler plate code, but it doesn't take that long to rivet those plates into place. Seriously, how much of your time do you spend on INPC implementation? And how often have you been handed a bug that was due to incorrect INPC implementation?
If it's boiler plate code you want to eliminate, I'd go for DPs. I think every dev understands how INPC works, but for newcomers to WPF/ Silverlight DPs are something of a dark art. The peculiar relationship between DPs and XAML, does my CLR wrapper get called? If I don't write a CLR wrapper is it a real DP? Can I add logic to CLR wrappers? What's all this metadata about? Does it have to be called FooProperty?
Agreed, language support for INPC would be nice, but language support for DPs would be a whole lot nicer!
MVVM is in a funny state at the moment. A lot of energy, a lot of great ideas and individuality. There is a very interesting, recent post, on the Silverlight forums about MVVM:
I suspect you're right - I also suspect that there are a couple of other things coming into play here:
1. He's got a position that he's defended in the past, so rather than admit that he could be wrong on some points, he's going to keep to his standard party line. 2. Some people are just anti-pattern. Patterns require some thought, planning and architecture and this is just plain alien to certain developers. They'd rather sit down and hammer out code than actually think something through for half a day. One of the key traits of these developers is that they also seem to be against testing their code, so you won't see unit tests and the like.
On Tue, Feb 2, 2010 at 1:15 PM, Michael D. Brown <mike.br...@azurecoding.net
> wrote: > I get the feeling that people are taking their Win Forms knowledge and > trying to apply it to WPF and tacking MVVM on top of it. Which is even worse > than if they just used Winforms style programming.
> *From:* wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] *On Behalf Of *Jeremiah Morrill > *Sent:* Tuesday, February 02, 2010 3:32 AM
> *To:* wpf-disciples@googlegroups.com > *Subject:* Re: [WPF Disciples] Re: State of MVVM
> All I get out of that guy's post is that he thinks MVVM is for *everything > *. I'm guessing he and his bosses have never heard of a template-able > control? I think the SilverlightToolkit is using best practices, is > testable and there's no MVVM in sight...
> Do you guys feel that new-comers to MVVM have a confusion of when to make a > View vs. a reusable UI control?
> -Jer
> On Mon, Feb 1, 2010 at 8:28 PM, Michael D. Brown < > mike.br...@azurecoding.net> wrote:
> BTW, for those exact reasons that this guy whines about is why MVVM is > great > to me. It makes it easy to isolate the logic that drives your application > from the logic that drives your UI. Putting crap like enabling controls > when > this checkbox is true directly in the code behind is brittle because when > the requirements change to "enable this section of the app when the > checkbox > is true and the value of the publish date is 1970 or earlier" and later > changes to "enable this section if the logged in user is an administrator, > there's a full moon tonight, and the width of the screen is 800".
> The requirements are absurd but that's the great thing. Who gives a damn? > You have one place to change that logic and it's all event driven and > isolated from the 20 thousand other bits of display logic being juggled > around in your UI.
> On Behalf Of Michael D. Brown > Sent: Monday, February 01, 2010 11:14 PM > To: wpf-disciples@googlegroups.com
> Subject: RE: [WPF Disciples] Re: State of MVVM
> On a side note, you guys are referenced up the wazoo on Wikipedia. That's > big pimpin'!
> -----Original Message----- > From: wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] > On Behalf Of Colin Eberhardt > Sent: Monday, February 01, 2010 5:18 PM > To: WPF Disciples > Subject: [WPF Disciples] Re: State of MVVM
> > > Among the next steps, I would like to eliminate the boilerplate > > > code for INotifyPropertyChanged (and eventually eliminate > > > DependencyProperties and DependencyObjects and allow any property on > > > any class to support binding and change notification).
> > Wow! I can just imagine the abuse of being able to databind anything > > to anything. :) Elimination of the INPC boilerplate has been the holy > > grail of MVVM devs, but I'm fairly convinced this can't be done at the > > library level. AOP solutions work, but the costs incurred with this > > approach are too steep for many. I'd love to see some language support > > here.
> Elimination of INPC boiler plate code is the holy grail of MVVM? This one > has always baffled me. Yes, it is repetitive boiler plate code, but it > doesn't take that long to rivet those plates into place. > Seriously, how much of your time do you spend on INPC implementation? > And how often have you been handed a bug that was due to incorrect INPC > implementation?
> If it's boiler plate code you want to eliminate, I'd go for DPs. I think > every dev understands how INPC works, but for newcomers to WPF/ Silverlight > DPs are something of a dark art. The peculiar relationship between DPs and > XAML, does my CLR wrapper get called? If I don't write a CLR wrapper is it > a > real DP? Can I add logic to CLR wrappers? What's all this metadata about? > Does it have to be called FooProperty?
> Agreed, language support for INPC would be nice, but language support for > DPs would be a whole lot nicer!
> MVVM is in a funny state at the moment. A lot of energy, a lot of great > ideas and individuality. There is a very interesting, recent post, on the > Silverlight forums about MVVM:
I agree that we can use MVVM to write rich UI efficiently. But I don't think that MVVM is the only way to write rich UI efficiently. There are a lot of patterns that we can write rich UI ( UI is not just WPF/Silverlight)
>>2) where the code is maintainable
The same goes for this as well. Writing maintainable code is not just about MVVM.
>>3) the model never needs to be changed to support changes to the view >>4) the viewmodel rarely if ever needs to be changed to support changes to the view >>5) there can be many views of the same viewmodel
Agreed.
>>6) the design is as toolable as possible.
Do you agree the fact that we need to dump the view as much as possible?
Do you think that using Data Trigger or Value Converter are anti-MVVM? If yes then what about using Visual State Manager, Blend Behivor, Event or Property Trigger?
Is it okay to have control-related stuffs (like Control Event or etc ) in View Model?
I'd love to hear other's opinion as well for those questions.....
Regards, Michael Sync
Thanks and Best Regards, Michael Sync
Don't go the way life takes you. Take life the way you go
On Tue, Feb 2, 2010 at 3:09 AM, John Gossman <gossmans...@gmail.com> wrote: > I haven't written anything about MVVM in a while because there is so much > material already being published. However I have been thinking about what > we can do in the platform to make things better and reading a lot of the > public stuff, so I thought I'd summarize for my own sake if nothing else:
> The state of MVVM reminds me of Peter Naur's classic paper "Programming as > Theory Building". He basically says the proper model for computer > programming is not engineering but scientific development where you have > problem, you develop a hypothesis for how to fix it, you experiment (write > code and test it), and then you decide whether you've solved the problem. > If not you synthesize a new hypothesis and try again.
> MVVM feels more like "science" than anything else I've seen...with lots of > authors publishing papers containing their hypotheses and results and > suggesting avenues for further research. Some papers are better than > others, some are revolutionary and some contain nothing new.
> Fundamentally I think the goal of MVVM has still not been clearly stated. > I posit some of the goals include: > 1) efficiently write rich UI > 2) where the code is maintainable > 3) the model never needs to be changed to support changes to the view > 4) the viewmodel rarely if ever needs to be changed to support changes to > the view > 5) there can be many views of the same viewmodel > 6) the design is as toolable as possible.
> To my mind #6 is the most important and perhaps the one we still have made > the least progress with. Blend Behaviors are a huge step in the right > direction, but we need to go further.
> I don't think eliminating all code from the View is part of the goal, > though it obviously makes some of the others easier. When it makes them > harder though, one should write view code (though whether that means the > code behind model or something else is not clear).
> Among the next steps, I would like to eliminate the boilerplate code for > INotifyPropertyChanged (and eventually eliminate DependencyProperties and > DependencyObjects and allow any property on any class to support binding and > change notification). Further I would like to bind events in the View > directly to Commands on the ViewModel so you can say <Button Click="{Binding > SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>. This > leads to the question whether ICommand itself is just boilerplate and we can > simply remove it with binding directly to methods. The downside being it > isn't clear all methods can/should be called from the View in which case it > may be useful to have contract (currently offered by the list of properties > of type ICommand). On the tooling side I would like to see a UI where you > can select a control, see a list of the events it supports and choose which > methods on the ViewModel you want them to trigger. This leads in turn to > how to handle event arguments like keys. Keybinding is already pretty good, > but the syntax should be simple.
- To the goals, I would add that testability is important to many of us. - I'd love to see the INPC code disappear, perhaps simply by the C# compiler implementing the code for auto properties. - I don't mind dependency properties as they currently are as a typical 'use case' doesn't necessitate creating them. Most projects generally have 'cross cutting' team members who work on controls, frameworks and so on, and 'feature' developers focused on a specific use case. I'd like to optimize the productivity of the latter. - Blend behaviors are nice, but then, they shouldn't be 'Blend' behaviors, they should be part of WPF and have VS support. Simplifying the syntax would be nice too.
That said, I think these are all relatively small improvements over the current experience which is already pretty good - and I can work around any problems. There are lots of other improvements I'd like to see over any of these, most of which I can't work around. In fact I just took the liberty of writing them all down :)
On Tue, Feb 2, 2010 at 6:09 AM, John Gossman <gossmans...@gmail.com> wrote: > I haven't written anything about MVVM in a while because there is so much > material already being published. However I have been thinking about what > we can do in the platform to make things better and reading a lot of the > public stuff, so I thought I'd summarize for my own sake if nothing else:
> The state of MVVM reminds me of Peter Naur's classic paper "Programming as > Theory Building". He basically says the proper model for computer > programming is not engineering but scientific development where you have > problem, you develop a hypothesis for how to fix it, you experiment (write > code and test it), and then you decide whether you've solved the problem. > If not you synthesize a new hypothesis and try again.
> MVVM feels more like "science" than anything else I've seen...with lots of > authors publishing papers containing their hypotheses and results and > suggesting avenues for further research. Some papers are better than > others, some are revolutionary and some contain nothing new.
> Fundamentally I think the goal of MVVM has still not been clearly stated. > I posit some of the goals include: > 1) efficiently write rich UI > 2) where the code is maintainable > 3) the model never needs to be changed to support changes to the view > 4) the viewmodel rarely if ever needs to be changed to support changes to > the view > 5) there can be many views of the same viewmodel > 6) the design is as toolable as possible.
> To my mind #6 is the most important and perhaps the one we still have made > the least progress with. Blend Behaviors are a huge step in the right > direction, but we need to go further.
> I don't think eliminating all code from the View is part of the goal, > though it obviously makes some of the others easier. When it makes them > harder though, one should write view code (though whether that means the > code behind model or something else is not clear).
> Among the next steps, I would like to eliminate the boilerplate code for > INotifyPropertyChanged (and eventually eliminate DependencyProperties and > DependencyObjects and allow any property on any class to support binding and > change notification). Further I would like to bind events in the View > directly to Commands on the ViewModel so you can say <Button Click="{Binding > SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>. This > leads to the question whether ICommand itself is just boilerplate and we can > simply remove it with binding directly to methods. The downside being it > isn't clear all methods can/should be called from the View in which case it > may be useful to have contract (currently offered by the list of properties > of type ICommand). On the tooling side I would like to see a UI where you > can select a control, see a list of the events it supports and choose which > methods on the ViewModel you want them to trigger. This leads in turn to > how to handle event arguments like keys. Keybinding is already pretty good, > but the syntax should be simple.
On Tue, Feb 2, 2010 at 1:29 PM, Paul Stovell <p...@paulstovell.com> wrote: > Hi John,
> A few thoughts:
> - To the goals, I would add that testability is important to many of > us. > - I'd love to see the INPC code disappear, perhaps simply by the C# > compiler implementing the code for auto properties. > - I don't mind dependency properties as they currently are as a typical > 'use case' doesn't necessitate creating them. Most projects generally have > 'cross cutting' team members who work on controls, frameworks and so on, and > 'feature' developers focused on a specific use case. I'd like to optimize > the productivity of the latter. > - Blend behaviors are nice, but then, they shouldn't be 'Blend' > behaviors, they should be part of WPF and have VS support. Simplifying the > syntax would be nice too.
> That said, I think these are all relatively small improvements over the > current experience which is already pretty good - and I can work around any > problems. There are lots of other improvements I'd like to see over any of > these, most of which I can't work around. In fact I just took the liberty of > writing them all down :)
> On Tue, Feb 2, 2010 at 6:09 AM, John Gossman <gossmans...@gmail.com>wrote:
>> I haven't written anything about MVVM in a while because there is so much >> material already being published. However I have been thinking about what >> we can do in the platform to make things better and reading a lot of the >> public stuff, so I thought I'd summarize for my own sake if nothing else:
>> The state of MVVM reminds me of Peter Naur's classic paper "Programming as >> Theory Building". He basically says the proper model for computer >> programming is not engineering but scientific development where you have >> problem, you develop a hypothesis for how to fix it, you experiment (write >> code and test it), and then you decide whether you've solved the problem. >> If not you synthesize a new hypothesis and try again.
>> MVVM feels more like "science" than anything else I've seen...with lots of >> authors publishing papers containing their hypotheses and results and >> suggesting avenues for further research. Some papers are better than >> others, some are revolutionary and some contain nothing new.
>> Fundamentally I think the goal of MVVM has still not been clearly stated. >> I posit some of the goals include: >> 1) efficiently write rich UI >> 2) where the code is maintainable >> 3) the model never needs to be changed to support changes to the view >> 4) the viewmodel rarely if ever needs to be changed to support changes to >> the view >> 5) there can be many views of the same viewmodel >> 6) the design is as toolable as possible.
>> To my mind #6 is the most important and perhaps the one we still have made >> the least progress with. Blend Behaviors are a huge step in the right >> direction, but we need to go further.
>> I don't think eliminating all code from the View is part of the goal, >> though it obviously makes some of the others easier. When it makes them >> harder though, one should write view code (though whether that means the >> code behind model or something else is not clear).
>> Among the next steps, I would like to eliminate the boilerplate code for >> INotifyPropertyChanged (and eventually eliminate DependencyProperties and >> DependencyObjects and allow any property on any class to support binding and >> change notification). Further I would like to bind events in the View >> directly to Commands on the ViewModel so you can say <Button Click="{Binding >> SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>. This >> leads to the question whether ICommand itself is just boilerplate and we can >> simply remove it with binding directly to methods. The downside being it >> isn't clear all methods can/should be called from the View in which case it >> may be useful to have contract (currently offered by the list of properties >> of type ICommand). On the tooling side I would like to see a UI where you >> can select a control, see a list of the events it supports and choose which >> methods on the ViewModel you want them to trigger. This leads in turn to >> how to handle event arguments like keys. Keybinding is already pretty good, >> but the syntax should be simple.
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Paul Stovell Sent: 02 February 2010 13:30 To: wpf-disciples@googlegroups.com Subject: Re: [WPF Disciples] State of MVVM
Hi John,
A few thoughts:
* To the goals, I would add that testability is important to many of us. * I'd love to see the INPC code disappear, perhaps simply by the C# compiler implementing the code for auto properties. * I don't mind dependency properties as they currently are as a typical 'use case' doesn't necessitate creating them. Most projects generally have 'cross cutting' team members who work on controls, frameworks and so on, and 'feature' developers focused on a specific use case. I'd like to optimize the productivity of the latter. * Blend behaviors are nice, but then, they shouldn't be 'Blend' behaviors, they should be part of WPF and have VS support. Simplifying the syntax would be nice too.
That said, I think these are all relatively small improvements over the current experience which is already pretty good - and I can work around any problems. There are lots of other improvements I'd like to see over any of these, most of which I can't work around. In fact I just took the liberty of writing them all down :)
On Tue, Feb 2, 2010 at 6:09 AM, John Gossman <gossmans...@gmail.com> wrote:
I haven't written anything about MVVM in a while because there is so much material already being published. However I have been thinking about what we can do in the platform to make things better and reading a lot of the public stuff, so I thought I'd summarize for my own sake if nothing else:
The state of MVVM reminds me of Peter Naur's classic paper "Programming as Theory Building". He basically says the proper model for computer programming is not engineering but scientific development where you have problem, you develop a hypothesis for how to fix it, you experiment (write code and test it), and then you decide whether you've solved the problem. If not you synthesize a new hypothesis and try again.
MVVM feels more like "science" than anything else I've seen...with lots of authors publishing papers containing their hypotheses and results and suggesting avenues for further research. Some papers are better than others, some are revolutionary and some contain nothing new.
Fundamentally I think the goal of MVVM has still not been clearly stated. I posit some of the goals include: 1) efficiently write rich UI 2) where the code is maintainable 3) the model never needs to be changed to support changes to the view 4) the viewmodel rarely if ever needs to be changed to support changes to the view 5) there can be many views of the same viewmodel 6) the design is as toolable as possible.
To my mind #6 is the most important and perhaps the one we still have made the least progress with. Blend Behaviors are a huge step in the right direction, but we need to go further.
I don't think eliminating all code from the View is part of the goal, though it obviously makes some of the others easier. When it makes them harder though, one should write view code (though whether that means the code behind model or something else is not clear).
Among the next steps, I would like to eliminate the boilerplate code for INotifyPropertyChanged (and eventually eliminate DependencyProperties and DependencyObjects and allow any property on any class to support binding and change notification). Further I would like to bind events in the View directly to Commands on the ViewModel so you can say <Button Click="{Binding SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>. This leads to the question whether ICommand itself is just boilerplate and we can simply remove it with binding directly to methods. The downside being it isn't clear all methods can/should be called from the View in which case it may be useful to have contract (currently offered by the list of properties of type ICommand). On the tooling side I would like to see a UI where you can select a control, see a list of the events it supports and choose which methods on the ViewModel you want them to trigger. This leads in turn to how to handle event arguments like keys. Keybinding is already pretty good, but the syntax should be simple.
I like how you pointed our Karl specifically rather than "all VB.NETdevelopers". I guess since Karl is the only WPF developer using VB.NET it's valid to name him individually :)
Just kidding Karl.
Paul
On Wed, Feb 3, 2010 at 12:33 AM, Peter O'Hanlon <pete.ohan...@gmail.com>wrote:
> Paul - amen to the compiler implementing the code for INPC auto properties, > but I'd extend this to VB.NET as well to keep Karl happy.
> On Tue, Feb 2, 2010 at 1:29 PM, Paul Stovell <p...@paulstovell.com> wrote:
>> Hi John,
>> A few thoughts:
>> - To the goals, I would add that testability is important to many of >> us. >> - I'd love to see the INPC code disappear, perhaps simply by the C# >> compiler implementing the code for auto properties. >> - I don't mind dependency properties as they currently are as a >> typical 'use case' doesn't necessitate creating them. Most projects >> generally have 'cross cutting' team members who work on controls, frameworks >> and so on, and 'feature' developers focused on a specific use case. I'd like >> to optimize the productivity of the latter. >> - Blend behaviors are nice, but then, they shouldn't be 'Blend' >> behaviors, they should be part of WPF and have VS support. Simplifying the >> syntax would be nice too.
>> That said, I think these are all relatively small improvements over the >> current experience which is already pretty good - and I can work around any >> problems. There are lots of other improvements I'd like to see over any of >> these, most of which I can't work around. In fact I just took the liberty of >> writing them all down :)
>> On Tue, Feb 2, 2010 at 6:09 AM, John Gossman <gossmans...@gmail.com>wrote:
>>> I haven't written anything about MVVM in a while because there is so much >>> material already being published. However I have been thinking about what >>> we can do in the platform to make things better and reading a lot of the >>> public stuff, so I thought I'd summarize for my own sake if nothing else:
>>> The state of MVVM reminds me of Peter Naur's classic paper "Programming >>> as Theory Building". He basically says the proper model for computer >>> programming is not engineering but scientific development where you have >>> problem, you develop a hypothesis for how to fix it, you experiment (write >>> code and test it), and then you decide whether you've solved the problem. >>> If not you synthesize a new hypothesis and try again.
>>> MVVM feels more like "science" than anything else I've seen...with lots >>> of authors publishing papers containing their hypotheses and results and >>> suggesting avenues for further research. Some papers are better than >>> others, some are revolutionary and some contain nothing new.
>>> Fundamentally I think the goal of MVVM has still not been clearly >>> stated. I posit some of the goals include: >>> 1) efficiently write rich UI >>> 2) where the code is maintainable >>> 3) the model never needs to be changed to support changes to the view >>> 4) the viewmodel rarely if ever needs to be changed to support changes to >>> the view >>> 5) there can be many views of the same viewmodel >>> 6) the design is as toolable as possible.
>>> To my mind #6 is the most important and perhaps the one we still have >>> made the least progress with. Blend Behaviors are a huge step in the right >>> direction, but we need to go further.
>>> I don't think eliminating all code from the View is part of the goal, >>> though it obviously makes some of the others easier. When it makes them >>> harder though, one should write view code (though whether that means the >>> code behind model or something else is not clear).
>>> Among the next steps, I would like to eliminate the boilerplate code for >>> INotifyPropertyChanged (and eventually eliminate DependencyProperties and >>> DependencyObjects and allow any property on any class to support binding and >>> change notification). Further I would like to bind events in the View >>> directly to Commands on the ViewModel so you can say <Button Click="{Binding >>> SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>. This >>> leads to the question whether ICommand itself is just boilerplate and we can >>> simply remove it with binding directly to methods. The downside being it >>> isn't clear all methods can/should be called from the View in which case it >>> may be useful to have contract (currently offered by the list of properties >>> of type ICommand). On the tooling side I would like to see a UI where you >>> can select a control, see a list of the events it supports and choose which >>> methods on the ViewModel you want them to trigger. This leads in turn to >>> how to handle event arguments like keys. Keybinding is already pretty good, >>> but the syntax should be simple.
