[stringtemplate-interest] getting rid of StringTemplateGroupLoader

[Jonathan Buhacoff]

On Nov 8, 2009, at 5:20 PM, Terence Parr wrote:

> 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).
>

I like this.  It looks like writing alternate loaders will be more  
straightforward this way.


> 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)

Right but it's not confusing because they aren't accessed from the  
same places -- programmers or administrators  set up the inheritance  
chain, and template authors organize their templates into folders.  
Some people wear both hats.

>
> 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?

You mean where you inherit templates :)

The directory structure should be just an organizational tool for  
template authors, and not a system for inheritance.  Inheritance  
should be set up explicitly in java code (which can read it from a  
configuration system).

I propose that "/file1" should NOT be the ancestor of "/path/to/ 
file1" , but simply just another file in some arbitrary directory  
structure.  This is far more powerful than using directories  
implicitly as an inheritance scheme.  And by the way, if someone has  
templates already set up in a directory structure for inheritance they  
could certainly write a group loader that treats a directory structure  
full of templates as an inheritance chain. I'll be glad to help, too.


> 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");

I think it should be a.getInstanceOf("/misc/leftgutter") and  
a.getInstanceOf("/search") , omitting the group "name".  I think the  
only useful place for a group name is in error logs.

If I write STGroup a = new STGroupURL("http://my.server.net/path/to"),  
I wouldn't want to later write a.getInstanceOf("http://my.server.net/path/to/misc/leftgutter 
");  ... I'd want to just write a.getInstanceOf("/misc/leftgutter")  
and not worry about where it's actually coming from.

The loader could be a database loader like STGroup a = new  
STGroupQuery(myDataSource, "SELECT content FROM template WHERE  
filename=?")  where filenames can very well be "paths" like "/misc/ 
leftgutter" or "/search"  (and it cleverly completes relative paths  
based on the complete name of the current template, just like a  
filesystem would).  Again, in this case I would also like to simply  
write a.getInstanceOf("/misc/leftgutter") since "a" is already fully  
configured.

Actually, I also have SMB, FTP/SFTP, and a few others ready to go as  
soon as this API is finalized.

>
> 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.

How about use leading / for looking in the "root" of the current  
group, and use no leading / to indicate relative to the current  
template, wherever it resides in the hierarchy?

so in the file /misc/leftgutter,  if it wants to refer to a  
neighboring template /misc/kingpin it can just say <kingpin()> and  
that would resolve to /misc/kingpin.

>
> 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.

Won't be an issue if the group "name" is not part of the template  
paths as I suggest above. Instead of IllegalArgumentException you'll  
only need to throw FileNotFoundException at the top of the chain.

>
> does any of this make sense? any comments?
>
> Ter
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest