[stringtemplate-interest] getting rid of StringTemplateGroupLoader

[Zenaan Harkness]

On Mon, Nov 09, 2009 at 03:30:49PM -0800, Terence Parr wrote:
> On Nov 9, 2009, at 3:08 PM, Zenaan Harkness wrote:
>> 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?

Like Java, this would mean search each 'root' provided within the
templatepath (classpath).

>> 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.
>
> Are they organized into a subdir hierarchy? If so, you only need one  
> root group, right?

They are, but that's only because I have not yet released my project
to the wild - when I do, "core" template groups will of necessity be
distinguished from 'custom' groups by being within their own 'local'
hierarchy.

And I am clearly anticipating ceation of 'library' groups as well -
so ultimately a minimum of three separate template group hierarchies
would be regularly used with my system.


>> 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.
>
> are they organized into dir hier.?

Yes.

I can see though, being a new day an all, that except for the
internal inheritance preference (and Multiple Import) features
that I'm desiring:
   -  I'm not currently using group interfaces;
   -  I do currently manually connect relevant "end user level"
      templates to their appropriate models, for view generation;
   -  I can easily see implementing my own 'imports' scheme.

I guess my thought is, that to me these ST-file-level declarations
seem most natural to me in the ST group files, rather than in any
accompanying hierarchy declaration files (such as XML, YAML or
whatever).

And if I need them, and in fact it makes my code simpler and editing
and refactoring easier, then it seems natural to me to think that
others will likewise reap similar advantages with such features.

That's my thought.

Thinking on 'most significant' ST4 features to me:
   -  Whitespace niggling has been most frustrating 'feature';
   -  Multiple group-file-declared imports appears self evidently
      most productivity-increasing ST feature I can imagine
      (given my ST usage patterns).

best
zen

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