lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Group premium quotes


From: Vadim Zeitlin
Subject: Re: [lmi] Group premium quotes
Date: Fri, 19 Jun 2015 16:20:33 +0200

On Wed, 17 Jun 2015 15:24:52 +0000 Greg Chicares <address@hidden> wrote:

GC> Right now, the main question from my POV at least is how to pass data
GC> from lmi to the code that write the PDF file.
GC> 
GC>  - I could pass a struct. Then the code will look like different parts were
GC>    written by different people.

 I'm not sure why should it necessarily imply this. The code would look
like it consists of two isolated pieces, yes, but provided they're
written in the same consistent manner (and I think I'm getting better
here...), it shouldn't be possible to say which piece was written by whom.

 As for the "two pieces" part, for me this is more of an advantage than
anything else as it would make each of them simpler and, for the PDF one,
easier to test. The main drawback I see with this approach is that it
requires to decide in advance which data is passed from the GUI code to the
PDF generation function and that if we decide wrongly, we would need to
update the interface to allow passing more data.

 This could be mitigated by using "generic" data structures such as passing
the entire product_data (with all of its keys) and a self-describing 2D
array for the premiums (i.e. an array containing information about its
columns) and if we foresee the need for the information in the generated
PDF to vary, then this would probably the best thing to do. But if we need
to generate just the kind of summaries discussed so far, it would, IMHO, be
better to avoid such broad stringly type interface and use a concrete
struct.

 BTW, a somewhat related question: will the totals (for each column) be
computed by lmi or PDF generation code? Computing the sum is not a
difficult operation, as maths go, so I guess the PDF code could be trusted
with it, or do you still see it as too risky?

GC>  - The PDF code could call back into lmi for each datum where it's needed.
GC>    That would probably work well for footnotes:
GC>      product_data const& p = [whatever];
GC>      std::string const marketing_name_footnote = 
p.datum("MarketingNameFootnote");
GC>      [then use that string in the PDF code]
GC>    But it might not work so well for premiums. We certainly want to keep the
GC>    premium-calculation details encapsulated, as the PDF code has no need to
GC>    see how those calculations are performed. Maybe we need to create a
GC>    quote_premiums object and pass that to the PDF code.

 The trouble is that I don't know where do these premiums live right now.
Are they already available in some existing data structure?

 If not, then I think we do need some object which would be part of the
bigger struct describing the entire group premium document to generate.
I.e. I see something like this, in pseudo-C++:

        struct premium_document_description
        {
            string
                ,header_text
                ,header_image_file
                ,footer_text
                ,company
                ,prepared_by
                ,summary_data
                ;

            struct participant
            {
                string name;
                int age;
                double
                    ,income
                    ,face_amount
                    ,premium
                    ,premium_with_waiver
                    ,premium_with_adb
                    ,premium_with_waiver_and_adb
                    ;
            };

            vector<participant> participants;
        };

And then

        void create_premium_summary_pdf
            (string const& file_name
            ,premium_document_description const& data
            );

 What do you think?
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]