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.
'mgroves' on Thu, 22 Mar 2007 02:02:36 GMT, sez: I think the problem is one of user interaction: the user has to understand what the template strings/tokens are, how/why to use them, and (perhaps most importantly) validation of the templates.
Beyond that, I believe the programming is somewhat trivial, even custom solutions.
'Lispa' on Thu, 22 Mar 2007 04:03:15 GMT, sez: this is what lisp macros are for
'John Rusk' on Thu, 22 Mar 2007 06:01:18 GMT, sez: I've heard that you can host the ASP.NET page processing engine in your own code, and use it just as a templating engine. Haven't tried it myself though.
'Mike Woodhouse' on Thu, 22 Mar 2007 07:55:03 GMT, sez: And of course there's Ruby's #{} thingy, which I once got part-way to implementing in VBA...
StringTemplate looks interesting, and the guy behind it has a track record (ANTLR). Not something to learn in a day though, unlike String.Format(), which is pretty easy, even if the MS documentation on darker formatting options is a little, er, sucky.
'Ian Rae' on Thu, 22 Mar 2007 10:42:39 GMT, sez: Actually StringTemplate can be learned in a (full) day. I've used it in both C# and Java. My only complaint is that, like any other markup text, there is no compiler, so small syntactic errors are a littler harder to track down.
I wrote a blog article on it at: http://silentsoftware.blogspot.com/2007/02/grokking-stringtemplate.html
'Ryan Smith' on Thu, 22 Mar 2007 16:48:20 GMT, sez: To me, regular expressions are the string templating system. It doesn't really matter how your text is formatted, or how you decided to define your special escape sequence characters; running a regular expression will always be able to replace it.
'lb' on Thu, 22 Mar 2007 21:03:24 GMT, sez: >host the ASP.NET page processing engine
>in your own code
i believe this is how codesmith works.
'Article by Phil Haack' on Wed, 07 Jan 2009 02:02:20 GMT, sez: Phil Haack has implemented (and compared) some techniques for 'named formatting' as he calls it -- (see link in comment header)
There are over 30 comments there that touch on the topic.
|
secretGeek .:dot Nuts about dot Net:.
Just Wally
Complete secretGeek Archives
The Best Software Writing I
The Business Of Software (Eric Sink)
