[stringtemplate-interest] getting rid of StringTemplateGroupLoader

[Terence Parr]

A comment on that interface:

/** When group files derive from another group, we have to know how to
  *  load that group and its supergroups.  This interface also knows how
  *  to load interfaces.
  */

Getting closer to a rough draft on ST v4 :) I just finished handling  
of group files and directories of templates. Now I need to tackle  
inheritance and polymorphism. To make inheritance work in the previous  
version we said something like:

group AdminView : GeneralView;

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:

STGroup g = new STGroupDir("GeneralView"); // the default look of the  
website let's say
STGroup a = new STGroupDir("AdminView"); // a specialization of the  
general view for a website
// now make 'a' load files from 'g' that it can't find
a.setSuperGroup(g);
ST st = a.getInstanceOf("x"); // looks in 'a' for x then 'g' if not  
found
String output = st.render();

This will decrease complexity significantly (by removing the entire  
concept of group loader).

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)

That could get really confusing. When I say supergroup, do I mean the  
group that lives above me in the directory structure or do I mean  
where I inherit templates? In the case above, there are two subtrees  
of templates rooted at directories GeneralView and AdminView, let's  
say.  Underneath those root directories I might have lots and lots of  
subdirectories and/or group files. So, I can ask for:

a.getInstanceOf("/AdminView/misc/leftgutter");
a.getInstanceOf("/AdminView/search");

It will look in subdir misc to find leftgutter.st. It will look for  
search.st in root dir AdminView. Notice that now we use '/' on the  
front to mean absolute start from the root. Without the / on the front  
it looks in the surrounding group's directory. If we template x says  
<foo()> ST would look in x's associated directory for foo.

Anyway, what if AdminView doesn't have misc/leftgutter.st? We need to  
look in the supergroup. It will attempt to load file /GeneralView/misc/ 
leftgutter.st. That all make sense to me but I wondered about the  
users. Well, actually, I guess I hide the internal tree of groups from  
the user so maybe it's not a big deal. Perhaps I should throw any  
legal argument exception if someone tries to set the supergroup on a  
non-root group.

does any of this make sense? any comments?

Ter