Re: [lmi] Error message in do_interpolate_string_in_context()

[Vadim Zeitlin]

On Tue, 13 Feb 2018 22:30:56 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-02-13 22:18, Greg Chicares wrote:
GC> > [Vadim--I think I've fixed this, but please take a look at SHA1 124129467]

[I will do it, but not right now as I'm trying to fix the _M_range_check
 error, but gdb isn't cooperating, so it is taking longer than I'd like]

GC> > When running inforce illustrations, Kim sees this message:
GC> >   Invalid value '3' of section 'InforceYear' at position 3226, only 
GC> >   "0" or "1" allowed
GC> 
GC> Vadim--Why is it that only boolean values are allowed?

 This is an intentional sanity check.

GC> According to:
GC> 
GC>   https://mustache.github.io/mustache.5.html
GC> | If the person key exists and has a non-false value, the HTML between
GC> | the pound and slash will be rendered and displayed one or more times.
GC> 
GC> ...I would have guessed that '3' would be a non-false value.
GC> However, AIUI, we're using our own mustache implementation instead of
GC> someone else's library, and if so...
GC> 
GC>  - Was it our intention to constrain "section" values to boolean,

 Yes as I was far from certain that always handling non-zero numbers or
non-empty strings as true was the right thing to do, so I preferred to err
on the side of caution.

GC>    or should we expect '3' to be converted to "non-false", i.e., '1'?
GC>    (If so, the I think we should revert my commit 124129467 and
GC>    change our MST implementation.)

 We could change it easily, but I'm still not sure if it's not going to
result in some grief later.

GC>  - Might we want to support a "handlebars" alternative like
GC>      {{#if condition}}
GC>          one thing
GC>      {{else}}
GC>          another thing
GC>      {{/if}}
GC>    because it's a bit easier to read?

 This would definitely be nice, but is much less simple to implement
because we need a parser for conditions. I do think this would be worth
doing, e.g. to avoid having to define variables such as InforceYearLE4 in
the code, but I didn't think it was useful enough to spend significant time
on this before finishing the rest of the new PDF generation. I'll let you
be the judge of whether the time to do this has come now or not yet.

 Regards,
VZ