[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