This evening I gave a presentation at the St. Louis DotNetNuke user group. What follows is a summary of that talk. It is intended to be a high level introduction to Razor. I want to provide a bit of history, point out all of the moving pieces, and relay enough information so that those unfamiliar could jump in and get started with Razor in DNN.
The Story of Razor
Is Razor a view engine? A scripting language? A templating syntax? Well it depends on how you use it - it’s all of those things in different contexts. Razor was introduced as a new view engine for ASP.NET MVC in July 2010. It is also incorporated into Web Matrix with its cshtml and vbhtml Web Pages. More recently, it has been within third party applications built on .NET, most notably DotNetNuke and Umbraco.
Putting your code in HTML
Razor is a simpler and smarter way to embed code in HTML. The act of writing code and embedding it in HTML is debatable itself, but that aside, if you’re going to do it, you’d be better of using the Razor syntax than that of ASPX Web Forms – simply because it was built from the ground up (quite recently) to do just that.
Razor comes with smart defaults to help users be successful. Data being rendered on the page is automatically HTML encoded for you – because that’s what you want. With Razor - you don’t have to write code to “do the right thing” – it knows the right thing to do already.
Even though you’re writing code in your html, you’d probably best serve yourself by keeping it as clean and readable as possible. Razor makes it easy for developers to create helper methods, so that they can embed less code in their html. You can define a simple helper method once, and re-use it in several places.
Uses of Razor
As a View Engine
In the MVC world – the view is pretty dumb. It knows how to render html on the screen and perform minimal dynamic tasks in order to accomplish that task. So in the world of ASP.NET MVC, Razor acts (mostly) as a templating engine – allowing you to display your dynamic content. Of course you can get crazy and write as much code in your views as you would like, but that’s not the intended use case.
As a Scripting Language
In the context of Web Matrix, DotNetNuke or Umbraco, Razor acts as a scripting language. It serves as both a templating mechanism to display dynamic content and the way you build dynamic functionality. While you can certainly leverage libraries and API methods, the strength of Razor as a scripting language is to act as the glue that binds those external resources (web requests, DNN API methods, database calls) to your markup.
Razor in DotNetNuke
Getting going with Razor in DNN isn’t hard, but you do need to make sure your environment is set up properly.
Razor Host Module Usage
After you’re set up, you can start using the pre-installed Razor scripts found in the DesktopModules/RazorModules/RazorHost/Scripts folder. You can also create your own. Use them by placing the Razor Host module on a page, navigating to “Edit Scripts” and selecting the script you would like the module to render.
Packaging as a DNN module
You also have the option of registering a user control that inherits from RazorModuleBase with DotNetNuke as a module – and therefore creating your own DNN module that is really a Razor script. All you would need to do is make sure the Razor script file is named appropriately.
To set this up – the razor file should have the same name as the user control, only with a leading underscore. For example: MyUserControl.ascx would have a _MyUserControl.cshtml file next to it in the file system. Because the user control inherits from RazorModuleBase, it will look for and invoke that razor script when the control is rendered on the page.
Razor is a lot of different things to a lot of different people. To ASP.NET MVC developers, it’s a view engine used to simply and cleanly render their data. To those that are new to the Microsoft Technology stack, it’s a scripting language that allows them to make their web pages dynamic and render it as html. To a DotNetNuke developer, I believe it’s another tool in the toolbox. It’s another approach to create dynamic functionality – one that naturally lends itself to quickly building out small(ish) modules where the “traditional” development process may be considered overkill.
This post is intended to provide a brief introduction, for further research and insight, I suggest the following: