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

[Gerald Rosenberg]

On 2/20/2010 11:43 AM, Terence Parr wrote:

Seems I borked the explanation.
> To me,  it's not the job of ST to manage a list of your output templates.
To be clear, the enhancement is to allow a single template invocation to 
output multiple content fragments.  A mark on a template will flag when 
to switch to a new content buffer and the end of that template defines 
the switch back.  The *only* management ST does is to blindly push and 
pop output content buffers based on some static mark.
> There to many kinds of data structures you might want
The specific data structure is really a don't care. Did not intend to 
suggest that it was tied to or needed any particular data structure.
> and I'm not sure introducing new syntax is the right approach. In my tools, I use the same template to generate multiple output files with no problem.
Yes, existing behavior is one content string output per invocation of a 
template. But, like inheritance, it is somewhat of a blunt instrument.

ST supports regions so you can override deep details in a parent 
template.  Well, suppose rather than changing what text is generated 
deep in a template invocation, you just want to capture that bit of text 
as an independent content fragment.  One basic use case is a parent 
template that generates the text that includes an inner class 
definition.  If you can generate the text of the inner class, then you 
have all that you need to generate a stand-alone class right there, 
right then.   *Except* you need to capture the text of that stand-alone 
class in an independent string so you can save it to a separate file.  
Like regions, it is a matter of conceptual clarity and convenience.  
Likely less control code to write and maintain, also.

So, for

/String[] contents = parentTemplate.renders();/

where /parentTempate/ invokes /subTemplateA/ invokes /*^*subTemplateB/ 
invokes /subTemplateC/

/    contents[0]/ is the ordinary generated text of /parentTempate/ and 
/subTemplateA/ as though /subTemplateB/ and /subTemplateC/ where not 
specified.
/contents[1]/ is the generated text of /subTemplateB/ and /subTemplateC/ 
dependent on whatever attributes existed when the instance of 
/subTemplateB/ was first invoked
     ...
/contents[n]/ is the generated text of /subTemplateB/ and /subTemplateC/ 
dependent on whatever attributes existed when the instance of 
/subTemplateB/ was invoked the nth time.

The order of the fragments 1..n really doesn't matter since they are 
independent of one another.  (If knowing which template resulted in 
which content fragment is needed, /renders()/ could instead return an 
ordered map of content fragment/^template name.)

The result is clean, minimal, functional, etc, etc.

Best,
Gerald

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20100220/33734d31/attachment.html