Re: [lmi] Group premium quotes

[Vadim Zeitlin]

On Mon, 22 Jun 2015 01:34:50 +0000 Greg Chicares <address@hidden> wrote:

GC> It might help you to think in terms of the (simply flattened) xml output,
GC> even if you actually use the (structured) class Ledger. You can create a
GC> specimen like this:

 Thank you for the instructions, looking at the produced XML file indeed
gives a good overview of the data.

GC> You don't need to understand why 'SpecAmt' is "invariant"

(that's a relief because I don't)

GC> We're creating a report with rows consisting of
GC>   name, age, DOB, salary, "SpecAmt", and a few premiums
GC> along with some headers. We'll probably want to dump the data as flat text
GC> just for regression testing (because most of these premiums are used nowhere
GC> else). I suppose we'll judge whether the PDF corresponds to the flat text by
GC> code review and by visual inspection of some samples--there's little chance
GC> any problem will sneak past us, and PDFs are hard to test automatically.

 I was thinking to use diff-pdf tool that Vaclav wrote some time ago to
help with this. But it could probably be integrated as some kind of post
build step instead...

GC> > There doesn't seem to be any way to create
GC> > a (dummy) Ledger for testing purposes, or am I missing some way to do it?
GC> 
GC> I don't quite understand.

 I meant to create a Ledger filled with some known dummy values just to be
able to generate a fixed PDF.

GC> >  The third potential problem is more nebulous, but it's the one that
GC> > worries me the most: Ledger classes are relatively complex, I've never
GC> > worked with them before and looking at them right now I have to admit that
GC> > I'm a bit lost. I hope I can find my way in them quickly, but there is
GC> > still a risk of misunderstanding something and making some stupid mistake.
GC> 
GC> I'll be your safari guide, so no hippopotamus will become your sarcophagus.

 I am afraid the only way I could reply to this would somehow involve the
word Prius and so it's probably better for me to abstain...

GC> If you like, you can use an ad hoc intermediate struct internal to the
GC> "premium quotes" code. For example: as the Ledger objects drift by
GC> (driven by a chain of events you can trace from CensusView::DoAllCells()
GC> into as much depth as you please), grab the tiny subset you need, and
GC> store it in your local data structure, then use that subset to create
GC> the PDF. That would be more economical of RAM than holding all the
GC> Ledger objects for potentially thousands of rows.

 OK, thanks, I'll think about it. Of course, if I can just use a Ledger
already existing somewhere else, I'll try to do this instead.

GC> > GC> - GUI: The existing "Print roster to spreadsheet" command could become
GC> > GC>   "Print roster..." with a submenu, with its toolbar button perhaps
GC> > GC>   becoming a combobox (which I suppose wx can put in a toolbar).
GC> > 
GC> >  (it can put a button with a drop down menu, which is the more standard UI
GC> > for this kind of things)
GC> 
GC> Good. Then it'll be like this:
GC>   http://virt-tools.org/learning/start-vm-with-virt-manager/force-off.png

 Yes, this is literally the very same widget that wxGTK uses for
implementing drop down toolbar buttons and it looks pretty similar under
MSW too.

GC> I'm not sure, either. Let me say this, though: we might want to "emit"
GC> more than one "emission" in a single pass through the code, though I'm
GC> not sure we've ever done that; but we really won't need to emit more
GC> than one "roster type": IOW, the toolbar-button-with-dropdown-menu
GC> has a single-choice menu only. That seems to argue for a separate
GC> roster-type argument.

 Yes...

GC> Let me suggest:
GC> 
GC>     if(emission & mce_emit_group_roster)
GC>         {
GC>         LMI_ASSERT(!tsv_filepath.empty());
GC>         PrintRosterTabDelimited
GC>             (ledger
GC>             ,   tsv_filepath.string()
GC>             +   ".roster"
GC>             +   
configurable_settings::instance().spreadsheet_file_extension()
GC>             );
GC>         if(contains(ledger.GetLedgerInvariant()..value_str("Comments"), 
"TeStInG"))
GC>             WritePremiumQuotePdfFile();
GC>         }
GC> 
GC> That trick makes it easy to postpone the decision. (Every PDF contains that
GC> WeIrD sTrInG during development only, but that's all right.)

 OK.

GC> > GC> >>  What do you think?
GC> > GC> 
GC> > GC> Right back atcha!
GC> > 
GC> >  Well, it seems clear that we will be using Ledger for this. I'll have to
GC> > spend some time to understand how to create Ledger with the test data 
first
GC> 
GC> We'll use CensusView::DoAllCells() in production. For isolated, lightweight
GC> testing during development, just clone that small function, not worrying
GC> about the effect of user cancellation. The svn repository contains a
GC> 'sample.cns' that is probably good enough to start testing.
GC> 
GC> > and then how to get the data back from it. If you have any words of wisdom
GC> > on either or both of these topics, they would be gratefully received, but
GC> > if not I can at least try to learn this on my own during the next couple 
of
GC> > days.
GC> 
GC> I hope the blazes and cairns I've laid above show the trail well enough,
GC> but let me know if you want more detail.

 No, it's enough for now, thanks. I really have to start writing some code
(or, rather, start by writing some makefiles to build wxPdfDoc with lmi...)
and doing something which will probably result in more questions, but not
immediately.

 Thanks again,
VZ