Scott Gu's blog has a much more comprehensive look at this engine:

http://weblogs.asp.net/scottgu/archive/2010/07/02/introducin...

Much better, thanks!

They really needed to do this. The ASPX view engine just felt like they took existing code and shoved it in to the MVC framework.

A fresh start was needed, and it looks great.

It'll be interesting to see how they incorporate unit testing.

Views are notoriously hard to test - a lot of that comes down to "does it look right", which is not automatable.

The MVC pattern is already a lot more unit-testable than most, since the view is separated from the rest, and data (viewModel) and processing (controller) can be tested without the view.

I probably should have said that as a reply to the Scott Gu article.

From that article: "Unit Testable: The new view engine implementation will support the ability to unit test views (without requiring a controller or web-server, and can be hosted in any unit test project – no special app-___domain required)."

I was wondering how that would work, since as you said, they're notoriously hard to test.

I think the main point with testable views is that the default asp.net view engine is completely coupled to the asp.net runtime. It was impossible to instantiate a view engine instance and render a view inside the test framework without creating a special app-___domain in which to host the test.

I had to wrestle with this just last week, it was a major pain in the ass to work around this limitation.

Razor is a major step in the right direction. Spark view engine still offers enough punch for me not to switch to Razor just yet. The stuff that you can do with bindings and the convention over configuration stuff are still killer features for Spark.

Am I the only person who sees this and says, “Congratulations guys, nice work! Now if only you had done this in 2006, you might be on the cutting edge.” I don't mean to disparage their work, I am sure that is is technically sound and well-considered.

It seems like, among the leading-edge developers, this kind of tempting is rapidly being eschewed by newer techniques.

I cannot understand your last sentence. Please help. "This kind of tempting?" "Eschewed?" Eclipsed? Eschewed in favor of?

There is this running gag where I use an ipad on a train and messages get garbled. Sorry, but its too funny and too late to correct. Try typing "templating" on an iPad, it will complain.

The correction is, of ourselves, "this kind of templating is being eschewed by other, newer techniques." Enlive by cgrand is the example I like to mention.

You fail sir, you cannot disparage their work for being old and say it is being 'eschewed by newer techniques' without providing some examples.

An example: Enlive for Clojure. This is a really awesome technique.

Maybe you want something like this: http://code.google.com/p/nhaml/

the new Dynamic View and ViewModel properties is a great addition to mvc3

Why? In particular Dynamic view models? What is the benefit of adding this third way of expressing your view model objects?

Clearer syntax. No need to define another ViewModel object for each page. Ability to refactor. Getting rid of naming the param as text.

ViewModel["Something"] = "Other";

vs

ViewModel.Something = "Other";

The best use case for dynamic IMO.

While I think this is a neat use of dynamic, I think I'm still going to stick with my strongly typed models.

More specifically, I really like the 'ViewModel' technique. I won't give up my Intellisense and Compile Time validation anytime soon.

The more I see stuff like this, the more I think the lift concept of view first and XML is better than the MVC model.