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
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
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.
-Evan
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:
http://forums.silverlight.net/forums/t/159237.aspx
Regards,
Colin E.
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-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
Oh well. It had to be said :)
-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Laurent Bugnion, GalaSoft
Sent: Monday, February 01, 2010 11:49 PM
To: wpf-di...@googlegroups.com
Thanks Jer.
Wow, 5 months of being unhappy at work. I cannot start to imagine what it must be like.
Cheers,
Laurent
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:
>
> http://forums.silverlight.net/forums/t/159237.aspx
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.
-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@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
>
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-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Michael D. Brown
Sent: Monday, February 01, 2010 11:14 PM
To: wpf-di...@googlegroups.com
.Corrado
-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
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
Laurent
--
Sent from mobile
-original message-
Subject: Re: [WPF Disciples] Re: State of MVVM
From: Zhou Yong <footb...@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
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-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Jeremiah Morrill
Sent: Tuesday, February 02, 2010 3:32 AM
To: wpf-di...@googlegroups.com
Why shouldn’t they be “Blend Behaviours”?
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Paul Stovell
Sent: 02 February 2010 13:30
To: wpf-di...@googlegroups.com
> To the goals, I would add that testability is important to many of us.
Uhm... I thought that was a given :). Yeah, this is probably THE biggest reason.
> 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.
I said as much about them being part of WPF/VS way back when they were
announced and we discussed them on this list. I understood at the time
that that was the final intent, but maybe I was wrong? I agree, they
should be in the base libraries, and Cider should support them. I'm
not as worried about the syntax, since they are toolable concepts.
Hopefully, you won't ever code one of these by hand :).
> 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 :)
>
> http://www.paulstovell.com/wpf-wishlist
From your wish list:
> 2.I shouldn't have to declare the same half-dozen xmlns:abc entries in every XAML file. An ASPX inspired 'project-wide imports' system would be great.
Could something be achieved through xinclude or similar?
> 3.Ability to replace tags from a namespace, ala ASP.NET TagMapping.
This one's focused fairly strongly on hand coding the XML, which I
hope we're moving away from with designers and Blend. Not saying this
is a bad idea, but I'd make it a fairly low priority.
> 6. MarkupExtension should be an interface. Then extensions could be DependencyObjects and thereby support attached properties.
Interesting. If they can make binding work on any type, though, maybe
we could get attached properties to not require DependencyObject in
the inheritance chain? I would be interested in hearing some use cases
for this idea, though. It's intriguing, even if I don't see when I'd
use it.
> 7. MarkupExtension should be an interface. Then extensions could be DependencyObjects and thereby support attached properties.
What's the difficulty here?
> 8. FrameworkElement.AddLogicalChild shouldn't be protected, it should be public
What would you do with this?
> 9. Styles simply shouldn't be so verbose. Give us a CSS-like syntax for styles.
I'm not as concerned about this. The syntax really isn't that bad, and
unlike CSS, remains consistent with the rest of the syntax. What I'd
like more is a more flexible system for applying styles (think CSS
selectors, though it doesn't have to exactly parallel this).
> 12.Easier to make attached lazy collections (without the current 'hacks').
The hacks are awfully easy. The problem with the hacks are that they
aren't self documenting. Someone not familiar with the hack has no
idea what's going on or why things are coded the way they are. That's
bad. For this reason, I too would love to see lazy creation added to
attached properties (and not just for collections, though that's the
canonical example).
> 18.Delete everything from System.Windows.Navigation, and build a better navigation system.
Here, here! This is probably in the top 5 things I want fixed, and
it's one of the larger and more important ones. PageFunction, at least
as it's implemented today, must die, and a LOT more attention needs to
be paid to lifetime/journal management (which includes the ability to
purge nodes from both the back and forward history stacks).
--
I wholeheartedly agree that Behaviors should be in the framework proper. After all, while behaviors will be USED in Blend, they will be DEVELOPED in VS.
Hi,
Paul, what should be better in VS? OK the syntax could be simplified, I agree, but other than that, I don't find it a big deal to add a behavior in VS, especially with R# enabled. I also agree it would be great to get rid of System.Windows.Interactivity.dll. Other than that, did you mean you want tool support to add a behavior?
I would like to have another name for them though. Naming them "Blend behaviors" makes people think that they need to have Blend installed to work with behaviors, which is not true. I don't like to use "behaviors", "actions" and "triggers" alone either, because then it is not clear what we speak about. We just need a better name, that doesn't covey the "blend" name, just to make things clearer. Maybe "interaction behaviors" but that is a mouthful…
Cheers,
Laurent
Excellent ideas, thans for precising!
OK, no doubt they should be in the Framework. 100% agreed.
And I don’t know any other way to build them other then in Visual Studio – so nothing has changed there?
I don’t believe that anyone who needs to perform any sort of serious interactivity implementation would gain anything by having to work with the Visual Studio designer as opposed to Blend.
I agree that it would be nice to have that support though for those that want to use Behaviours as a short cut for implementing boiler plate pieces of functionality in a fairly simple UI in design terms.
Let me ask a pretty simple question.... If Blend had the Visual Studio code editor embedded along with say 80% of the additional features that we need from VS aside from straight code editing; would you use Blend or still use Visual Studio?
I ask you all that question... because it’s interesting that the design side of the fence understand what their tool is. They understand very clearly how it should work and they are pretty fixed on making sure that it works for the tasks that they need to perform on their side of the designer/developer workflow. They don’t want it to be a development tool.
Have we developers figured that out yet for Visual Studio, or do we still think that we should own it all? (In other words – when is enough.. enough in terms of the Visual Studio design surface?
**Commence rock throwing**
> Let me ask a pretty simple question.... If Blend had the Visual Studio code
> editor embedded along with say 80% of the additional features that we need
> from VS aside from straight code editing; would you use Blend or still use
> Visual Studio?
Turn it around. If VS had 80% of the features of Blend, would you use
Blend or VS? As long as we stick to that 80% figure, the answer would
depend on whether or not you were a developer or a designer. If Blend
had 80% of the functionality of VS, I'd still use VS for everything
but UI work... and even then, I'd use VS for that work as well at
least some of the time. Why? Because I'm a developer, not a designer.
To be honest, I kinda wished they'd made Blend modular, such that
designers would have the experience they're used to, while us devs
would have Blend *inside* of VS instead of having to use Cider and/or
switch back and forth between Blend and VS.
> I ask you all that question... because it’s interesting that the design side
> of the fence understand what their tool is. They understand very clearly how
> it should work and they are pretty fixed on making sure that it works for
> the tasks that they need to perform on their side of the designer/developer
> workflow. They don’t want it to be a development tool.
That's because all they do is design work. Developers have always had
to straddle the fence, and while the theory is that we'll move towards
having dedicated designers on projects, the developer is still going
to have to work with the UI at least to do integration work.
We understand what our tool is. We understand clearly how it should
work. However, we do multiple things with that tool, unlike the
designer, so our tool has to be able to do multiple things.
> Have we developers figured that out yet for Visual Studio, or do we still
> think that we should own it all? (In other words – when is enough.. enough
> in terms of the Visual Studio design surface?
I'm not sure enough is ever enough when it comes to a development tool :).
--
My main grudge with VS is the sheer absence of product support. We had one single service pack with VS2008, and yeah, there's about 5K non-officially supported hotfixes one can individually download. Given VS is a product that should help us write stable software, I can't help but scratch my head about this. I would certainly see VS2010 to get more love after RTM than its predecessors.
Blend is a nice tool, and it makes a nice addition. But then, I mainly use Blend because designer support really is lacking in VS (the 2010 bits we've seen so far included). Blend "within" VS would be nice, but as an alternative, as more seamless switching between the two products already would be nice.
Plain and simple…I don’t see why VS doesn’t share the same designer as Blend. MSFT already does it with Expression Web being the designer for HTML in VS. It would allow the teams to stop duplicating effort and make a better product for both sides.
--
On Feb 2, 9:26 pm, "Peter O'Hanlon" <pete.ohan...@gmail.com> wrote:
> I'm going to be really controversial here then - I don't use the designer
> inside Visual Studio at all, I code up all my basic XAML by hand >
Sounds like you are not so controversial as you think! I also do all
my XAML by hand. I just like XML.
My main bugbear with the VS tooling is the lack of decent error
messages when developing WPF / Silverlight. So many problems result in
cryptic parse errors or an application that sits and does nothing!
Whilst experienced developers learn the patterns and can rapidly side-
step the gotchas, newcomers to the frameworks often struggle.
Regards,
Colin E.
Most of the projects I work on are only partially blendable (I would say
anywhere from 30% to 80%). Tweaking the XAML is as much part of an
integrator's job as knowing Blend inside out. I don't really see anything
wrong with that.
I have been using the VS designer mostly to get screenshots for my book ;)
It's not bad, not bad at all (I especially like the binding editor) but it's
not Blend. Having talked to a lot of devs about that, especially in small
one-man-shop type firms, I am not convinced that integrating the Blend
designer in Studio would be a winner. Unless of course we finally get a "VS
skin" for Blend like I have been advocating since the MVP summit 2008 ;)
Cheers,
Laurent
-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
I will be a little controversial... not because I want to piss anyone off
but because I think it's important to have these debates. I do it inside
design circles as well to ensure I get the entire view of all camps
concerned...
I have to say looking over the response that most people in here do have
that understanding of why things are the way they are. Of course we want
them to always improve on previous versions, and that's because we are the
way we are (perfectionists!) and it's awesome!
One comment that is a little miss-guided is to think that designers only
have one thing to do in their tool and don’t need multiple things from it
live we as developers need from VS.
Currently using Blend, you have Rapid proto-typers, Interactive Designers,
Visual Designers, Industrial Designers to name a few that all use the tool.
They all have different needs and different requirements - not just painting
pretty pictures. It (Blend) also has multiple outputs from Silverlight, WPF,
Surface, SketchFlow (and a few other secrets). It does it well (and will get
better) for designers that are not wanting to try and develop in it. The
point is that Blend is a specific tool for the creation of interaction and
design implementation. Visual Studio is and should remain a specific tool
for the implementation of development. If we blur the lines too much... we
wind up in a mess that is of our own doing and will be hard to undo if it
goes too far.
All I can say (and will continue to say) is that it is vital to our industry
that we be the guardians of designer/developer based workflows. MVVM as a
pattern is an enabler of this workflow, but it too needs careful
considerations to how it's implementation can benefit BOTH sides of the
solution and not just one party who are ferocious in their need for logical
performance.
The NHS in the UK is Microsoft's largest global client (well that is what
the NHS tell me) and so have some of the largest enterprise solutions on the
planet. The vast majority of the existing solutions are totally shit.
Remarkable shit - built purely by developers. These systems are unusable -
hence the reasons doctors and nurses in most hospitals still write stuff on
paper and use whiteboards and then have some poor intern manually enter it
into the rubbish system. People die because of these shit systems. Data is
out of date by 3 months in most cases, sometimes caused by poor
infrastructure, but the number one reason - you guessed it... people either
don’t or cant enter details in these systems accurately because they were
never designed with the end user in mind.
They (the NHS) have woken up (with some very simple samples) to how using a
User Centred Design (UCD) process to draw solution requirements (rather than
using a business analyst) pays massive productivity dividends - because
people actually want to use the software instead of going out of their way
to avoid it. The improvements have a fiscal value that runs into the tens if
not hundreds of millions of pounds (that's a shit load for you $Dollar
owners {... you know I love the US})
That is the "enterprise" domain, so if they understand the absolute
requirement of designers in the solution, there is not a single excuse why
anyone else can't do it to. If you are heading towards that process... you
are already behind the curve.
Companies like IdentityMine (and shout to my crew at Splendid) are models of
how this works; not just in consumer software but also some pretty big
enterprise solutions as well.
So to end... my view is that the state of MVVM is pretty darn impressive
given the time span we have been moving with this... we can make it (the
tools, the frameworks, the creators) better again in the future if we don’t
exclude requirements from all sides.
Disclaimer:
I have the flu at the moment and the medications mean no one can take
offense to my views as my sanity is questionable ;-)
Good things to everyone.
Cheers
-> 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.
Hi John,
A few thoughts: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 :)
- 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.
http://www.paulstovell.com/wpf-wishlist
Paul
On Tue, Feb 2, 2010 at 6:09 AM, John Gossman <gossm...@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.
--
Paul Stovell