Consider a plain read-only, HTML rendering razor script with a good amount of HTML, over a page long. Nothing unusual and it works perfectly fine as it is:

The code in this post is for Umbraco MVC (4.10+), but it’s concepts apply to all versions of Umbraco.

<...lots of tags above this point...>
<div class="widget">
    <h4>Recent Posts</h4>
    <ul>
        @foreach (var blogPost in Umbraco.TypedContent(1068)
            .Children().Where(t=>t.IsVisible()).OrderByDescending(t => t.CreateDate).Take(10))
        {
            <li><a href="@blogPost.Url">@blogPost.Name</a>
            @foreach (var item in blogPost.GetPropertyValue<string>("categories").Split(','))
                { <span>@item</span> } </li>
        }

    </ul>
</div>
<...lots of tags beneath this point...>

A few things that can be made better here as I see it:
- The recent blog posts widget can be separated from the rest of the view into a reusable partial.
- Intentions are not clear, what exactly are we trying to do with the chained methods?
- Hard coded node number 1068, what if we change that one later?
- Lot of C# mixed inside HTML makes both the HTML and the C# harder to read and problems harder to find.

I suggest:
- Separate the code into a partial / separate razor script, give it a name and or a location that both describes the type of HTML it renders aswell as the content, for example “Widgets/RecentBlogPosts.cshtml”.
- Move all C# code, but a bare minimum to the beginning of the script.
- Specify the intent with the code being used by using good names, close to what it is described as on the actual site, or in the specification to the customer.
- Stay away from hard coded node numbers.
- Use C# Linq with Lambdas together with typed content. It’s a great syntax to express Umbraco content queries.
- Use the .Select method, together with anonymous object to return exactly what you need, i.e. arrays and objects with only simple types. This will help you make clear what you need and will show you possible problems early.

Main cshtml:

<...lots of tags above this point...>
@Html.Partial("Widgets/RecentBlogPosts")
<...lots of tags beneath this point...>

Partials/Widgets/RecentBlogPosts.cshtml:

@{
  var blogPostsRootNode = Model.Content.AncestorOrSelf(1);
  var recentBlogPosts = blogPostsRootNode.Children
    .Where(t=>t.IsVisible())
    .OrderByDescending(t => t.CreateDate)
    .Take(10)
    .Select(p => new
    {
      p.Url, 
      p.Name, 
      Categories = 
        (p.GetPropertyValue<string>("categories") ?? "")
          .Split(',')
    });
}
<div class="widget">
    <h4>Recent Posts</h4>
    <ul>
        @foreach (var blogPost in recentBlogPosts)
        {                                                            
            <li><a href="@blogPost.Url">@blogPost.Name</a>
            @foreach (var category in blogPost.Categories)
            { <span>@category</span> } </li>
        }
    </ul>
</div>

What about separate model, view and controller classes?
The C# part of the script is building a ViewModel and, as such, could be placed in a C# model file, which in turn could be instantiated from the controller file firing up the view file.

We certainly could. And we could create a strongly typed view, and unit test the controller and the model. But would it really help us for this kinds of scripts that only show content – and does not deal with posted data?

I don’t think so. I found the approach described in this blog post be good amount of separation of concerns for views like this, I would very much like to hear experiences / opinions / examples from you, dear reader!

Happy coding

I’m currently trying to collect my thoughts about what I could have done better, and what to change for next project (or for refactoring the same project). One thing is the team. I was the developer for both client and server side + the UI&UX designer (or rather “Bootstrap-devsigner”), and it would probably be better to be at least two persons for this kind of a project.

I’m rather pleased with the server side. ServiceStack makes it pretty easy to build a well structured, easy to maintain api. I’m using it together with the PetaPoco microorm, and legacy Poco’s. I would probably have choosen ServiceStack’s own MicroOrm if I was to redo it now. Since I ditched most of my legacy code anyways.

For the client side I’m pleased with the application, but the road there was a bit rocky. And the maintenance will be a bit harder than it should. So for the future I decided to find and choose a good client side framework.

Currently it looks like I’m going to choose AngularJs, which seems to get increasing popularity for each day, and I hear good things about it from pretty much everywhere. Plus I like the Angular team opinions and ideas. The main alternative is Backbone+Marionette. I already use some of backbone, and adding more of it + Marionette in iterations would probably be easier and more seamless than moving to Angular.

The client side language is Typescript, which I’m very happy with. The tools failed me a few times, nothing to write home about, but as it is still preview some problems was expected.

To be continued…

This is my application structure:

• main.ts (contains bootstrap startup code, reference to refs.ts)
• refs.ts (contains all references)
• modules… (contains only a single ref, to refs.ts)

With this structure I run the instruction

TSC refs.ts --out refs.js

To get refs.js with all code from all referenced files. The refs.ts has all references in order (where necessary).

On deploy to the live site I simply minify the refs.js.

With this I only need to include <script src=”refs.js”> in my html.

I have the command to compile with –out as an external tool in Visual Studio. It would be nice to have it included in Web Essentials. I have disabled “create typescript on save” in my web essentials.

When I add a new module I need to remember to include it in refs.ts. After that it’s available globally in my application, and it will be included in main.js.

I also need to remember to re-build the solution (or run my custom tool) before I test run (parts of) the application after editing a file.

Cool thing is that TSC.exe (that comes with the Typescript installation) has a -e option to execute a file. So you can simply write:

tsc -e somefile.ts

That command will compile the .ts to .js and execute that js.

But we also like to be able to see some generated output. We can do that using the IO object that TSC creates for us. So let’s write a small ts file:

declare var IO;
IO.print("hello world");

Execute that one and you get “foo” in the console. Add the TSC -e command as an external tool to your Visual Studio and you have a useful shortcut to execute whatever ts you like.

A few useful functions within IO:

IO.readFile(path:string):string;
IO.writeFile(path: string, contents: string): void;
IO.print(value:any):void;
IO.printLine(value:any):void;
IO.dir(path:string):string[];
IO.fileExists(path: string): bool;

Full IO.d.ts in this gist. (It’s auto-generated from the TypeScript source.) However – to use the d.ts (instead of the anonymous declare var IO;) you need to use a rather strange workaround currently (I expect it to be fixed soon?):

Workaround to use io.d.ts in current version of Typescript

Create an empty file to reference to (for example empty.ts). And add refs to that file aswell as to io.d.ts:

/// <reference path="empty.ts"/>
/// <reference path="io.d.ts"/>
IO.print("hello world");

Then execute it with the –out parameter:

tsc -e somefile.ts --out somefile.js

First download PhantomJs from http://phantomjs.org/ and extract the folder. Copy the path.

Next open Visual Studio and open the menu Tools > External Tools

Add a new tool, give it the title Phantom&Js (the ampersand makes you get an alt-shortcut for the letter J in the menu).

Paste the path to your phantomjs.exe as the command, add $(ItemFileName).js as the filename and add $(ItemDir) as the initial directory.

The explicit file extension (.js) makes typescript files work just fine, we cannot send the actual .ts file to PhantomJs, so we need the typescript compiled .js (use WebEssentials to compile to .js on save).

Check the “use output window” to get the console result there.

Next add a small typescript file, sample code in this image, the actual test code is below the class, simply a value output’ed with console.log:

Save the file. Now run the script from the Tools menu, or hit Alt+T,J .

You should get the result “hello Foo” in the output window.
 

phantom.exit(); is necessary to stop the execution. (Otherwise you can do that from the tools window.)

Add a REPL
Cool – but what if you like to play with the code in a console window? That is also possible since PhantomJs can be run in “REPL mode”. To do that, just create another external tool. With the following values:

Title : Phantom &Repl
Command : the path to phantomjs.exe
Filename : empty
InitialDirectory : $(ItemDir)

Do not check the use output window checkbox.

Now when you hit Alt+T+R you will get a command prompt with a phantomjs> prompt.
Try writing some code:

var foo = "bar";
console.log(foo);

You should get the result “bar” inside the console.

You can also load your own scripts into the repl using the injectJs function:

phantom.injectJs("somelib.js");
var test = new MyAwesomeClass();
console.log(test.Whatever());

Check out the PhantomJs site for more information.

Note: I tried to get the Nuget Package Manager console to behave nicely with PhantomJs Repl, I could not do that as the output pipeline is not redirected to the console host, I guess a Powershell guru can fix that pretty easily (it does work in std PowerShell).

Add a field to the dev database. Add the property to the DTO. Deploy a new version of the dev dll’s. And later repeat the same thing for the production database and deploy the dll scheduled at night to the production web server.

Small thing? Why complain? Well, when I’m into client side flow dev, I dislike leaving my comfort zone for quite some time just to do such a futile task.

Both ways helps in making the HTML code DRY and well structured. But an important difference is a RenderPage file can be wherever we want, and changes are fluent (no app restarts). We do loose strongly typed parameters but I think that is a small price to pay when we are doing Html functions. We can still send a typed viewmodel to the rendered page. What about performance? As far as I understand we will get a performance hit the first time we call the page after a save (generally much quicker than a app restart tho). But after that it’s on par with a global helper. Correct me if I’m wrong.

This is the basic syntax :

@RenderPage("/path/to/SomeTypedView.cshtml",someObject)

And in the SomeTypedView.cshtml :

@{var viewModel = (SomeType)PageData[0]; // mimic strongly typed view}
<div="phew">@viewModel.Name</div>

But the RenderPage-code is rather ugly. Let’s make a small global helper to make the syntax nicer:
/App_Code/Tmpl.cshtml:

@helper Display(object value, string templateName="") {
    if (templateName=="") {
        templateName = value.GetType().Name;
    }
    @PageContext.Page.RenderPage("~/Shared/DisplayTemplates/" + templateName + ".cshtml",value)    
}

It’s using a defined path. And it also checks the type name if we do not specify it. So the two following instructions makes the same result:

@{var myObj = new MyType();}
@Tmpl.Display(myObj,"MyType")
@Tmpl.Display(myObj)

They both renders /Shared/DisplayTemplates/MyType.cshtml

Introducing RazorTemplates

Can we extend this further, using dynamics to write:

@tmpl.MyTemplateName(someModel)

…as a way to render the /DisplayTemplates/MyTemplateName.cshtml with someModel ?

Yes we can, check out DynamicHtmlTemplates in this gist, [Update: or the Umbraco RazorTemplates package which is basically the same, but evolved a little bit to an Umbraco context - also automatically picking up NodeTypeAlias to render file according to document type.]

Put DynamicHtmlTemplates in your App_Code and you can use:

Cool eh?

@using DynamicHtmlTemplates
@{
 var myobj = new MyClass{Name="Someone", Value="123"};   
 dynamic tmpl = new Templates();
 // or dynamic tmpl = new Templates("~/Path/ToTemplates/");
 // or dynamic tmpl = new Templates("SubPathToTemplates");
}
        
Rendering /DisplayTemplates/MyClass.cshtml (sending myobj to PageData[0])
@tmpl.Display(myobj)

Rendering /DisplayTemplates/MyClassAlternative.cshtml  (sending myobj to PageData[0])
@tmpl.Display(myobj, "MyClassAlternative")
        
... or let it use Dynamic to figure out the template name:
Rendering /DisplayTemplates/MyClassAlternative.cshtml  (sending myobj to PageData[0])
@tmpl.MyClass(myobj)

Rendering /DisplayTemplates/MyClassAlternative.cshtml  (sending myobj to PageData[0])
@tmpl.MyClassAlternative(myobj)
        
Rendering /DisplayTemplates/Possible.cshtml (sending inline razor item template to PageData[0] and list to PageData[1])
@tmpl.Possible(Templates.ItemTemplate(@<text>this is @item</text>),new List<string>{"one","two"})

Contents of /DisplayTemlpate/Possible.cshtml:        
<div>
    @foreach(var item in PageData[1]) {
        @PageData[0](item)
    }
</div>

So with this, a bootstrap form can be created in a much more DRY way:

Tested in Umbraco 4.71 and Umbraco 6.02 as well as a vanilla WebPages site

Here is one way – that works fine in WebPages Razor v1 (not MVC, and not WebPages Razor v2) – use the CreateInstanceFromVirtualPath method to create an instance of an existing cshtml page, and call methods within it. Like this:

@{
    dynamic hlp = WebPageBase.CreateInstanceFromVirtualPath("~/dev/SharedHelpers.cshtml");
}       
@hlp.SomeHelper()

You can use this together with razor code aswell, as I write about in another article. But to call a dynamic function with a Func (as the razor code behaves as) you need to cast it:

@hlp.SomeHelper(new Func<string, HelperResult>(@<p>foo</p>))

Unfortunately using CreateInstanceFromVirtualPath this way is “not supported”

If you find yourself adding the same boilerplate code over and over again in your razor scripts:

<div class="this">
  <div class="that">
    foo
  </div>
<div>

You’ll do yourself a favour if you add a helper:

@helper DivThisThat(string contents)
{
    <div class="this">
        <div class="that">
            @contents
        </div>
    </div>
}

Which means you can write:

@DivThisThat("foo")

- Ok. But. What if we want this to be available globally? In every Razor script.

Just add the helper to a Razor file inside the App_Code folder, call it /App_Code/GlobalHelpers.cshtml , that way you can use it everywhere like:

@GlobalHelpers.DivThisThat("foo")

- Ok. But. Simple text is not enough, I like to use this and include custom razor.

Like this:

@GlobalHelpers.DivThisThat(
  @<div class="thus">foo</div>
)

You can, just change the signature of your helper to this:

@helper DivThisThat(Func<string, HelperResult> template)
{
    <div class="this">
        <div class="that">
            @template("")
        </div>
    </div>
}

- Ok. But. What’s that empty string?

It writes text out to your template. Let’s say you like to do a helper for displaying a list, and you like to optionally write something special if the list is empty. Then you can create this helper:

@helper ListIfContent(List<string> someList, Func<string, HelperResult> liTemplate, Func<string, HelperResult> emptyTemplate)
{
    if (someList.Any())
    {
    <ul>
        @foreach (var i in someList)
        {
            @liTemplate(i)
        }
    </ul>
    } else {
        @emptyTemplate("")
    }
}

Use like this:

@GlobalHelpers.ListIfContent(someList,@<li class="whatever">@item</li>,@<p>No data</p>)

And the result is this if the list is not empty:

<ul>
  <li class="whatever">one</li>
  <li class="whatever">two</li>
</ul>

And this if the list is empty:

<p>No data</p>

Notice “@item” in the first template, that’s where the helper writes the string content.

- Cool. But I tried it and got errors:

@GlobalHelpers.DivThisThat(
  @<div class="thus">foo</div>
  @<div class="the">bar</div>
)

You can only add one helper result to the function, but you can easily use them together by adding the text tag:

@GlobalHelpers.DivThisThat(@<text>
  <div class="thus">foo</div>
  <div class="the">bar</div>
</text>)

Data is easy to store locally in localstorage. But localstorage is not good for images. There’s a limit of 5 mb’s. FileApi? Yes, seems like a good candidate, but not on iOS Safari, which is a requirement, it cannot do filewrites.

My current shot is to keep the page open and keep the files in a DataForm variable until the user goes online again. The page must be kept alive. But I think we can live with that (it is a single page application). And in worst case, the users just need to find the images from the local disk again. Another alternative is to use createObjectUrl(), which generates a temorary url to a local file, the url is easy to store in localstorage. But, those urls are only valid during the document lifetime. Don’t understand why. Should at least be an option to keep them longer. A more robust alternative for the iPad would be to rely on some native application to keep the files for us. I think PhoneGap can do that, but I’m not sure.