Use RenderPage to Split and Reuse your Razor-Views/Templates or to use Conditional Sub-Templates

4/25/2016

When your Razor gets a bit more complex, you'll either want to split your files a bit to organize them better, or move partial views/templates into separate files. This is very easy using @RenderPage.

I'm writing about this, because many people somehow don't seem to know about this - so it's simple, but important.

The Basics of RenderPage

This is more or less all you have to write

RenderPage("_2SexyContent Feature - List.cshtml")

or often inside a div/span etc:

<div>@RenderPage("_2SexyContent Feature - List.cshtml") </div>

And I'm sure you guessed it: the stuff in the quotes is a file, relative to the location of your initial file. Simple, right?

Simple Stuff: The Result

Remember that razor and ASP.net Views (MVC, Core, etc.) are basically just a few simple objects passed around. So the result of RenderPage is a HelperResults string. This means that if you just render the result to as part of the page, the HTML will be used as is (just what you want). But if you would use the result in any kind of string-manipulation, you'll have to @Html.Raw(...) it first, to ensure the HTML can be used.

A Dit Hard: Parameters

If you want to use sub-views a bit like an external template expecting some parameters, you can just add that to the call, like

@RenderPage(url, data)

Data can be anything you want it to be, like a single value or a dictionary of values which the internal template expects. The internal template will be able to use this data by accessing the variable PageData. So you could create a simple CSHTML which simply expects a list of items and generates a table for that.

The Hard Stuff: Data for the Sub-View

This is so simple, that people tend to forget what's happening behind the hood, and are then surprised when things work a bit differently. So I want to help you understand what really happens. Basically if you want the sub-view to have much more than just the parameters, then the Razor-Host which runs the main page must do that for you. Here's some stuff you may want in your inner template

DNN objects
Helper commands like AsDynamic
The full set of data which the original view had
Webserver stuff like the Request object

This sound logical and obvious, and it's basically all taken care for you...if you use the right razor host. Because the Razor-Host itself MUST take care of this. Otherwise it ain't gonna happen. So if you're using this method and feel like you're missing something.

The default razor host of asp.net will do a bit of this, the razor-host in DNN will do a bit more. The 2sxc-razor host will ensure that all inner templates have access to the full, initialized set of information which the main template had. Because of this you can easily create a list-template and a view-template, and call them from the main file as you need, like in the following example:

Example with conditional (if) to choose between list / details

@if (Request.QueryString["id"] == null)
{
    // Note: the code inside _List.cshtml could also be inserted right here
    // I just took it out to make everything a bit easier to read
    // The Render-Page will execute that CSHTML 
    // the 2sxc-host automatically provides all the data of the hosting-view
	@RenderPage("_2SexyContent Feature - List.cshtml");
}
else
{
    // This one will also execute another CSHTML, but will add a variable with the URL-parameter
	@RenderPage("_2SexyContent Feature - Details.cshtml", Request.QueryString["id"]);
}

Recommendation for View-Switching

So basically this is all you need to do. Now you'll probably say: why do I need this, there is a setting in the view to automatically switch views (see pic). In reality the auto-switch does exactly the same thing as this code does, and it's ideal for simple use cases. But there are more advanced cases, where the automatic process can actually become a problem.

For example, if the developer wants to place multiple content-items on a page, then in can happen that they all listen to the same url-parameter to switch views. In such cases you can't use auto-switching and will revert back to your own mechanism.
There are also cases where the developer wants more control over the sub-view - maybe based on user-login or something. In these cases too you need more controll.

Daniel Mettler grew up in the jungles of Indonesia and is founder and CEO of 2sic internet solutions in Switzerland and Liechtenstein, an 20-head web specialist with over 800 DNN projects since 1999. He is also chief architect of 2sxc (see github), an open source module for creating attractive content and DNN Apps.