[stringtemplate-interest] Attribute definitions, Group files and Templates.

[Jonathan Buhacoff]

This is the post I was looking for :)


On Oct 12, 2009, at 11:53 PM, Zenaan Harkness wrote:

> On Tue, Oct 13, 2009 at 03:28:59PM +1030, Barrie Treloar wrote:
>> The other thread about cleaning up ST made me check Jira for one of
>> the things I wanted while working with ST.
>>
>> I wanted to use a directory for my TemplateGroup instead of a file.
>> As the size of my templates would make the group file massive and  
>> unwieldy.

And I would like to use any arbitrary file storage class for a  
template group.  In my projects I have a FileStorage interface with  
implementations for classpath, disk, http, samba, ftp, sftp, memory,  
jdbc, etc, that I use routinely to allow my users to easily use files  
from any location.

In the project I'm working on now, I need to load templates from a  
database as a StringTemplateGroup having templates from the classpath  
as a super group to provide sensible defaults for missing templates.

I was just looking today for the easiest place to subclass  
TemplateGroup so when I call getInstanceOf it will load the templates  
from whatever data source I specify. Looks like the best place to do  
it is to override loadTemplateFromBeneathRootDirOrCLASSPATH.

Does that look right?  I looked at the StringTemplateGroupLoader  
interface but it doesn't look like the right place.


>>
>> I think the only reason I wanted a group was so I could get attribute
>> definitions in my templates.
>> If the new version of ST will allow me to do this for template files
>> then I think I dont need TemplateGroup as a directory instead of a
>> file.
>> Can anyone see the values of having TemplateGroups as a directory  
>> then?
>
> I rather like the structured Java-like approach:
>
>   -  Directories correspond to java 'Packages', or "ST Packages"
>      ie groups of ST TemplateGroups.
>   -  Files correspond to classes, ie ST TemplateGroup files.
>   -  Individual ST templates can be in a single file,
>      BUT, for uniformity (ala Java), should still be a TemplateGroup.
>
>
>   -  Next, TemplateGroups (just Group perhaps??), have an inheritance
>      hierarchy ("extends", like Java classes).
>   -  Multiple inheritance, would help big time for me.
>      -  I have a "lib" ST group
>      -  I have a language specific group (eg. Java, C#), sort of
>         specialized 'lib' groups
>      -  I have specific lower level/ operational groups which often
>         need to inherit templates from different parent lines.
>

It would be nice if there were an interface for loading the templates  
in a group, something like loadTemplate: String -> StringTemplate, so  
that in StringTemplateGroup itself this could be delegated to disk-  
and classpath- specific implementations, and it would be an easy way  
to integrate other storage or inheritance schemes.



>   -  Ie, I am using the TemplateGroup to bring sanity to the number  
> and
>      structure of templates.
>   -  Without multiple inheritance, I am required to do some really
>      hacky temporary file munging, to ensure that all groups I need
>      ultimately form a single-inheritance hierarchy.
>
>   -  A good language (eg. Java, ST), provides facilities to  
> competantly
>      manage complexity.
>   -  Current versions of ST do not provide adequate complexity
>      management facilities for larger projects.
>   -  So, whether MultipleInheritance, or something else (eg. "mixin"
>      pattern is the more robust way than "inheritance" pattern to
>      componentize, where possible, at least when it comes to
>      programming languages), another tool within ST for complexity
>      management is required.
>
>   -  It is my belief, that because ST is a declarative generative
>      language, multiple-inheritance should not pose anywhere near the
>      fine grained difficulties that we see for example in C++ MI.
>

I disagree, I think the problems with multiple inheritance will follow  
that concept into any situation.

But if we had a clean interface to implement a template loader for  
StringTemplateGroup without having to replace all the logic in that  
class, it  would make it easier for Zenaan to implement his package- 
based and multiple inheritance loaders, even publish them for other  
users who may want that.  In my program, I just need to implement a  
loader that contains a jdbc loader and a classpath loader and try them  
in order.


>
> So, directories are a fine and natural (given current and foreseeable
> OSes) tool for grouping of files, and therefore a useful tool for
> complexity management, which tool we _are_ currently using in ST.
>
> To have TemplateGroups _be_ a directory, is comparable (comparison  
> with
> Java) to having a class of functions/methods, _be_ a directory - ie
> splitting out each method into its own file, and having all those  
> files
> in a directory, and the directory be the java Class.
>
> Of course, historically, it made sense - ST was built piece by piece,
> and started out with much less features than it has now. thankfully,
> despite feature growth,
>
>   --== ST remains the only template engine to
>        consistently separate view from model. ==--
>
> And THAT is quite an achievement, for which we can thank Ter's  
> rigorous
> analysis in the first instance, written paper, and ongoing education  
> and
> commitment to this foundation principle (now of course supported by we
> the ST community).
>
> I have been convinced for some years now, since I first studied and
> began my own ST journey, that ST's day is yet to truly begin. And I
> think that with a spec :), the cleanup now in progress (thanks Ter),  
> and
> just a few little extra features (including in particular something  
> akin
> to multiple inheritance/ one more complexity management tool), then ST
> has the potential to be the foundation of an amazing renaissance in
> programming/ software development. Time will tell of course :)
>
> cheers
> zen
>
> -- 
> Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
> Please respect the confidentiality of this email as sensibly  
> warranted.
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest