[stringtemplate-interest] group loading is messy

[Nate]

I see. I guess my problem is that it is so loosely defined. I expected 
some features out of the box. When I find they don't exist, I go to look 
at how to implement them and run into a somewhat daunting API. I 
shouldn't have to hack on the StringTemplate internals to get the 
behavior I desire. If I were off the beaten path, then is would be great 
that this is possible at all. However, I feel like I am doing standard 
stuff that most users will do.

A parallel might be JDOM vs XOM. They both do the same thing, but with 
the XOM API there is only one way to do a task. This may seem less 
powerful, but with a carefully designed API it doesn't have to be.

Looking at the StringTemplate source, there are many protected members. 
These are part of the public API and can't be changed without 
potentially breaking people's code. When the internals are exposed like 
this it allows people to extend the class and muck around, but it also 
means that if the software goes through an iteration that adds major new 
features, this legacy API must be maintained. The StringTemplate API 
feels to me as if this had happened. It doesn't feel "tight".

For example, have you ever tried to load template files with an 
extension other than "st"? Apparently this can only be done by extending 
StringTemplateGroup and overriding getFileNameFromTemplateName, which 
consists of this code...
    return templateName+".st";
Oops! Don't forget to also override getTemplateNameFromFileName which 
consists of this code...
    String name = fileName;
    int suffix = name.lastIndexOf(".st");
    if ( suffix>=0 ) {
        name = name.substring(0, suffix);
    }
    return name;
Are there other methods that need to be overridden? The way to find out 
is to read the StringTemplate code, potentially all of the code.

Anyway, I don't mean to knock StringTemplate too hard as I do think it 
is great. I just think the API could use some TLC. It seems the 
necessary changes could be made if a release were made that is not 
backwards compatible.

-Nate


Caleb Lyness wrote:
> Nate wrote:
>> Why is group loading so messy?
>>   
> Because you are using a square peg for a round hole?
>> The worst part is that a .ST group file and a directory containing 
>> templates are really two different kinds of groups. Eg, I have this 
>> directory structure...
>>
>> redskin/template1.st
>> redskin/template2.st
>> blueskin/template2.st
>>
>> I want blueskin to extend redskin. The way I ended up doing this is to 
>> create a text file named "supergroup" which contains the name of the 
>> super group, which I manually load and call setSuperGroup. Why can't I 
>> have a .ST file that defines the template group and the directory? This 
>> way I could define the super group in the .ST file as well as templates 
>> AND I could have template files in the same directory. Currently I can't 
>> mix defining templates in a group file and using a directory of templates.
> Group file (stg) and template files serve a different purpose.
>
> I have something similar though,
>
> generic/template1.st
> generic/template2.st
> generic/resgroup1.stg
>
> skin1/template2.st
>
> skin2/template1.st
> generic/resgroup1.st
>
> I wrote a wee class which loads the group file in a hierarchically way
> and I removed my custom class loader and replaced it with something based
> on the one email /you /sent a couple of weeks back (Thanks - its a 
> simple solution).
>
> I wanted something like this:
> skin/template.st -> generic/template.st -> skin/resgroup1.st -> 
> generic/resgroup1.st
>
> (Actually a little more complex, because I have common templates and 
> language based templates too,
> but it illustrates the example)
>
> So for the first part:
>
> final Vector<File>        searchPath = new Vector<File>(4);
> ....
> // Fill in the search path with the thing you want to inherit from in 
> order. Like you would with the jar classpath
> ,,,,
>
>         templateGroup = new StringTemplateGroup("templates") {
>             protected StringTemplate 
> loadTemplateFromBeneathRootDirOrCLASSPATH (String fileName)
>             {
>                 for (File dir: searchPath) {                   
>                     String file = new 
> File(dir,fileName).toString();                   
>                     StringTemplate result = 
> super.loadTemplateFromBeneathRootDirOrCLASSPATH(file);
>                     if (result != null) {        
>                         return result;
>                     }
>                 }
>                 return null;
>             }
>         };
>         templateGroup.setSuperGroup(resourceGroup);
>
> There is nothing stopping you from defining a resource group which 
> knows how to define the search path
> for your templates. That way you don't need to hard code 'em. If you 
> are complaining about having to manually
> join the group templates and template files.
>
>
> Cheers
>      Caleb