[stringtemplate-interest] getting rid of StringTemplateGroupLoader

[Terence Parr]

On Nov 8, 2009, at 9:37 PM, Zenaan Harkness wrote:

> On Sun, Nov 08, 2009 at 05:20:38PM -0800, Terence Parr wrote:
>> inheritance and polymorphism. To make inheritance work in the  
>> previous
>> version we said something like:
>>
>> group AdminView : GeneralView;
>
> Ahah! Time to strike :)
>
> Multiple-inheritance/ MI - yay!

sure. why not.

> OK, now MI is considered possibly challenging to implement.

it's easy. just have a list of supergroups. walk in order looking for  
the template.

> [snip]
> The design of Java, with it's plentiful complexity management tools -
> packages, classes, interfaces, methods, classpath, imports etc, is
> proven to work well for supporting both very large, as well as small,
> systems.
>
> Let's take advantage of these proven things, yes?

Well, i'm not implementing interfaces this time. not really needed.   
Java has a much more complicated problem than templates.  I never felt  
the need in ST to have packages. subtrees of templates on disk kind of  
does that.

>> That means that we are creating a new group derived from GeneralView.
>> Any template that we don't find in AdminView, we will look up in
>> GeneralView. This lets us inherit and refine templates from above.   
>> As
>> the comment suggests, we need the group file loader so that ST knows
>> how to locate GeneralView as it parses that file. I no longer have
>> that header inside group files so I don't think we need the group
>> loader anymore; we will construct the hierarchy manually:
>
> Sounds ... manual.

Yep, and sometimes you need it for dynamically choosing supergroup.

> How about something like this:
>
>   StringTemplateEngine e = STFactory.getPlatformInstance();
>   e.addTemplatePath("~/st/mylibs");
>   e.addTemplatePath("C:\st\mylibs"); // Windows version
>

Not sure we need paths since when coding you know which one to load  
since you're saying explicitly which to load.  Perhaps we can add a  
path thing later.

> This to me looks clean.
>
> Of course, no reason to not have "programmatical assembly of templates
> and groups" api, as we have now. But I imagine, for any system of
> significant size, the process I suggest above will be a godsend.
> I've been craving for such simplicity for a while, and was
> contemplating for some time (for when I had time) to create a separate
> module which would do a little custom parsing and assembling, to
> effectively get this auto-import/multi-inheritance type thing off the
> ground for my own system. But a generic solution is always preferable.
>
> Q:
> Does the above suggestion look clean, workable, and implementable?

how is it different than group loaders?

> ...
>> This will decrease complexity significantly (by removing the entire
>> concept of group loader).
>
> Nice. But we should not need to put complexity back onto the ST user.
> Let's follow Java's lead, and make ST more structured - increase
> performance of ST, and provide greater flexibility and complexity
> management to the user, at a small cost of syntax overhead (to the
> user - implementation aside).

I've never needed the loader when manually setting supergroup.

> It's really nice to be able to work within ST 'text' files,
> without having to re-compile some host (java, c# etc) code
> to get my latest changes.

yep :)

>> My only concern is that now we have two trees:
>>
>> * trees of templates. For websites we often have many directories of
>> templates grouped into subtrees on the disk
>> * inheritance hierarchy (tree)
>
> I think we should deprecate the old concept of templates in individual
> files grouped into directories.
>
> Allow the user to choose one or the other 'loader' :)
> to provide a version or two worth of backward compatibility.
>
> I know it's the way you used to do it, but for editing templates
> without some custom ST-aware editor, group files grouped in directory
> 'packages' is definitely the preferred way to use directories as a
> complexity management tool.  Simply makes large systems development
> sane, at least in my world.

STv4 treats .stg files as directories of .st files. they are same now.

> The only things missing in ST are multiple imports, and a ClassPath/
> TemplatePath or TEMPLATE_PATH. So we can consider MI as multiple
> "imports", which is really what I am after here: I want to be able
> to do something very similar to Java's package "import" statements,
> where I can 'import' needed ST functionality (groups, or even
> individual templates).

you'll have mult. inher.

Ter