views:

110

answers:

3

Recently I created a spike of a view engine, in which views are plain classes, and the content is created by using funny using-scope blocks.

The code together with a simple sample site is available at http://code.google.com/p/sharp-view-engine/

Here I'd like to hear your opinions regarding such an idea. Is it completely weird or maybe someone likes it?

+1  A: 

This is an interesting idea taken to the extreme I'd say. At my shop we're using html conventions for pretty much everything except our layout. The only real html we have in the project is our Spark master page. For generating the content itself we use a convention engine that that spits out a semantic html model. (We're using the HtmlTags library from FubuMVC to build the semantic model.)

An example convention for rendering a multiline text box looks like:

public static HtmlTag Build(ElementRequest req)
{
    return Tags.TextArea
            .Rows(6)
            .Id(req.ElementId)
            .Attr("name", req.ElementId)
            .Text(req.StringValue());
}

These conventions get triggered from reflecting on the view model (or we can manually call them from a helper method). The output is rendered (via ToString()) into the content section of our master page. We're joking that pretty soon we won't even need a view engine.

ps here's how we handle nesting. (Your using blocks look cluttered!)

return Tags.Div.Nest(
    Tags.Button("save").AddClass("positive"),
    Tags.Span.Text(" or "),
    Tags.Anchor.Text("cancel").AddClass("negative")
);

Nest() is an extension method that simply takes a params array of HtmlTag and appends them to the parent's children collection.

Ryan
+3  A: 

I would actually not like that.

I can agree with DSLs (such as a Parser-Combinator or for generating XML Nodes in a data-context), but in this case I think that too much is being put in code that. And, in the end, this just complicates boundaries and leads to hard-to-maintain code. (You can already do the same, but with more verbosity just using the "standard" Web Controls. You can always use {subblock} in C# to limit a variables scope.)

The approach I prefer to use is templates with bindings (but no "code in templates"). That makes it easy for the "designer" (hopefully not me, or the next person to come along and) edit the layout of the view how they see fit. However, the core logic (the available controls and bindings) are kept in the code -- uncluttered. (Another advantage with the templates is that if they externally housed they do not require a recompile for every little change.)

Simplicity and maintainability are like ... zen.

pst
A: 

Also there is another pure C# view engine for ASP.NET MVC - SharpDOM - http://sharpdom.codeplex.com/ - similar idea, but not so cluttered - combines the pure HTML and logic - both expressed in C#

vtimashkov