ASP.NET MVC and the Spark View Engine Getting friendly with HTML in ASP.NET MVC just got a whole lot easier. In this article, I’ll delve into the Spark View Engine, an alternate view engine for the ASP.NET MVC Framework. Spark’s main goal is to allow HTML to dominate the flow of view development while allowing code to fit in seamlessly. Developing views for your ASP.NET MVC application should not be hard. However, as you develop your MVC application, you quickly come to realize that you are spending a significant amount of time developing the View. With each new feature that you implement, your HTML is becoming heavier and heavier and harder to read - this is known as the “Bracket Tax” (angle brackets that dominate your screen). The view is a conglomerate of HTML, output notation, binding and code brackets. Eventually the view ends up resembling “Tag Soup”. Looking at the view inside of Visual Studio resembles a mish-mash of yellow highlighting signifying some output notation or expressions. Put simply, it’s hard to look at and it is difficult to discern the intent of the code inside of the view. This article will expose you to the Spark View Engine’s inner workings. From basic output notation to Partials and Layouts, I will cover how to set up ASP.NET MVC to use the Spark View Engine. But first, a basic understanding of ASP.NET MVC is recommended. Why Another View Engine? Spark originated from a blog post - “Code Based Repeater” by Phil Haack, where a commenter stated that the Web forms view engine syntax was ugly. Louis Dejardin, the author of Spark, replied to the comment with his take on what a view would look like if the language could fit in seamlessly. (http://haacked.com/archive/2008/05/03/code-based-repeater-for-asp.net-mvc.aspx#67581) The default view engine in ASP.NET MVC is completely capable of rendering output as necessary for most projects including some very large sites. However, upon further looking at the Web forms view you will notice that the syntax for the default view engine is rather ugly. Your clean, elegant HTML rapidly becomes a confusing mess with the introduction of even the simplest loop structure, as shown below: <table>
<% var rowIndex = 0; %>
<% foreach (var order in Model.Orders) { %>
<tr class="<%=Html.GetRowClass(rowIndex) %>">
<td><%=order.OrderTotal %></td>
<td><%=order.OrderShipToZipCode %></td>
</tr>
<%rowIndex++; %>
<% } %>
<tr>
<td colspan="2">
Total: <%=Model.TotalOfAllOrders %>
</td>
</tr>
</table>
At first glance the intent of the view is not immediately known. After a brief inspection you can figure out that the HTML is displaying a table of orders with the order total, destination zip code and total of all orders. The row style gets changed via a custom HtmlHelper extension method Html.GetRowClass. The exact same view is much easier to read when using the Spark View Engine, as shown below: <table>
<tr each="var order in Model"
class="alt?{orderIndex % 2 == 0}">
<td>${order.OrderTotal}</td>
<td>${order.OrderShipToZipCode}</td>
</tr>
<tr>
<td colspan="2">
Total: ${Model.TotalOfAllOrders}
</td>
</tr>
</table>
The intent of the view is much easier to discern when using the Spark View Engine. This example illustrates many aspects of Spark, which I will cover in more detail in this article. Above, the HTML has dominated the flow of the screen and it reads like an HTML document. The idea behind the Spark View Engine is to allow the HTML to dominate the flow and the code to fit in seamlessly. A side effect of this approach to view development is readability. | " |
The idea behind the Spark View Engine is to allow the HTML to dominate the flow and the code to fit in seamlessly.
| " |
Looking at the code snippet above, it is immediately apparent what is happening. As a result of Spark’s output notation, the code is seamlessly placed into HTML resulting in a cleaner view. Juxtapose this with the default view engine output notation (angle brackets and percent signs) and it is immediately evident that Spark’s output is much more desirable as the resulting view is much easier to read and understand. The entire C# language is available in a way that doesn’t interfere with the harmony and balance of the markup. | & | | 
By: Donn Felker
Donn Felker is the Principal for Agilevent, a Microsoft Partner he founded in Minneapolis, Minnesota. He is an experienced Software Architect/Developer with over nine years of professional experience in various markets that include: entertainment, health, retail, insurance, financial, and real estate.
He is a Microsoft ASP Insider who currently holds certifications as an MCTS in Web Client Development for the ASP.NET 3.5 Framework, Certified Scrum Master and ITIL Foundation v2. He also holds a bachelors of science in Software Engineering. He writes, presents and consults on various topics ranging from architecture to agile practices to patterns and practices. He is the founder/coordinator of the Twin Cities Give Camp, President of the Twin Cities Developers Guild and the founder of Twin Cities Pragmatic Beer.
You can read Donn’s blog at http://blog.donnfelker.com
donn@donnfelker.com |