Template Languages and "Nearly VB"

re: Template Languages and "Nearly VB"

bill — Tue, 26 Feb 2008 01:51:26 GMT

So why not use VB for the templates but C# for the initial output rather than some "Nearly VB" . Doesn't C# address every issue you've raised ?

But I am curious as to what about issues that are language specific, such as declerative event wiring, optional parameters etc ?

re: Template Languages and "Nearly VB"

Kathleen — Mon, 25 Feb 2008 17:42:07 GMT

Almost,

The infrastructure of the template itself outputs the VB code, so no translation is needed to output the VB code, thus 1.2 and 2.2 in your list do not occur. You just run the original template. This also makes 4.2 slightly misleading as there is no template preprocessor for VB.

For 3.2, you do need the preprocessor - I think the preprocessor name is confusing here but I haven't come up with better semantics yet.

Scenario 5 is well supported beause of the three pronged nature of the conversion. Writing C# templates is as easy as wriitng VB templates, you have the full support of the infrastrucutre methods such as OutputFunction and some of the semi-colon management if you want it, because that's the way it happens to work.

You do, however, have to use VB for the XML literals. If you want to write only C# and do not want to use XML literals, you are probably better off sticking with the ASP.NET style template languages including CodeSmith, MyGeneration, CodeBreeze, and T4 from Microsoft (free).

For complex templates you can still use XSLT, however why would you? You have to learn a secodn language (either VB or XSLT) and VB is way closer to C# than XSLT.

Thanks for the summary Baxter!

re: Template Languages and "Nearly VB"

Baxter Lane — Mon, 25 Feb 2008 16:17:17 GMT

So this adds an extra step to the previously blogged about template preprocessor. You would always have to run the preprocessor, even if you were just generating VB code since the templates are no longer "legal" vb.net code.

As I see your proposal we have the below five usage scenarios.

1. You want to generate both C# and VB.Net out of the gate

1.1. You create your templates in the “Nearly VB” template language

1.2. The preprocessor has to run before your two templates are usable

2. You are currently only going to generate vb.net code but you want to support generating c# from your templates , just in case the need arises

2.1. You create your templates in the “Nearly VB” template language

2.2. The preprocessor has to run before your template is usable

3. You are currently only going to generate c# code but you want to support generating vb.net from your templates, just in case the need arises

3.1. You create your templates in the “Nearly VB” template language

3.2. The preprocessor has to run before your template is usable

4. You could not care less about c# and only want your template creators to have to know valid vb.net code

4.1. You create your templates to output legal VB.Net (which should be slightly easier for your vb.Net guys)

4.2. The preprocessor does not ever run against your template

5. You could not care less about vb.net and only want your template creators to have to know c#

5.1. Not possible with this product since we require the XML literals but…

5.2. You create their template output using legal c# and never have to worry about the “Nearly VB” syntax

5.3. The preprocessor does not ever run against your template

If the application has this flexibility I think it sounds great. If we are talking about limiting people I think we are going to scare off some who could otherwise greatly benefit from this tool.