[antlr-interest] Organization of complex template structures

Loring Craymer lgcraymer at yahoo.com
Sun Dec 21 22:16:16 PST 2008


Mike--

The key points that drive template organization are probably
1.)  group templates that would be swapped out as a group for retargeting.
2.)  group templates whose evaluation is driven by common control variables used in conditionals.  (for example, templates containing "<if(backtracking)> ... <endif>" should usually be grouped)
3.)  Template evaluation has (or should have) no side effects.  It is perfectly feasible to use multiple StringTemplateGroups in constructing a template instance to be evaluated (containing template instance from one group, arguments from others).
4.)  A StringTemplateGroup can load multiple template groups, so any large group can be split up into several smaller groups and all can be loaded into a single StringTemplateGroup.  [I have not had reason to do this; it seems more common to override some templates in one group with another.]

Having an include mechanism for templates would make sense if StringTemplate were an application rather than a library; Ter designed StringTemplate to work inside a Java controller program, so inclusion capability is folded into the StringTemplateGroupLoader rather than the template language.

As to your examples:  tree structuring would make sense if templates were tightly coupled, but they rarely are; multiple template groups are handled through the Java (or other target) StringTemplateGroup, and that gives considerable flexibility.

--Loring




----- Original Message ----
> From: Mike Pagel <mike at mpagel.de>
> To: antlr-interest at antlr.org
> Sent: Sunday, December 21, 2008 2:05:01 AM
> Subject: Re: [antlr-interest] Organization of complex template structures
> 
> Thanks for your explanation. But even if I set aside the class/method 
> analogy: how would I organize my templates then? From what you wrote I 
> basically see that typically a template calls other templates within the 
> same group. So how can I reuse a template for instance across different 
> projects? Copy and paste it into the other project's template group 
> file? Merge this and the other project's group files?
> 
> You are basically saying that all templates reside in a single group 
> with inheritance being a feature to be used mainly for retargeting, but 
> that's not practical for large scale projects. Other template engines 
> like XPAND (open architectureware), T4 from MS DSL Tools, MD Workbench 
> from Sodius, JET, ... *all* support splitting up your template project 
> into trees of template files that can call each into each other. This 
> way a template that knows how to serialize an attribute to something 
> like "int i" can be used for class attributes as well as for method 
> arguments, without the whole template zoo residing in a single group.
> 
> Another example: if a want to create the three elements of an MVP style 
> application I will create at least three files, one for the business 
> object model, one for the view and one for the presenter. Would I create 
> three different template groups, one for each file? But how do those 
> groups then share common templates? By (single) inheritance? Or would I 
> have to put all templates into a single group? That's gonna be some file!
> 
> Is it really true that ST assumes most of the templates for a given 
> project sit inside a single group?
> 
> Mike
> 
> 
> 
> Loring Craymer schrieb:
> > Your understanding is flawed--template groups are not classes, nor are
> > templates methods.  Treating them as such is likely to cause you
> > grief.  Think rather that template groups are a convenience for
> > argument checking against a template interface.  That way, changing
> > template groups makes it possible to switch from, say, generating Java
> > code to C# just by switching template groups.  Template groups are a
> > mechanism for retargeting.  Switching individual template groups within
> > an application while leaving others unchanged is not a common usage
> > pattern.
> >
> > Instead of thinking of templates as methods, take a
> > simpler view:  arguments fill "holes" in templates and the arguments
> > should be thought of in "instantiated" form.  Thinking of arguments as
> > dynamically invoked methods misses an important level of abstraction: 
> > argument evaluation is independent of template evaluation and is
> > side-effect free.  [It is possible to implement side-effects as the
> > result of evaluation through reflection, but the results are
> > unpredictable.  Do not do this!]
> >
> > It is possible to invoke other
> > templates in the same group from within a template, but you should see
> > this as a macro invocation, and the facility as a convenience to allow
> > factoring.  Almost always, the invoked template is local to the
> > template group (not declared in the interface).  Such invocations tend
> > to be uncommon.
> >
> > --Loring
> >
> >
> >
> >
> > ----- Original Message ----
> >  
> >> From: Mike Pagel 
> >> To: antlr-interest at antlr.org
> >> Sent: Saturday, December 20, 2008 7:45:01 AM
> >> Subject: [antlr-interest] Organization of complex template structures
> >>
> >> Hi there,
> >>
> >> I am wondering how to best go about structuring complex sets of string 
> >> templates. As I understand the current mechanisms, a template group is 
> >> pretty much a class with its templates being the class methods. You can 
> >> build inheritance structures between groups and thereby overriding 
> >> templates (the methods) and call super group (class) templates.
> >>
> >> This allows to build up some structure in terms of reusing basic 
> >> templates and if required specialize certain pieces. But in the end, you 
> >> always call a template (method) that is part of or being inherited by a 
> >> specific leaf template group (class). Once the thread of control is 
> >> within a template group there is no means to call templates in other 
> >> groups, except for the groups which belong to inheritance line of the 
> >> leaf group (if I'm not missing anything).
> >>
> >> So far I find this limiting, e.g. if my model describes (Java) classes 
> >> and I want to generate the class code. Then my leaf template group may 
> >> be a "class.stg" with all kinds of templates like "generateMethods()" 
> >> and "generateAttributes()". The implementation of those template now 
> >> should invoke templates from a group "Methods.stg" and another group 
> >> "Attributes.stg". (This example may not be pressing the issue but it's 
> >> easy to follow.)
> >>
> >> Now I cannot derive "Class.stg" from both other groups, nor can I 
> >> somehow call into these groups (like calling static members functions of 
> >> another class in code). What would be a good way to express this with 
> >> the current mechanisms or is there actually a limitation?
> >>
> >> Thanks a lot,
> >> Mike
> >>
> >> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> >> Unsubscribe: 
> >> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
> >>    
> >
> >
> >
> >      
> >
> > List: http://www.antlr.org/mailman/listinfo/antlr-interest
> > Unsubscribe: 
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
> >  
> 
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: 
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address



      


More information about the antlr-interest mailing list