[stringtemplate-interest] Advice: Avoiding duplication via iterating of list and applying template

[Barrie Treloar]

On Thu, May 26, 2011 at 9:16 AM, Udo Borkowski <ub at abego-software.de> wrote:
> Iteration is one way to do this. However you could also avoid duplication by just using a template with parameters.
>
> E.g.
>
> t(p1, p2, p3, p4, p5, p6, p7) ::= <<
> <p1> | <p2> | <p3> | <p4> | **    ;  handle any hyphens in a unit field ; <p5> - <p6> <p7> **
> <_handleUnitNumbers(unitNumberSupported,["1", "2", "3"])>

I see where you are coming from with this.
I'll think about whether I can use this approach elsewhere.

I'll answer in depth in the next bit.

>>>
>
> And then you call this template with the different arguments:
>
> <t("^", "-", ">", "^", "1", "3EBA", "1")>
> <t("^", "-", ">", ">", "1", "3EBA", "3EBA")>
> <t("^", "-", ">", "L", "1", "3EBA", "LOT")>
> <t("^", "-", ">", "<", "1", "3EBA", "A501")>
> <t(">", "-", "^", "^", "3EBA", "1", "1")>
>
> This makes it more obvious what are the variable and the fixed part.

Well the variable part is the whole string as its the "match pattern"
for my output file.
I like that I can easily read the match pattern in the target language
as its being past in, rather than having to look at the template to
see what it looks like. That may just be my personal bias here.

> Also: currently the variable parts belong to your template definition (as arguments to the template calls). Depending on where you get these values from you may want to consider these "variable values" to be part of the "model". Then you would pass them pass them from the model to the template, e.g. as a list of maps, each map containing the values for "one line". Then you would again use the iteration to process it.

I'm probably not using ST in the conventionally envisioned manner.

My model is very basic, it only defines some variables that help
select which features of the template to enable/disable.

I'm using ST to help me build an ESRI locator pattern file.
The same patterns are used in three different contexts, one for
Address points, and one for Intersections (but you need a left and
right pattern here eg <LEFT> & <RIGHT> (like 5th & Madison)

Its a massive beast of 5k lines, and a lot of it is cut-n-paste, with
no concept of modularisation or re-use (well you only get one level of
sub routine calls)

To help make this understandable I'm using ST to generate it so that I
can get back modularisation.

This is my problem I had with another question I posted, because the
target file looks like:
<match pattern>
<rule>+

And since the model contains no information to help define either the
match pattern or the rules it makes adjusting the contents of the rule
difficult as these are dependent on the match pattern and not from any
direct values from the model.


Thanks for the advice.