State of MVVM

[John Gossman]

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.

[Bill Kempf]

On Mon, Feb 1, 2010 at 2:09 PM, John Gossman <gossm...@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.

[Laurent Bugnion, GalaSoft]

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

[Marlon Grech]

same comments here

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/
Microsoft MVP for Client App

[Michael D. Brown]

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

[Evan Lang]

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.

-Evan

[Colin Eberhardt]

>
> > 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:

http://forums.silverlight.net/forums/t/159237.aspx

Regards,
Colin E.

[Laurent Bugnion, GalaSoft]

[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-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]

[Laurent Bugnion, GalaSoft]

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-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

[Jeremiah Morrill]

I remember that dude Laurent.  He made some valid points about his architects...but now he's just on a crusade.

Here's his first one.

http://forums.silverlight.net/forums/t/127825.aspx

[Laurent Bugnion, GalaSoft]

Thanks Jer.

 

Wow, 5 months of being unhappy at work. I cannot start to imagine what it must be like.

 

Cheers,

Laurent

[Zhou Yong]

-> 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:)

MarcoZ

[Bill Kempf]

On Mon, Feb 1, 2010 at 5:17 PM, Colin Eberhardt
<colin.e...@gmail.com> wrote:
>>
>> > 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:
>
> 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.

[Michael D. Brown]

On a side note, you guys are referenced up the wazoo on Wikipedia. That's
big pimpin'!

-----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

>

[Michael D. Brown]

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-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 Cavalli]

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.

.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 Bugnion]

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 <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

[Jeremiah Morrill]

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

[Michael D. Brown]

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

[Peter O'Hanlon]

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.

--
Peter O'Hanlon

[Michael Sync]

Hi John,

Thanks for creating MVVM pattern. :) 

>>1)  efficiently write rich UI 

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

http://michaelsync.net

[Paul Stovell]

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 :)

http://www.paulstovell.com/wpf-wishlist

Paul

--
Paul Stovell

[Peter O'Hanlon]

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.

--
Peter O'Hanlon

[Brennon Williams]

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

[Paul Stovell]

I like how you pointed our Karl specifically rather than "all VB.NET developers". I guess since Karl is the only WPF developer using VB.NET it's valid to name him individually :)

Just kidding Karl.

Paul

--
Paul Stovell

[Bill Kempf]

On Tue, Feb 2, 2010 at 8:29 AM, Paul Stovell <pa...@paulstovell.com> wrote:

> 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).

[Bill Kempf]

Because we want to use them in Cider as well, and not all WPF
developers (gasp) use Blend and thus don't have access to them?

--

[Paul Stovell]

A couple of reasons:

• VS should have behavior support too - it's just such a good concept. Since Blend is optional, they can't really be Blend specific.
  
• I don't have to xcopy from machine to machine a DLL and manage the possible versioning issues which that introduces. For example, what if there's a security patch right now (unlikely, but who knows)? Auto updates can't fix it currently because every project has a private reference in their bin directory
  

So from a maintenance point of view it seems logical that it should be in the GAC. Easiest way to get it there is to move the types into PresentationFramework.dll - the same way DataGrid and VisualStateManager moved there from the WPF control toolkit when they could have easily stayed where they were.

Paul

--
Paul Stovell

[Michael D. Brown]

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.

[Laurent Bugnion, GalaSoft]

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

[Paul Stovell]

I'd like the syntax simplified just to make the intent clearer. I'd love if we could drop the i:Interaction.Behaviors lines, and just allow any Visual to accept 'IVisitor' objects, much like [ContentProperty] attribute, which the behaviors would implement:

<Button>
   <FooBehavior1 />
   <FooBehavior2 />
   My content here
</Button>

But yes, VS designer support would be the main request. Ideally behaviors could appear on the toolbox and be dragged on to a control, or with a custom editor in the property grid.

Oh, and I'll add another one that I wanted to do recently - ability to set behaviors in a style:

http://stackoverflow.com/questions/1252277/is-it-possible-to-apply-blend-behavior-using-style-or-template

Paul

--
Paul Stovell

[Laurent Bugnion, GalaSoft]

Excellent ideas, thans for precising!

[Brennon Williams]

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**

[Sacha Barber]

Right now I am not that enamoured with VS compared to other tools, such as (and believe me I do not like to say this), Eclipse and NetBeans, both of which seem to be quite ahead in terms of profiling/threading addins etc etc when compared to VS.

I do love Blend, but also like VS, but would be find using either as long as they dis what I wanted.

--
Sacha Barber
sacha....@gmail.com

[Bill Kempf]

On Tue, Feb 2, 2010 at 12:02 PM, Brennon Williams
<brennon...@x-coders.com> wrote:

> 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 :).

[Marlon Grech]

for threading there is much to come in VS2010.....

here are some things
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/10/19/vs-2010-beta-2-concurrency-resource-profiling-in-depth-first-look.aspx

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/
Microsoft MVP for Client App