[stringtemplate-interest] getting rid of StringTemplateGroupLoader

[Zenaan Harkness]

On Mon, Nov 09, 2009 at 12:12:31PM -0800, Terence Parr wrote:
> On Nov 8, 2009, at 11:18 PM, Jonathan Buhacoff wrote:

> > 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.
...
> >> 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?
> 
> yep, that's what i meant.

What about template-path concept (like classpath)? If we have a Java-style group
loader, then leading / would mean search from 'root' of current template-path?

No leading / same as above (relative to current template).

Again, advocating to group loader:
At the moment my project has a set of nearly 50 ST groups over 10 directories
("packages") as I call them, and this is set to balloon out 4 or 5 times after
my current system design simplification and expansion.

To have to separate group-hierarchy creation would demand new data declaration
files to declare the group connections, and new code to manually set up these
connections. From my vantage point, that looks like a short term disadvantage
(which is never a problematic cost to me if it means longer term cleanliness),
but more importantly a long term increase in maintenance overhead. Given my
system design and corresponding ST usage pattern that is.

best
zen

-- 
Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.