views:

57

answers:

2

My background is mostly in desktop applications on the Microsoft platform. I've been working a lot with ASP.Net MVC lately and completely skipped over learning webforms. I find I'm having the most trouble (not being a web guy) with writing my views in MVC. How proficient should I be with HTML and javascript to write good views in MVC? Also, is the standard Webforms view engine what I should go with, or would I have an easier time using the Spark view engine, given my background?

A: 

You'll need a good understanding of HTML, JavaScript (and jQuery most likely) and CSS for most web work these days. It doesn't matter if you are using ASP.Net MVC w/ Spark, default engine or other technologies like PHP. In the end, the browser only understands HTML, JavaScript and CSS, the other stuff is just to assist in creating that final output, but you still need to understand what you want to be generating.

Regarding view engine, if you are working on learning for future use rather then for an immediate project you want to put into production ASAP, I'd suggest taking a look at Microsoft's upcoming view engine Razor.

http://weblogs.asp.net/scottgu/archive/2010/07/02/introducing-razor.aspx

It is being built for the ASP.Net MVC 3 release taking lessons learned from Spark, NHaml and the default view engine.

From the article:
Design Goals

We had several design goals in mind as we prototyped and evaluated “Razor”:

  • Compact, Expressive, and Fluid: Razor minimizes the number of characters and keystrokes required in a file, and enables a fast, fluid coding workflow. Unlike most template syntaxes, you do not need to interrupt your coding to explicitly denote server blocks within your HTML. The parser is smart enough to infer this from your code. This enables a really compact and expressive syntax which is clean, fast and fun to type.

  • Easy to Learn: Razor is easy to learn and enables you to quickly be productive with a minimum of concepts. You use all your existing language and HTML skills.

  • Is not a new language: We consciously chose not to create a new imperative language with Razor. Instead we wanted to enable developers to use their existing C#/VB (or other) language skills with Razor, and deliver a template markup syntax that enables an awesome HTML construction workflow with your language of choice.

  • Works with any Text Editor: Razor doesn’t require a specific tool and enables you to be productive in any plain old text editor (notepad works great).

  • Has great Intellisense: While Razor has been designed to not require a specific tool or code editor, it will have awesome statement completion support within Visual Studio. We’ll be updating Visual Studio 2010 and Visual Web Developer 2010 to have full editor intellisense for it.

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

For ASP.Net MVC 3 Preview 1, take a look at http://weblogs.asp.net/scottgu/archive/2010/07/27/introducing-asp-net-mvc-3-preview-1.aspx

ManiacZX
+1  A: 

Specifically on the subject of View Engines, if you're looking to introduce code blocks into your views, then Razor would be the neatest way of doing that.

I guess, given your background, the next question would be - "how do I know if I want to introduce code blocks into the view?" - the answer I'm afraid can only come to you with a lot of pain an experience. Many people have written blog posts explaining the dangers of code blocks mixed in with markup that leads to a nightmare commonly referred to as Tag Soup.

All that Razor (and Webforms for that matter) does for you is bring the power of the entire C# or VB.Net languages into the view in a way that prescribes abundant usage. This is what leads to the Tag Soup problem.

But it seems there are still die-hards out there under some kind of illusion that you can actually keep your views clean in the long term by using this method. If you are working on the code alone, and forever, then I'd tend to agree that it is possible, but only then with the mind-numbingly depressing levels of concentration and determination.

If however, you'd like to keep you views for markup with the code abstracted away to where it can be less tempting to put a "quick fix in here" and a "hack in there", then I'd highly recommend that you skip over the code-centric view engines and go with Spark.

In terms of answering your question directly, you can find plenty of tutorials from beginner to advanced. Here are some of the ones I'd recommend in blog and video formats:

Anyway, I hope that gives you enough to make an informed decision.

Best of luck in your dabblings!

Rob G

RobertTheGrey