Re: [lmi] Group premium quotes

[Vadim Zeitlin]

On Sun, 21 Jun 2015 17:05:51 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2015-06-19 23:30, Greg Chicares wrote:
GC> > On 2015-06-19 14:20, Vadim Zeitlin wrote:
GC> >> On Wed, 17 Jun 2015 15:24:52 +0000 Greg Chicares <address@hidden> wrote:
GC> 
GC> Should we use the existing class Ledger, with its somewhat "stringly"
GC> interface, or create something new?

 I agree that your arguments for reusing the existing "Ledger" class sound
convincing. The fact that it contains all the data, including plenty of
things that the PDF code doesn't need, could be construed as a disadvantage
but it's a minor one at most, and it could only be seen as an advantage
because it will allow to easily add more fields to the premiums summary in
the future.

 However I still have some questions/uncertainties about using it, please
see below.

GC> >>  As for the "two pieces" part, for me this is more of an advantage than
GC> >> anything else as it would make each of them simpler and, for the PDF one,
GC> >> easier to test.
GC> > 
GC> > Very good point. The easiest way to regression-test the data that a
GC> > PDF contains is to dump the data as flat text, and test that.
GC> 
GC> We already have regression tests for class Ledger.

 But what about the PDF testing? There doesn't seem to be any way to create
a (dummy) Ledger for testing purposes, or am I missing some way to do it?

GC> Members of class Ledger and its HAS-A subordinates aren't quite "stringly".
GC> However, Ledger::write(xml::element&) creates an inherently "stringly"
GC> xml object.

 This is my second question: will the PDF code be supposed to work with XML?
I'd really like to avoid this if possible and it seems like it ought to be,
with value_str() method, but you keep mentioning XML in your email which is
making me nervous, so I'd appreciate if you could please confirm that XML
names are used for illustrative purposes only and you don't propose to
create the XML document from the ledger and use it to produce the PDF.

 The third potential problem is more nebulous, but it's the one that
worries me the most: Ledger classes are relatively complex, I've never
worked with them before and looking at them right now I have to admit that
I'm a bit lost. I hope I can find my way in them quickly, but there is
still a risk of misunderstanding something and making some stupid mistake.
These classes also seem to be pretty central to lmi, so modifying them is
probably out of question and if I run into any problems (e.g. performance,
although I still think it's unlikely) I wouldn't have much latitude in
solving them, compared to using an ad hoc intermediate struct discussed
before which would have been simple and easily modifiable/optimizable if
needed.


GC> I'm starting to see this as a generalized "roster" facility. The existing
GC> group roster is one flavor; premium quotes are another; and the inforce
GC> bill that I see on the horizon is a third.

 I have no idea what the inforce bill is, but even I can see that the
existing roster.tsv output is indeed pretty similar to the PDF summary we
want to add.

GC> - GUI: The existing "Print roster to spreadsheet" command could become
GC>   "Print roster..." with a submenu, with its toolbar button perhaps
GC>   becoming a combobox (which I suppose wx can put in a toolbar).

 (it can put a button with a drop down menu, which is the more standard UI
for this kind of things)

GC> - Calling code: we could either expand enum mcenum_emission (which has
GC>   thirteen enumerators now, and I guess we can portably have thirty-two
GC>   total, being log2(1.0+ULONG_MAX), which should suffice for another
GC>   decade or so; or add an argument:
GC> 
GC> double emit_ledger
GC>     (fs::path const& filepath
GC>     ,fs::path const& tsv_filepath
GC>     ,Ledger const&   ledger
GC>     ,mcenum_emission emission
GC> +   ,mcenum_roster_t roster_type
GC>     )
GC> ...
GC>     if(emission & mce_emit_spreadsheet)
GC>         {
GC> +       if(enumerator_for_original_roster == roster_type) {
GC>         LMI_ASSERT(!tsv_filepath.empty());
GC>         PrintCellTabDelimited
GC>             (ledger
GC>             ,   tsv_filepath.string()
GC>             +   
configurable_settings::instance().spreadsheet_file_extension()
GC>             );
GC> +       } else if ... [a 'case' statement would seem better]
GC>         }

 I really don't know if it's more logical to think of the new feature as
another roster type or as a new emission. For me it seems to rather be the
latter (i.e. I'd prefer to extend mcenum_emission) but, as I keep repeating
since the beginning of this discussion, I am absolutely not sure about it.

GC> >>  What do you think?
GC> 
GC> Right back atcha!

 Well, it seems clear that we will be using Ledger for this. I'll have to
spend some time to understand how to create Ledger with the test data first
and then how to get the data back from it. If you have any words of wisdom
on either or both of these topics, they would be gratefully received, but
if not I can at least try to learn this on my own during the next couple of
days.

 Regards,
VZ