Is there a general solution to string templating?

String Templating seems to be a problem that gets solved over and over again. But is there a general problem underneath at all? And if so, can a general solution be designed, implemented everywhere and used with confidence? Read on for rampant speculation.

In various systems I've worked on, we let users set 'templates' for things such as emails or SMS.

Typically, we define a few 'special strings' that end users can embed in these 'templates', a bit like merge codes in a word document.

For example:

Dear %UserName%

Thank you for your complaint letter, dated %ComplaintDate%.

We take all complaints seriously and will address this issue in the next release of our product, version %Nextver%, due out on %NextVerDate%.

[etc.]

Okay -- that's the simplest case. I've seen the same sort of thing in many many places. Reporting services, as one example.

Next step up from that, you have something like CodeSmith where more complex substitutions can be employed:

#region <%= SourceTable.Name %> Class

..and you can define properties to be used, like so:

<%@ Property Name="SourceTable" Type="SchemaExplorer.TableSchema" Category="Context" Description="A Table." %>

And you can even define scripts (which I won't go into here...)

And here's an even simpler example of a powerful templating solution:

String fullName = String.Format("{0} {1}", firstName, lastName);

And in the last few days I've been looking at the in-built string expansion in Powershell. For example:

PS H:\> $name = 'fred'
PS H:\> "Hello $name, can you count to $(2+2) ?"
Hello fred, can you count to 4 ?
PS H:\>

(Not to mention Double-Quoted Here-Strings! Woah Baby!)

Now these are all different examples of what i'm calling 'templating solutions'

The thing is though, that everywhere I look there seem to be more and more custom solutions to this problem. Some of them are slightly standardised, most of them are very home-baked.

Each of them requires a parser, a mini language of 'special strings'... some input data that gets injected it... and then either a little or whole lot more complexity on top of that.

So each time a parser is written for this, it has to ignore or re-solve the character escaping problems. And then users want to specify numeric formatting. And string functions. And simple arithmetic. And date arithmetic. And more. And anywhere from a little to a lot of familiar code has to be written or rewritten (more code is bad, right).

All of which makes me wonder: "is there a general templating problem?"

We can say that there's a general 'data storage and retrieval' problem -- and as such we have Relational Databases and the famous 'Domain-Specific-Language' SQL

And we can say that there's a general 'transmission of structured data' problem -- and for this we have another Widely Implemented mini-Language XML

And we can say that there's a general 'match and or replace all sorts of patterns in text' problem -- and for this we have another Widely Implemented (and Mis-Implemented) 'Domain-Specific-Language' Regular Expressions

But what about string-templating? Is it a definable problem? Can it be specified once, implemented on any platform, and re-used with confidence?

Eh?

Incidentally, I may as well list some other string-templating related solutions I've stumbled onto in the time I've been thinking about this...

  • XSLT (but because the templates are never human-writable, I ignore this as a general solution in itself. Could underpin a good solution.)
  • StringTemplate -- implemented in Java, Python and C#. Might be promising...
  • A Powershell Templating Engine -- not sure about this one.
  • asp (classic) and php are basically string writing engines... with specific support http & html
  • Haml
  • wscg world's simplest code generator uses arrays of data and special strings like '$1'. But I like it.
 

I'm currently writing a book about how to build your first product. If you want to build your first product, please sign up to be notified when the book is available.

(By the way, I read every comment and often respond.)

Your comment, please?

Your Name
Your Url (optional)
Note: I may edit, reuse or delete your comment. Don't be mean.