NHaml: Block Methods and RESTful Helpers

Posted by Andrew on August 21, 2008

New in the trunk are a couple of cool features worth mentioning:

Block Methods

Block Methods are helper methods that accept a block of NHaml markup as a final argument.

An example (albeit contrived) to demonstrate:

- Html.Tag("div") () =>
  Some regular NHaml markup here...

which results in:

<div>
  Some regular NHaml markup here...
</div>

And the Tag method looks like this:

public void Tag(string name, Action yield)
{
  _output.WriteLine("<" + name + ">");
  yield();
  _output.WriteLine("</" + name + ">");
}

As we can see, NHaml wraps up the nested block markup into a lambda (or anonymous method if targeting C# 2.0) and passes a delegate to the block as the last argument of the helper method. Invoking the delegate causes the markup within the block to be rendered. Notice too, we can write directly to the output stream: _output is an instance of NHaml’s IOutputWriter which is passed to our helper class when it’s instantiated. It has the following methods:

void WriteLine(string value);
void Write(string value);
void Indent();
void Outdent();

Output written using these methods will be correctly indented and we can also further control the indent level if we need to write nested output.

Worth mentioning is that we can also pass arguments to a block:

- Html.Tag("div", 21, 21) (i, j) =>
  = "N was: " + (i + j)

which yields:

<div>
  N was: 42
</div>

And our helper method:

public void Tag<T1, T2>(string name, T1 t1, T2 t2, Action<T1, T2> yield)
{
  _output.WriteLine("<" + name + ">");
  yield(t1, t2);
  _output.WriteLine("</" + name + ">");
}

RESTful Helpers

Using a Block Method we can create a nice Rails-style helper that encapsulates building a form for a single model:

- var product = new Product { ProductName="Soap on a Rope" }
- Html.Form(product) (f) =>
  = f.Label(p => p.ProductName)
  = f.TextField(p => p.ProductName)
  %br
  = f.Label(p => p.UnitPrice)
  = f.TextField(p => p.UnitPrice)
  %p
    = Html.SubmitButton()

Results in:

<form action="/products.mvc/create" method="post">
  <label for="Product.ProductName">Product Name</label>
  <input type="text" name="Product.ProductName" id="Product.ProductName" value="" />
  <br />
  <label for="Product.UnitPrice">Unit Price</label>
  <input type="text" name="Product.UnitPrice" id="Product.UnitPrice" value="" />
  <p>
    <input type="submit" />
  </p>
</form>

A couple of things to note here:

  1. Our Form method takes a model object and uses the conventions of REST to generate the target action. To make this work our model needs to implement a small interface: IModel:
    public interface IModel
    {
      int Id { get; }
      bool IsNew { get; }
    }
  2. Happily, we can bind our model attributes in a strongly typed fashion using Expressions.

Here’s what our Form method looks like:

public virtual void Form<TModel>(TModel model, Action<FormBuilder<TModel>> yield)
  where TModel : IModel
{
  // this should be pluggable
  var formBuilder = new FormBuilder<TModel>(model, this, _outputWriter);
 
  formBuilder.OpenTag(FormMethod.Post, new RouteValueDictionary());
  yield(formBuilder);
  formBuilder.CloseTag();
}

RESTful Link Helpers

Finally, we can apply RESTful conventions to link helpers too. Here are a few examples of some NHaml ActionLink helpers that work using REST conventions.

= Html.ActionLink<CategoriesController>() // /categories
= Html.ActionLink<CategoriesController>(RestfulAction.New, "Add Category") // /categories/new
= Html.ActionLink(category)  // /categories/show/42
= Html.ActionLink(category, RestfulAction.Edit, "Edit Category") // /categories/edit/42
= Html.ActionLink(category, RestfulAction.Destroy, "Delete Category") // /categories/destroy/42

Thoughts/comments appreciated.

kick it on DotNetKicks.com

VS File Explorer

Posted by Andrew on August 13, 2008

We at Mindscape just released a cool, free VS add-in: the Visual Studio File Explorer. It’s basically Windows Explorer inside Visual Studio 2008 so you can perform file system tasks without needing to context switch. It’s also shell enabled so extensions like TortoiseSVN work too.

Download it here

Why Tabs Suck

Posted by Andrew on August 05, 2008

I’m quite often receive a puzzled look when I explain to .NET coders that, like Ruby developers and others, I prefer spaces (2 to be precise) over tabs. If you’re already a space aficionado you may go about your business, otherwise read on.

First of all, I don’t have a problem with the tab character per se. My problem is that it’s all too easy to misuse it. Observe:

This code, taken from an open source project that mandates tabs, illustrates the problem - The author has mistakenly applied a liberal sprinkling of spaces in with the tabs:

Of course, the problem manifests itself because my indent level is different to that of the author. And, to be honest, I don’t think I’ve ever seen a tab-indented project that didn’t suffer from this problem.

Spaces, on the other hand, are atomic and consistent - They always render the same way.

So which indent level? Studies have shown that 2 to 4 is the sweet spot:

Although blocking style made no difference, the level of indentation had a significant effect on program comprehension. (2-4 spaces had the highest mean score for program comprehension.) We recommend that a moderate level of indentation be used to increase program comprehension and user satisfaction.

Personally, I prefer 2 spaces because it’s no less readable but uses less horizontal real estate.

kick it on DotNetKicks.com