Re: [lmi] Variables synthesized in 'pdf_command_wx.cpp'

[Vadim Zeitlin]

On Tue, 5 Feb 2019 16:32:29 +0000 Greg Chicares <address@hidden> wrote:

GC> > [...] Or we could just implement support for
GC> > Mustache lambdas or Handlebars block helpers which both basically allow
GC> > applying arbitrary functions to the variable values and then we could use
GC> > something like {{First(CorpName, 60)}} instead. But this would require
GC> > slightly more effort, of course.
GC> 
GC> That's a really attractive idea. It doesn't have to be done at this moment,
GC> and it'll probably entail a lot of effort.

 It's not so much the effort which is the problem (some will be required,
of course, but this is something that can be done, and fully unit tested,
quite independently of the main lmi code, so I'm rather confident we could
do it), but the philosophy: initially I chose Mustache because its
"logic-less" nature, was appealing in its simplicity. I did have my doubts
about whether it wasn't too simple, but so far I've resisted adding more
complex constructions to it to avoid ending up with XSL-FO 2.0.


GC> But let me make a "wish list":
GC> 
GC> * "{{First(CorpName, 60)}}" as above. Maybe the name should be {{Abbrev}}

 Irrespectively of the function name, there is also the fact that such
function call syntax isn't natural at all for Mustache/Handlebars templates
that we use/emulate. Something like this would be perfectly natural:

        {{#abbrev}}{{CorpName}}{{/abbrev}}

but has 2 problems: first, it's much more verbose (but I think we could
live with this) and second, it doesn't allow specifying the length. The
best compromise I can think of would be

        {{#abbrev 60}}{{CorpName}}{{/abbrev}}

which definitely isn't perfect but doesn't seem too bad and has the nice
property of being composable, e.g. it would naturally support things like

        {{#abbrev 60}}{{#capitalize}}{{CorpName}}{{/capitalize}}{{/abbrev}}

I don't know how often will we need anything like this in practice, but it
seems nice to allow applying these custom functions to anything without
making the parser significantly more complicated than it is now.

 What do you think of using such syntax? One rather serious limitation of
it is that it basically supports only one "generic" argument and the rest
of them, specified inside the block with the function name, must be
literals. Could this limitation be important for us?


GC> * {{IfNonempty}}, so that where we have something like this:
GC>   {{#HasWP}}
GC>     <p>The Waiver of Monthly Charges Rider provides for waiver
GC>     of monthly charges in the event of [...] </p>
GC>   {{/HasWP}}
GC> we could move the text into a '.product' file, then print it iff it's
GC> not null. (AIUI, perhaps incorrectly, MST expands an empty string to
GC> some kind of whitespace.)

 Sorry, I'm not sure what exactly would you like to do here, probably
because I don't see any real problem in the example above?


GC> * Some kind of if...elif...else; IIRC, handlebars has that already.

 Yes, see https://handlebarsjs.com/builtin_helpers.html and we could
implement support for this, of course, but it does add quite a lot of
complexity (suddenly you need to worry about unbalanced and nested ifs
etc).


GC> * Simple arithmetic, e.g. {{Add(MecYear), 1}} instead of defining an
GC> auxiliary variable {{MecYearPlus1}}. Even an {Origin1} function that
GC> returns one plus its argument would be useful.

 This could be handled similarly to "abbrev" above, i.e.

        {{#add 1}}{{MecYear}}{{/add}}

 Again, this is not nearly as terse as I'd like it and here there are even
less justifications for doing it like this rather than just

        {{add 1 MecYear}}

but for consistency/future extensibility reasons I'd still prefer the
version above.


 To summarize, I think we have 2 practical choices for the custom functions
in the templates:

1. The one proposed above, with only one arbitrary argument, passing
   through expansion, and any number (maybe 0) of literal arguments.

2. The one you had in mind originally, with any number of arguments with
   each of them being either just a simple variable name or a literal.

and a less practical but still implementable, if we need it, choice of

3. Completely general approach with any number of arguments of any kind,
   e.g. "{{abbrev 60 {{capitalize {{CorpName}}}}}}" should work (I don't
   think we can omit the interior braces here).

 I don't like (3) much, but it could still be done. The reason for
preferring (1) is that it seems more inline with the logic-ness of this
template system and it intuitively seems better suited -- but I realize
that saying that something is "intuitively clear" is just another way of
saying that I don't have any real arguments in favour of this approach.

 Please let me know if you have any preferences here,
VZ