Heading Down Easy Street With HTML Helpers

When ASP.NET MVC was unveiled, it came with some helper methods that can make repetitive HTML generation tasks a breeze. These helpers exist in the System.Web.Mvc namespace. You see they helpers used often with Razor, but they can be used with any view engine. For an example of their usage with another view engine, take a look at my previous article about using the Spark view engine.

The most common task achieved with the HTML helper methods is to generate an input element. There are a variety of helpers for specific inputs. For example, one can generate a textbox for a property on a given view’s model. Each one of these input specific helpers has a loosely typed and strongly typed version.

Below is an example of the loosely typed helper method for a textbox. The initial parameter is a string that corresponds with a property name on the view’s model. The second parameter is a value for the textbox, and the value of the model property will be used, since null was specified. Finally, the third parameter allows one to specify attributes on the element that will be generated.

The next example shows the strongly typed helper method for a textbox. Notice that the first parameter is a lambda expression that specifies a property on the view’s model. No value parameter is specified in this example, as it is automatically pulled from the model’s property.

The HTML helper methods also include templated helpers, such as editor and editorfor. These helpers will pick the appropriate HTML markup for a given property. In addition, you can influence them by using the DataType attribute, which is found in the System.ComponentModel.DataAnnotations namespace.

Below is an example of setting up a property on a view model so that it can be output as a multiline textbox when combined with templated helpers. Using this class of attributes, you can influence the rendering of your properties in a number of ways.

Here is the corresponding templated helper being used in an editor view for the same view model.

As if those features weren’t enough, you can also extend the HTML class with your own custom helpers. All that you need to do is to add a new static class to your project with one or more static extension methods. This is a very powerful feature and can be leveraged to achieve even greater streamlining of markup generation and reduction in code duplication.

Below is an example of a custom helper that is used to generate HTML 5 figure markup. Note that the extension method can take multiple parameters and apply them to the generated markup. In this case, the extension method takes an image URL and a caption describing the image.

The custom helper method could be called in the corresponding view using the following syntax.

HTML 5 offers a number of new markup options that you could leverage within custom HTML helpers. If you’d like to learn more about HTML 5, I recommend that you read Training Guide Programming in HTML5 with JavaScript and CSS3 (MCSD): 70-480 (Microsoft Press Training Guide). I found it to be quite helpful in bringing me up to speed on new HTML 5 features and functionality, particularly in terms of providing practical exercises.

HTML helper methods have proven to be one of many great additions that were included with the roll out of ASP.NET MVC. Using the helpers is certainly easier than constantly writing out all of one’s HTML markup by hand. The fact that you can customize the output of the helper methods with templated helpers makes this feature even better. Finally, being able to create your own custom helper methods makes HTML helpers hard to beat. If you’re not already taking advantage of them, regardless of the view engine that you’re using, get started today!

Spark View Engine

This week I am continuing my exploration of view engines by taking a closer look at the Spark view engine. I wanted to find at least one third party view engine that I could play around with and Spark seemed like potentially the best candidate. Spark was released before Razor, and it appears that it was last updated in June 2015. The good news is that there is a NuGet Package that allows you to use Spark with MVC 5. This helps to make it at least usable with current versions of Visual Studio.

One of the primary goals with Spark is that HTML comes to the forefront in the markup with less intermixed code than was seen with the ASPX view engine. Part of the driving force behind this implementation was that ASPX pages would be more and more difficult to maintain and read as time went by and they grew in size. The view engine was authored by Louis Dejardin and based on comments and search results, I’m going to guess that it was at one time the most popular third party view engine.

In my most recent post, I mentioned refreshing a classic ASP.NET tutorial web application, the Movie App. I had brought this project up to speed using MVC 5, so that I could use it as a basis for other experiments. I figured that a perfect usage for this would be to convert my previously created version of the Movie App to leverage the Spark view engine.

Getting up and running with Spark was not too tough. I started out by referencing the previously mentioned Spark.Web.Mvc5 NuGet package. After that, I updated my Global.asax.cs, removing all other view engines from usage and adding the Spark view engine. This would be the approach that you would want to take if you were wanting to using only Spark. If you wanted to also use Razor or ASPX, you would not bother to clear out the existing view engines.

As an optional step, you can add a spark section to your Web.config. Take a look at the configuration documentation for more details on what you can do there. I did read that setting the debug setting to true can be helpful in troubleshooting view compilation errors, so you may want to consider using that setting.

After modifying the configuration, I needed to make a few changes to the file structure under the Views folder. First, I had to rename all the views to *.spark, so that they would be recognized by the Spark view engine. Second, I deleted _ViewStart.cshtml, as it is not used by Spark. Third, I renamed _Layout.cshtml to Application.spark. Spark automatically looks for a layout file by that name. Finally, I had to add a reference to System.Web.Optimization in the _global.spark file that was added when I referenced the NuGet package. This enabled me to reference Styles.Render and Scripts.Render.

The next step, and the most involved step, was to replace the existing Razor syntax in all of the views with Spark syntax. One of the things that pops out at you right away is that several of the C# constructs, such as if and for are replaced by markup that looks like HTML. This does contribute to the readability of the document. Below is one example of a view that I updated, the movie creation view.

The Form tag in the above example leverages another important feature of Spark, bindings. You can create a binding that will replace HTML-like markup with C# code. In this case, I created a binding that could wrap some HTML with the appropriate code needed to render a form. This binding is defined within Bindings.xml, which sits in the Views folder. Below is the example binding that I created.

After setting up the binding and replacing the existing Razor syntax in the views, I was pretty much set to go. With a minimal amount of effort, I once again had the Movie App running, but this time using Spark syntax. Despite the fact that Spark hasn’t been updated in several years, it is still a fairly painless experience to get started.

Would I choose to use Spark over Razor? Probably not. I’ve already got some amount of Razor experience and I didn’t see anything compelling enough to persuade me to change. However, it is nice to know that you have options, and I can see how Spark was an attractive alternative to ASPX. The HTML-like markup does make it easier to read than a complex ASPX view.