The folks at the Castle Project development list have provided some excellent constructive criticism and some new functionality was added to Spark as a result.
One thing which is new is the ability to inline code directly.
#int total = 0;
#foreach(var item in items)
#{
# total += item.Quantity;
#}
#if (Params["page"] == "2") {
<p>Second Page - total: $total;</p>
#} else {
<p>Not the second page
#}
Or using the slightly more standard <% %> syntax
<%
int total = 0;
foreach(var item in items)
{
total += item.Quantity;
}
%>
<%if (Params["page"] == "2") {%>
<p>Second Page - total: <%=total%> </p>
<% } else { %>
<p>Not the second page
<% } %>
Another question which came up was about the support for MonoRail ViewComponent classes. This was an especially interesting point because the view engine itself is written to be used in any framework, while the ViewComponent is very specific to the Castle Project. To make this happen the Spark parser and code generator was changed to call an extension factory interface as it processed the elements from the view templates it digested. This enabled the MonoRail-specific view engine library to recognize elements whose names matched those of the registered view components. It can then provide an extension that consume the contents of that element to write it’s own chunks of generated code at the appropriate point.
So the net result is support for things like this.
<p>blah blah blah</p>
<DiggStylePagination Page="SomeMessages" Adjacents="3">
<prev>Go Back</prev>
<next>Show More</next>
</DiggStylePagination>
<p>blah blah blah</p>
And another piece of functionality which was added was the ability to declare and use helper-like functions inside the template file.
<macro name="MessageBox" caption="string" message="string">
#Logger.Info(message);
<div class="msgbox">
<h3>$H(caption);</h3>
<div>$message;<div>
</div>
</macro>
<p>blah blah blah</p>
$MessageBox("Warning",
"You're about to change " + somearg + " permanently.");
<p>blah blah blah</p>
The thing that I think is pretty cool about that is how it create a function what works like a helper method, because it takes a handful of arguments and returns a string, but the body of this thing is declared in the template vernacular. So it can be very “view oriented” in how it’s build and maintained. Which makes sense for a lot of helper-style methods which are very much about the idea of concatinating and returning html – implementing simple helper methods in classes can occastionally put more html in your cs files than you’re comfortable with.
In any case I’m really happy with how the view engine has come together. It’s been a delightful experience, didn’t take much actual time, and has really reinforced for me the value of tools like resharper and practices like test driven development.
Recent Comments