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

[Greg Chicares]

[The mailserver in Wendy's office is not working well these days,
so I'll try to answer one or two questions myself. If you could
cc her '.com' address in any reply to her (not <address@hidden>
as on the original email quoted below--that's not her office),
though, then apparently she'll receive it much faster.]

On 2006-11-7 16:19 UTC, Evgeniy Tarassov wrote:
> On 11/7/06, Wendy Boutin <address@hidden> wrote:
>> * Scalar data formatting tags
>>
>> I'm still not sure I completely understands where this stands.
>> Are right- and left-justified tags available for the scalar
>> data in the headers?
[...]
> If you mean the data in the table with vector values

No--the data with scalar values, shown above the html table.

> If you mean the scalar data which is located above the table (example):
>    Male, Nontobacco, age 45
>    23,844.41 guaranteed premium

Yes. I think what Wendy has in mind is not this:

>    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

(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.

>> * Configuring 'install' for new *.xml, *.xsd, and *.xsl
>>
>> Greg and I use this command to run 'lmi':
>>   c:/opt/lmi/bin[3]$./lmi_wx_shared.exe --ash_nazg --data_path=../data

Indeed we do; yet I have long thought that the relative path
  --data_path=../data
is a poor practice and that your suggestion
> - configurable_settings.xml in Greg's directory (c:/opt/lmi/data):
or something like that would be better. I guess it ought to be in
'configurable_settings.xml'. However, it's not; it's governed by
'global_settings.?pp' and mediated by 'data_directory.?pp'. This is
a throwback to the bad old days when msw application data customarily
went in the msw 'system' directory; today, it looks in $(pwd) instead,
but we've never taken the time to rework it thoughtfully, and this
isn't the best time to do that.

> Now i do realize that if the xslt_directory is not specified or empty
> then it is treated as a relative path, but the problem is that this
> path is relative to the executable (current directory) and not to the
> configurable_settings.xml.

IIRC, it's actually the current $(pwd), which can change while the
program is running, under msw at least; but one of the C++ files
mentioned above is supposed to save the original directory at
startup.

> To workaround it you could specify an absolute path in your
> configurable_settings.xml. Like so:
> - configurable_settings.xml in Greg's directory (c:/opt/lmi/data):
> <configurable_settings>
>  <xslt_directory>c:/opt/lmi/data</xslt_directory>
> </configurable_settings>

Wendy, does that work for you, and would it work for end users?
Or do they have data files in the same directory as the program?

> Do you think we want to treat relative paths as relative to:
> 1) the real configurable_settings.xml path

I don't think so. End users are probably accustomed to having the
application and all its files in one directory.

> 2) data directory

That sounds best, at least until we have time to rethink this whole
matter. Then the rule would be:
  "Place '*.xsl *.xsd *.xml' in the same place as '*.xrc'."
Maybe that's a poorer design than what you've already done, but
it would have the virtue of consistency. Then, after this release,
we can implement a better design consistently.

Some output gets written wherever $(pwd) points, and users have
asked for all output to be placed in one location. That's a good
idea for us to implement later.