Re: [lmi] Example of using the current PDF generation approach

[Greg Chicares]

On 2017-07-22 21:37, Vadim Zeitlin wrote:
> 
>  Sorry for yet another delay, I still haven't managed to make the code
> using the external templates approach to work, so for now I'd like to at
> least show to you how does the current code work, so that you could ask any
> questions you might have about it while I continue working on the
> alternative version.

[Just to fill in the background: off the list, we had been discussing two
different approaches. The first is demonstrated here, and an example of
the second is to follow.]

>  So here is a simple but representative example: consider the "Column
> Headings and Key Terms Used in This Illustration" page. Here is the
> (condensed for clarity, all ellipses are actually present in the real code)
> code generating it currently:

This is all very clear to me. Having recently worked on the XSL original,
I am struck by the simplicity of this replacement. For example, this:

>             ("{{AvName}} Value:"
>             ,R"(
> The accumulation at interest of the net premiums paid,
> {{^SinglePremium}}
> less any withdrawals,
> {{/SinglePremium}}
> less any monthly charges deducted.
> )"

corresponds to lines 670-679 of 'illustration_reg.xsl' in HEAD:

            <fo:block>
              <fo:inline font-weight="bold">
                <xsl:value-of select="$scalars/AvName"/> Value:
              </fo:inline>
              The accumulation at interest of the net premiums paid,
              <xsl:if test="$SinglePremium!='1'">
                less any withdrawals,
              </xsl:if>
              less any monthly charges deducted.
            </fo:block>

Considering just these two isolated constructs:

  New: {{AvName}} Value:"
  Old: <xsl:value-of select="$scalars/AvName"/> Value:

  New: {{^SinglePremium}}
  Old: <xsl:if test="$SinglePremium!='1'">

the "new" syntax is plainly preferable to the "old", much as *nix shell scripts
are preferable to OS/360 JCL.

Now, of course, no matter how accurate your translation, without expertise in
the problem domain you can't be expected to know whether this footnote actually
makes sense. In this case, it seems that the original is semantically dubious
(although that was masked by the thicket of XSL constructs): {{SinglePremium}} 
has
been used where {{WithdrawalsForbidden}} is apparently meant, probably because 
it
just so happens that those conditions have the same truth value within the 
finite
universe of products that have been implemented on lmi. (Or they once had the
same truth value, and have since diverged, exposing a latent error that cannot 
be
discerned without great effort.) Of course, without knowing what the technical 
life-
insurance jargon terms mean, you can't possibly tell which conditionals are 
sensible
and which are not, so this is in no way a criticism of anything you've done.

>             if(!interpolate_html.test_variable("GroupExperienceRating"))
>                 {
>                 terms_html += add_term_paragraph
>                     ("Death Benefit Option 2:"
>                     ,"..."
>                     );

Here, again, translation to a comprehensible syntax reveals that the notions
"allow group experience rating" and "allow option 2" have been conflated in
the original. This is why I had initially suggested that you ignore all XSL
conditionals, in effect presuming them all to be nonsensical. But if they're
easy enough for you to translate from one syntax to another, then with the new
human-readable syntax Kim and I can more readily rewrite the ones that actually
don't make sense, and that should turn out to be a shorter path to successful
completion of the PDF-replacement task.

>  I also hope that the code is sufficiently clear. Of course, it uses plenty
> of things not defined in it, like "html::tag" namespace helpers (there is a
> "using namespace html" directive in scope here) and "html_interpolator"
> class (which is 99%-based on the old ledger_xml_io.cpp code, except that it
> now expands {{Variables}} in the text passed to it instead of stashing the
> values of all these variables in an XML file from which they're later
> retrieved by XSLT). But, again, hopefully it's straightforward enough to be
> understandable.

It is straightforward and understandable.

By saying "the old ledger_xml_io.cpp code", do you imply that that source
file will be completely replaced? That would indeed be good news. It was
born in a parlous state and has only grown uglier over time.

>  I'll end this email here to not mix everything together and will second
> another email with the discussion of the (not implemented yet) approach
> based on external templates soon. Please let me know if you have any
> questions about this approach or would like me to provide more details
> about anything in this thread.

I have only one question. The first conditional block quoted above uses
the "ctemplate" or "mustache" syntax:

> {{^SinglePremium}} less any withdrawals, {{/SinglePremium}}

while the second uses a C construct:

> if(!interpolate_html.test_variable("GroupExperienceRating"))

Would the "external templates" approach push more C conditionals (like
this one) into the "mustache" syntax (which would seem desirable)?