NHaml AST Parser – current state

A while ago I’ve started to rewrite NHaml from its ground up to use an AST based parsing approach instead of directly creating the output while parsing. I did this because of the following reasons:

  • Separate parser from output generation
  • Allow to reuse the parser for syntax highlighting plugins like this one for Visual Studio or a possible ones for Sharpdevelop or Monodevelop
  • Error reporting with line and index of error source
  • Fully parse the document and report all errors at the end
  • Better maintainability since the separate steps are less complicated

Since this all dose not fit within the current codebase, so I’ve started an empty one at GitHub. Since i work the most time at trains offline, git is much more useable for me than SVN and i really like the GitHub forking model. So if the other members are agree, it is possible that we move the source code of NHaml to GitHub later.

Currently the entire codebase pass the haml-spec test suite from Norman Clarke. Big thank to Norman, without that spec it would have cost me much more time to bring the codebase to the current state. But this means not that it is useable. The current DebugVisitor which generates the HTML output from AST is only a intermediate step. It only output HTML and no compiler or any dynamic code is involved.

The next step, is to track the line number and character index for each node. This is ware i work on currently. And here it is:

image  
This is a little test editor written with the Windows.Forms.RichTextBox. Initially I’ve used the WPF RichtTextBox, but since it is very very slow for this scenario and the optimization would cost much time I’ve switched over to Windows.Forms. Note: My goal is it no to create an editor for NHaml, i only use it for testing. As you can see not all nodes are highlighted yet.

The next step would be to report errors like when you only type “%” without a name behind (possibly this information could be used in a future syntax highlighting plugin too). After that I’ve want to extend the test suite for some missing parts like the alligator notation.

When all this is done, i plan to reintegrate the compiler and mvc stuff and publish it all together as NHaml 3.0. But don’t expect it to be soon.

First steps to allow precompilation to NHaml

Currently i made some tests on my private branch. The problem with this is that there is no way to get the model type and the view – layout combinition before the controller was executed.

So what i did to solve this. Ive added a new markup to NHaml with name MetaMarkupRule. This markup is implemented as property bag and this property’s are passed to the parser at compile time instead of runtime.

The idea is the following: In the view Ive put the a line like this (i currently don’t know if ~ is the best char for this):

~model=System.String
%p
foo

Which results in a model property with value System.String which is passed to the Meta Dictionary inside of the TemplateParser.

The next step is to put a generic base type to the TemplateCompiler like this typeof(MyCustomView<>). Then direct after the parse step and right before the compiler melts the source and compiles it, we read the value of the model property if it is available (otherwise the default is System.Object) and create the model type with MakeGenericType of the base type. The result then looks like MyCustomView<System.String> which is this what you currently get if you call return View(“myview”,”mycustommodelstring”).

This could be the way to go for precompilation. After the precompilation return View(“myview”,”mycustommodelstring”) would not longer create the type, instead it searches in the list of the precompiled views and raises an exception if it dose not found the matching view type.

To solve the view-layout combinition problem we simply compile a version auf each view/layout combination that exists or we allow the view to specify also the layout. It is also an idea to allow a view specifiy more then one model. This could work as long as the both model types have the same propertys which are used in the view on it.

The NHaml way to prevent presentation concerns in controllers

Based on Ayende’s post about not putting presentation concerns in the controller, here is the NHaml way of setting the page title in the view.

ViewsShareApplication.haml:

^ var title = “Page”;
!!!
%html{xmlns=”http://www.w3.org/1999/xhtml”}
%head
%title = title
%body
_

ViewsHomeIndex.haml;

– title = “Home Page”;
%content
This is my Home Page

ViewsHomeAbout.haml;

– title = “About Page”;
%content
This is my About Page

Simple isnt it?

I am a team member of the NHaml project

Haml project logo

In fact i am joined for a while now, but i blog about it first now. You take the question what is NHaml? NHaml is a .Net port of the excellent Ruby Haml which is a HTML/Xml DSL ported by Andrew Peters which also provides a ASP.Net ViewEngine.  You could read more on his blog.

I really like the simplicity and cleanness templates of haml and i see a lot potential there, so my first step was to refactor NHaml to allow alternative TemplateCompiles instead of C#. While i dose this, ill added a Boo TemplateCompiler and Andrew later a IronRuby Template compiler. Since a few days now boo has also a Sample MVC Application which demonstrates how it work.

But there is a lot of more work to do, i added some of my ideas to the bugtracker of NHaml and hope to get all done. The next major steps are to provide all Haml 2.0 language features like filters and alligators. For later i also plan to add an working MonoRail ViewEngine.

Update:
Sergio Pereira hase made a nice overview of the benefits NHaml can give us.