We've been looking for ways to rework our internal Dot-Net CMS to have dynamic HTML templates so web designers can better relate to UI details, relieving programmers from most "formatting duties". The web designers are not expected to be programmers, but understand basic conditionals and loops. Razor has proven too complicated and finicky for this task.

Dynamic templates seem easier and more common in dynamic languages, such as PHP and ColdFusion. We are looking for something similar for Dot-Net.

A key requirement is the templates can be created without programmer intervention and don't "crash" the entire application if they have typos: only the specific "bad" template crashes, hopefully in a friendly/controllable way. Also, template inclusion can be conditional and nested. Compiled languages often choke on these requirements.

Here's a rough example of what we are looking for:

<t.includeTemplate file="folderX/page_intro7.tp" param_title="Page Title X"/> <t.tableLoop name="dat" datasource="mydatasource" class="tbl_green"> <t.ifNoRecords> <div class="my-notice" Sorry, no data found matching your criteria. </div> </t.ifNoRecords> <t.columnsHead class="tr_head_default"> <th>Name</th><th>Rank</th><th>Serial No.</th> </t.columnsHead> <t.loopBody> <td>#name#</td> <!-- value embedding... --> <td>#rank#</td> <td>#dat.serial#</td> <!-- note the optional 'dat.' prefix above --> <t.ifHasChildren> <!-- if has nested rows --> <t.includeTemplate file="folderX/template7.tp"/> </t.ifHasChildren> </t.loopBody> </t.tableLoop> 

All the "t." tags are part of the templating language. The optional reference prefix, "dat." in this case, allows scope clarification for nested loops (not shown). For simple loops one doesn't need it.

Optional parameters can be specified and given. For example, "class=" on the first line allows an optional CSS class name be given to the "table" tag. There may be other optional parameters, such as "noTable=true" if the designer doesn't want the default "table" tag so they can code their own (via direct HTML). I'm not saying this is the best arrangement, but how the defaults work should ideally be up to the programmer. For example, the query to determine "ifHasChildren(...)" would be programmer-defined based on shop conventions. One could in theory detect if no "ifNoRecords" tag-set were defined for the "tableLoop" tag-set, and give default handling for no-records-found. Such defaults reduce redundant code. Another example of useful defaults is if no "class=" attribute is given for the "loopBody" tag-set, then the default could be class "table-body-default". The tag design and defaults don't need to be designer-alterable themselves; the designers just use the tags as defined by the programmers.

Ideally the templates can be put into a folder structure of the designers' choosing.

I tried programming my own "template processor", but the feature set is too limited. I'd have to reinvent a full interpreter to have sufficient power. Tempting, but outside of my scope.

This is only an ideal suggestion, and something close enough may be, well, close enough. ColdFusion has a way to create custom tags similar to this. You can bash ColdFusion for other reasons, but it had a pretty good HTML/XML templating system that's hard to beat. Once you see it in action, you wonder why it's done any other way when designers are separate from programmers.

​