Editor’s note: Welcome to .NETRocks Conversations, excerpts of conversations from the .NET Rocks! weekly Internet audio talk show. Hosts Richard Campbell and Carl Franklin chat with a wide variety of .NET developer experts. This month's excerpt is from show 573, with guest James Kovacs, a Microsoft MVP – ASP/ASP.NET and creator of psake, a PowerShell-based build automation tool.
Carl Franklin: So what have you been thinking about these days? What are you talking about, or coding about?
James Kovacs: Oh, lately psake has been heating up. psake is a PowerShell build tool that I wrote a while ago, and it's gradually been evolving. It has acquired a fairly good size user base now. People are moving away from Navigation bar XML-based build scripts. They're generally moving either to psake or Rake. Rake as in the Rake Build.
PowerShell is really a great language for scripting your builds. The one thing that it really does lack is the ability to manage dependencies, things like I always want to make sure my directories are clean before I do the compile, I always want to make sure my code is compiled before I write a test. The standard I want to make sure all the tests are run before I actually deploy to my testing environment, those types of things. So a lot of times you'll have dependencies between all of your different tasks, and this is what MSBuild does and NAnt and all the other build engines do. PowerShell is a great way for scripting out the actions to do. It doesn't have a way of managing the ordering of the task, and that's what psake provides over the top of it. So people have been having a really great time writing very straightforward build scripts and dramatically just reducing the XML headache of writing builds.
Richard Campbell: Remember when we thought XML was human readable?
JK: It's a great idea for a machine-parseable format that can be human, it's human debuggable.
CF: I would agree with that.
RC: Maybe I said something unfair there. It is readable. It's writing it that's horrible.
JK: That's very true. Yeah, that's especially one thing I \\[disliked\\] with XAML. It's the fact that they did lean so much on the tooling side of things, make it easy for the tooling but hard for the developer.
JK: Like WPF is a brilliant story, but it's kind of painful to hack at the XAML at times.
CF: Kind of.
RC: You know, by the same token if you ever went and look at the Win Forms code underlying it, it sucked for human readability, too, but we never looked at it. So if we could actually get to the point where WPF was working purely in a designer, we wouldn't care how ugly the XAML was.
CF: I don't know about you, James, but there are some things that are just easier to do in XAML than they are in the designer just by the nature of the design.
JK: Oh, absolutely.
CF: Especially when you have controls embedded inside controls. That's when it becomes really difficult even to select which control you want to work on graphically because you move the mouse one pixel, and you're on a different control.
JK: Oh, completely. The other thing I find about XAML is that when you're working with the XAML, 90 percent of the problems in XAML can be solved by removing code. The vast majority of what I found is that both XAML designer inside of Visual Studio as well as Blend tend to put in a lot of extra XAML to get it pixel perfect, but then it causes layout problems—for instance, putting in exact width and height and a lot of that stuff. If you just put in the right containing elements like stack panels versus dot panels versus the other different containers in XAML, you get the proper layout if re-layouts are laid out properly. Yeah, I'm doing a lot of WPF in XAML on my current project, and when we've had layout problems I literally go in, I remove a lot of extra attributes that are more often than not causing problems.
RC: You know I've heard this discussion before. This is the discussion we had in 1997 about table layouts.
CF: Yeah, you're right.
JK: Yeah.
RC: This is HTML problems re-created.
CF: Absolutely.
RC: Are we back there again, just with a different set of tools?
CF: Yes, we are.
JK: Yes, yes, we are.
RC: I'm horrified.
JK: The designer in Visual Studio is Visual Internet.
RC: Oh, no. I thought you're going to say FrontPage.
CF: Oh, man.
RC: It's FrontPage, man. The FrontPage is back. So, I mean, the interesting thing about this is we know their solutions to these things. Do we get to a style sheet approach with XAML at some point?
CF: Are we going to have an elastic control for XAML?
JK: Oh, jeez. I would love something that came to CSS in XAML. Styling in XAML, styling in WPF sucks.
RC: Yeah, and it is literally like you're doing it in HTML again. We're headed down this path.
CF: Wait a minute now. You have the ability to find styles at an abstract level and then apply those styles in a cascading manner?
JK: No. But the problem is that they have to be explicitly specified. It's very hard to do it in a convention-based way. A very good example, so the current project I'm working on, we have a bunch of textboxes and so we specified styles on them. So we said, okay, we didn't use style keys. We said we're applying it to a type of textbox. Then we realized that, okay, this only allows numeric entries, so we created a derived type of textbox that only allowed numbers to be put in. Over styles broke because although numeric textbox was derived from textbox, the style always applied to textbox and not the numeric one. So styles don't cascade down inheritance hierarchies.
RC: Right.
JK: Which really hurts because every time you realize, hey, I need a little bit of extra functionality and all of a sudden you have to repeat all your styles again and there are rules around if you were creating a derived style, you need to have a key, a style key to base it off of. You can't based it off of a style on a type so now you have to extract that common style into a separate key style that applies to....
CF: Okay.
JK: When you're trying to get convention-based WPF styling, it hurts. I haven't found a good way to do it.
RC: It's interesting, yeah. This is an epiphany for me.
JK: It doesn't have anything that came to CSS. CSS is not perfect, but the ability to specify essentially conventions throughout and be able to heavily modify your layout between...
RC: Well, you know what? I want my CSS Zen Garden for WPF.
JK: Exactly.
RC: Here's a common set of functionality, now skin it, go nuts, show me the different ways you can actually render this. That to me would be very exciting and get us closer to this sort of paradigm. Because HTML seems to have worked itself out, mostly around -- I think jQuery has been the breakthrough.
JK: Yeah.
RC: Between CSS and jQuery, suddenly web development doesn't suck. This is weird.
CF: So why do you think Microsoft… implemented it the way they did? Is there any possible reason for it?
JK: Because historically they've been very much centered around the IDE, around drag and drop.
CF: So you think the people they got to do the styling had no experience to CSS?
JK: I don't know who they got to do the styling. You would hope that they would have looked at that. It just seems like WPF is very, very strong. It has excellent layer capabilities. The things that you can create with it are phenomenal. The styling story is just really poor. Unless you're coming from -- if you're coming from a Blend type of environment where you got a designer who explicitly like clicks on every elements and says I want this styled this way, I want this styled this way, that type could take control.
RC: Right.
JK: Yes, WPF will do that. But the sort of I want to use the style sheets on this application, it's pretty rough.
RC: Yeah. And the idea of re-skinning an app in WPF seems impossible.
JK: I really haven't seen people successfully do it. Actually the one example I have seen and it was a fair amount of work was on NH Prof where he did NH Prof, EF Prof, L2S Prof his profile or series.
RC: Right.
JK: They've all got the same code base and they have a different look, basically a different color scheme but there's this varying in the styles.
RC: Yeah. So all the same controls, it's literally it is just changing colors.
JK: Yes. But I haven't seen anything akin to CSS Zen Garden done with WPF.
RC: No, and I think that's really --it's almost like a milestone. In a lot of ways Zen Garden was about showing how much the separation of concerns really worked.
JK: Yes, and I think that will come to WPF. It's just going to take some time.
RC: Yeah. I just wish it would take less time.
JK: I know.
RC: I want it to work because I believe in it from the perspective of getting away from GDI 32, about GPU acceleration being native to the operating system. The stuff just should all just work.
CF: Right.
RC: And as long as it is as difficult as it is right now, the adaption is going tend to be tough and success stories are going to be exceptions. You're hinting at this idea of you want to create a set of tools where people fall into the pit of success, where you really got to work hard to screw up the UI and add that WPF is not there, you really got to work hard to make UI work at all.
There's much more: Listen to or read the full interview here.
Richard Campbell and Carl Franklin (both Microsoft Regional Directors) are the voices and brains behind .NET Rocks! (www.dotnetrocks.com). They interview experts to bring you insights into .NET technology and the state of software development. They’re more than dry technical interviewers—they have fun!