What’s coming next? Text templating improvements.

Stuart has a great post on what's around the corner in DSL Tools world.

Particularly important from a planning perspective is that our next release will require users to move to Visual Studio 2005 Beta 2 (and of course this means that we'll release after that does).

He mentions that one focus we're planning for the next release is improvements to our text templating technology.

Text templates are the glue that allow writing of ASP-like template files to generate code, reports, other models or any other kind of text file.  Whereas ASP page templates typically use a database or some business objects as their data source, our templates typically use a model file and the accompanying API generated by our tools as their data source.

A key point is that this system works with models created in both of the DSLs that ship as part of the DSL Tools (the Domain Model Designer and the Designer Definition xml file) and in exactly the same way with models created in the DSL designers that you build yourself.

We actually quietly added some functionality to the templating system in our March release.
I'm using the string <delim> in the text below as a substitute for angle-bracket percent as .Text doesn't like the literals, no doubt guarding against an injection attack.

You can now declare functions for use elsewhere in the template using a new type of code block with the delimiters <delim>!  </delim>, for example:

private static bool CalculateSomeValueRecursively( YourModelElement root )
    // Do funky recursive stuff
    return true;

Right now, there are a couple of limitations:
Functions you declare have to be static - we'll be lifting this restriction in a future release.
You can only have one <delim>!  </delim> block and it must come after all directives and before the rest of the template. You can declare as many functions as you like in this block though.

You're then free to call this function from any regular <delim> </delim> or <delim># </delim> block.  This functionality is pretty useful for a couple of things.
Firstly, it can tidy up your templates no end by removing repetitive code.
It allows you to walk the tree-like structures often found in models using recursion.  While recursion is not always a suitable technique, it is very, very convenient when traversing many models.

Looking ahead, a significant additional facility that we're planning in text templating is to enable a #include mechanism.  This will allow the repetitive code from templates to be squirreled away in a standard place, drastically easing maintenance.

(Sorry for all the updates, but I had a terrible time getting this entry to post)

Comments (5)

  1. Hi, I’m working in a code-generation tool that use C# templates (like codesmith), but reading metadata model from Visio UML.

    Using C# templates is very interesting, because I can call custom DLL’s, Web Services, etc and use data form them to populate my template… And considering that all Visio UML information I get is populated into a typed dataset, it is easy for the programmer to find out all the information he needs without worry about the source of the UML data.

    I’m wondering how much flexible will be this "asp-like" sintax, so I can port my code-generation tool and templates to this new software.


  2. Gareth Jones says:

    So I guess I should maybe have said ASP.Net- like syntax. I haven’t looked at Codesmith.

    What we have is syntax like ASP.Net, but without a control-composition model, thus reducing the functionality closer to ASP.

    You can only use C# today (and VB.Net in future), and you can call out to external assemblies (or Web Services – I haven’t had a reason to try that).

    From what you say, I’m sure you could port your code to use our system rather easily.

    We’ll also expose a plug-in data provider mechanism in future to make it easy to plug in data sources such as your Visio data.

  3. DJP says:

    This may be stating the obvious, but you can also define entire new classes inside the "Class features control block", and then create and use instances of these classes from inside the template. In C# terms, any classes you define will be nested inside the "main" static class, but this doesn’t really make a difference to how you would use them in the template. New classes don’t have to be static i.e. can have instance methods.

    Given that this is already possible, is it necessary to support non-static functions in a different way in a future release?

  4. GarethJones says:

    You’re correct that it’s not strictly necessary for this reason, but there are a bunch of other good reasons to change to instance classes. We’re changing the mechanism by which parameters are passed which gives a much cleaner syntax and extension mechanism.

Skip to main content