views:

471

answers:

3

I have looked at the usual suspects...Spark, NHaml, etc. They all seem to be syntactic sugar for those that are uncomfortable with the <% %> syntax. Are there any other tangible benefits? Syntactic sugar doesn't seem to me to be a sufficient reason to change out the entire view engine.

Reasons posted so far:

  1. Easier to transition from a different platform
  2. More natural context switching
  3. Better separation of concerns
  4. Fewer lines of code
  5. Better resistance against cross-site scripting
  6. Better XHTML compliance
+1  A: 

Syntactic sugar in what way? So that you can learn yet another syntax? No. These engines are of great use to developers migrating from other platforms. Makes their life much easier.

Robert Koritnik
How, exactly?....
Robert Harvey
I think Rob is talking about people who have used the mvc pattern in other frameworks/platforms. For example haml on RubyRails and nvelocity in Castle Monorail. They can transition to somthing similar to the view engines they are used to.
Simon
I think Rob made my point. For someone who is already in ASP.NET MVC, like me, this would not be a benefit.
Robert Harvey
But I can see how it would be very valuable for someone already familiar with the syntax.
Robert Harvey
Well, using the StringTemplate view engine is very useful to anyone wanting to strictly enforce Model/View separation in particular and MVC patterns in general. It isn't necessarily about transition or migration. http://websitelogic.net/articles/MVC/stringtemplate-viewengine-asp-net-mvc/
bzlm
Can strict model/view separation be claimed in the other alternate view engines as well? The code in StringTemplate is arguably pretty, but it still has to poke holes in the template to let the data through.
Robert Harvey
+6  A: 

The reason why people are uncomfortable with the <% %> syntax isn't that it contains alot of syntactic salt, but that it makes the Views code-centric, which can go against the MVC concept of making Views as dumb as possible. The goal of Spark, for example, is "to allow the html to dominate the flow and the code to fit seamlessly". So the tangible benefit is making it easier to follow the spirit of MVC.

<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
  <li each="var p in products">${p.Name}</li>
</ul>
<else>
  <p>No products available</p>
</else>

If the above is just syntactic sugar, then ASP.NET MVC itself is just syntactic sugar on top of ASP.NET Web Forms.

bzlm
In your example, p.Name is still being injected into the view (more or less) just like it would be in asp.net mvc's standard engine, except that ${} is being used instead of the angle brackets and percent signs. How is this any different?
Robert Harvey
It would be more accurate to say that ASP.NET views are syntactic sugar, not the entirety of ASP.NET MVC. ASP.NET MVC contains far more than just that.
Robert Harvey
Actually, I think I like this better than nHaml. It still looks like ASP.NET MVC, but it folds the code statements into declarative HTML properties. Is all of C# supported this way? :)
Robert Harvey
Almost. "CSharp code may be used to produce output. Any helper methods, object properties, or expression that evaluates to a non-void value can be used". http://sparkviewengine.com/book/export/html/4
bzlm
Isn't <ul if="products.Any()"> just syntactic sugar for c# code?
Robert Harvey
Something giving the sugar more than empty calories would be the fact the scope of the each="" and if="" is tied to the start and end tags of the element. As your html is well-formed so is your code, avoiding the <% } } %> scavenger hunts. There are more features as you look further, but in seven lines this gives you a pretty reasonable first impression.
loudej
+2  A: 

From the nhaml perspective

  • make views more succinct

Nhaml view (274 chars)

%h2= ViewData.CategoryName
%ul
  - foreach (var product in ViewData.Products)
    %li
      = product.ProductName 
      .editlink
        = Html.ActionLink("Edit", new { Action="Edit" ID=product.ProductID })
= Html.ActionLink("Add New Product", new { Action="New" })

aspx view (665 chars)

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" AutoEventWireup="true" CodeBehind="List.aspx" Inherits="MvcApplication5.Views.Products.List" Title="Products" %>
<asp:Content ContentPlaceHolderID="MainContentPlaceHolder" runat="server">
  <h2><%= ViewData.CategoryName %></h2>
  <ul>
    <% foreach (var product in ViewData.Products) { %>
      <li>
        <%= product.ProductName %> 
        <div class="editlink">
          (<%= Html.ActionLink("Edit", new { Action="Edit", ID=product.ProductID })%>)
        </div>
      </li>
    <% } %>
  </ul>
  <%= Html.ActionLink("Add New Product", new { Action="New" }) %>
</asp:Content>

It does this through a series of shorthand characters. See here for a full list [http://code.google.com/p/nhaml/wiki/NHamlLanguageReference]

  • partials and layout

better to look here [http://code.google.com/p/nhaml/wiki/PartialsAndLayouts]

  • htmlencoding by default (through config) for all content to avoid XSS

  • XHTML compliant output

from the spark perspective

  • embedded code into the xml tags and custom code tags can be used to perform progromattic actions. This all allows spark to minimise the context switching that occurs for both nhaml and aspx.

for example this spark

<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
  <li each="var p in products">${p.Name}</li>
</ul>
<else>
  <p>No products available</p>
</else>

aspx and nhaml would require you do a context swtich out to code to perform the if..else statement.

References

[http://code.google.com/p/nhaml/wiki/NHamlLanguageReference]

[http://sparkviewengine.com/documentation/syntax]

Simon
It does indeed look more succinct. However, the requirement to indent would be familiar only to those people developing in F#.
Robert Harvey
How does one specify inheritance in nHaml? In the default view engine it is specified as Inherits="MvcApplication5.Views.Products.List"
Robert Harvey
Also, the view that you provide is an example appears to be derived from an ASP.NET page. Some of the characters, such as AutoEventWireUp, CodeBehind and Runat=Server are gratuitous (they are not used in ASP.NET MVC).
Robert Harvey