[stringtemplate-interest] How best to do recursive hetero template calls?

[Gerald Rosenberg]

Just to be clear, the ST enhancement request is to support:

     String[] contents = someTemplate.render();

(or some reasonable equivalent).

A simple use case involves generating a standard class file instead of 
an inner class.  As is, generating an inner class is purely in-line, so 
no problem.  But, to instead generate an "outer" standalone class 
requires the content to be separated somehow.

methodSpec(...) ::= <<

         public void myMethod() {
<a.type> varNameA = new <a.type>();
<outer(a.type, ...) >
<b.type> varNameB = new <b.type>();
<outer(b.type, ...) >
<c.type> varNameC = new <c.type>();
<outer(c.type, ...) >
         }
 >>

The content from each template <outer(a.type, ...) > instance needs to 
be returned in a separate string so it can be saved into its own 
separate file.  Certainly, you could do another walk in the controller 
logic to gather together all of the attributes again and generate each 
outer class in in a separate loop, but that just hurts.  All of the 
necessary attributes are all right there, right now in the template.

So, maybe some syntax like <^outer(...)>  means: push the current 
content array string slot, allocate a new string array slot and generate 
the outer template content into that slot, and pop the array slot at the 
end of the template.

And here is the tie in to the tree walk.  My case is a root container 
that can contain any mix of containers and controls, repeating.  The 
tree walk works perfectly but results in one massive string.  Everything 
would have to be realized using inner classes.  In practice, each 
container needs to be generated to a separate string that could then be 
saved as a separate class file.

Don't think that this would break the functional only requirement of ST.

Best,
Gerald



On 2/19/2010 1:41 PM, Terence Parr wrote:
> Hiya. Can you be more specific? ST converts<list:{...}>  to a list of STs, not a string.
> T
> On Feb 18, 2010, at 9:09 AM, Gerald Rosenberg wrote:
>    
>> While it works well, turns out practical use is somewhat limited in that it renders as just one big blob of code|text.
>>
>> Wonder if any thought has been given to allowing ST to render to a string array, maybe using some template level flag to mark when to switch to generating to a new array slot?  Would add flexibility in the subsequent stitching together of the content.
>>      
>