[stringtemplate-interest] IronStringTemplate

[Robert Byrne]

I can think of two uses here of the top of my head here. Firstly, it would
be a way to bridge .stg and .st modes, if you have a primarily .st setup and
would like to merge some small templates into an .stg and call them from the
file based templates. A service to resolve template paths could be smart and
pull them from a group file instead of a .st file.

Secondly, you may want to ability to override some templates on a dynamic
basis, say having the default on a file, but having the user supplied
override stored in a database, perhaps on a user by user basis, so each user
may have a separate version of a template, and so on.

I'd be thinking something along the lines of

interface TemplateLocator {
	StringTemplate locate(string path);
}

That way you are not permitting any execution that does not result in a
valid template. I'm thinking of it like an mvc style interaction, whereby a
path doesn't necessarily match one to one with a file, there's a
'controller' in the background determining what the best template to satisfy
that path is.

I've seen some classes related to file based lookup and change detection in
the .NET version, so this may already be implemented, but it might be a good
idea to formalise and encourage it with an interface, as its not immediately
obvious.

Rob.

-----Original Message-----
From: Terence Parr [mailto:parrt at cs.usfca.edu] 
Sent: 30 June 2009 21:07
To: Robert Byrne
Subject: Re: [stringtemplate-interest] IronStringTemplate


On Jun 30, 2009, at 12:50 PM, Robert Byrne wrote:

> Sounds good, I agree with the dynamic nature, especially with silent
> handling of nulls in chained property access 'foo.bar.name', it  
> reduces a
> lot of the noise from the view or view model and makes it much  
> easier for
> non programmers to understand.
>
> One thing I'd like to suggest help is breaking StringTemlateGroup  
> down into
> a few simple services, which would make things like resolving template
> names/paths a little easier to plug into, say if the nominated  
> template is a
> 'virtual' one that doesn't happen to exist as a file and so on.  
> Would also
> make it easier to integrate .st files and .stg groups in the same  
> context.

Interesting...wouldn't it make it too easy to call an arbitrary  
function though if you could do virtual templates? (a func call I  
presume?)
T