lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Calculation summary: tidying up loose ends


From: Evgeniy Tarassov
Subject: Re: [lmi] Calculation summary: tidying up loose ends
Date: Wed, 8 Nov 2006 03:10:28 +0100

On 11/7/06, Boutin, Wendy <address@hidden> wrote:
Greg Chicares wrote:
> On 2006-11-7 16:19 UTC, Evgeniy Tarassov wrote:
> >    0         initial term specified amount
> >    1,000,000 initial total specified amount
> >    CT        state of jurisdiction
> [versus]
> >            0 initial term specified amount
> >    1,000,000 initial total specified amount
> >           CT state of jurisdiction

If I had to pick one, I'd pick the second, but given
the time we have left I don't want to expand our scope
when I see what follows as the real issue.

No-no, its not difficult at all. I have added it to the calculation
summary (html output).

> (though that's a good question, which I'll leave to Wendy),
> but rather something like this:
>
>   ------------------left------------------      -----------right------------
>           0 initial term specified amount      Male, Nontobacco, age 45
>   1,000,000 initial total specified amount     23,844.41 guaranteed premium
>          CT state of jurisdiction
>
> so that the same amount of information takes about half as much
> vertical space.

Yes, this is exactly what I mean. Most importantly, I want
Greg's demonstrated '---left---' and '---right---' buckets
for any scalar values above the html table. That achieves
the immediate goal of minimizing vertical space. And if it's
just as easy to assign left- or right-justified attributes
to each individual scalar value, then I'd like that too,
although, that's like "prettying it up", so I don't see it
as necessary as saving the vertical space.

Added to 'html.xsl' too. The dark side is that it's not as easy as to
assign "left" or "right" value to some attribute in the html.xsl file.
If one day we do implement scalar values selection, then probably the
xslt code generating that list will become generic and will probably
allow such a feature driven only by some attribute specified in
configurable_settings.xml or through GUI by user.

now this feature could be implemented (easilly, not taking much time) this way:
[simplified]
<table>
<td><!-- LEFT BUCKET -->
<xsl:value-of select="address@hidden'InitSevenPayPrem']"/>
initial seven-pay premium<br/>

<xsl:value-of select="address@hidden'InitBaseSpecAmt']"/>
initial base specified amount<br/>
[...]

<td><!-- RIGHT BUCKET -->
<xsl:value-of select="address@hidden'Gender']"/>,
<xsl:value-of select="address@hidden'Smoker']"/>,
age <xsl:value-of select="address@hidden'Age']"/><br />
[...]

</table>

Which means that to reorganise scalar values in the buckets will be as
easy/hard as moving around blocks from one bucket section to another,
where blocks correspond to scalar value and its label text.


Do this features need to be implemented for TSV output for calculation
summary as well?
I can say that pretiffying TSV data will be much more painfull on the
level of xslt code. It will be impossible to separate bucket scalars
in the code and columns will have to be interchanged which will make
the xslt much less readable.

On the other side, if we dont change TSV xsl template, then the data
will correspond to the calculation summary as it is now, except the
visual formatting. Do you think it is acceptable for users to have the
calculation summary scalars being copied as TSV into clipboard to
'move around' on the screen? :)




reply via email to

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