lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Calculation summary speed


From: Greg Chicares
Subject: Re: [lmi] Calculation summary speed
Date: Tue, 31 Oct 2006 17:28:26 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

On 2006-10-31 16:57 UTC, Evgeniy Tarassov wrote:
> On 10/31/06, Greg Chicares <address@hidden> wrote:
>> On 2006-10-31 0:15 UTC, Evgeniy Tarassov wrote:
>>
>> I think it would be better to use only columns specified in a new
>> 'calculation_summary_columns' entity in 'configurable_settings.xml'.
>> See:
>>   http://lists.gnu.org/archive/html/lmi/2006-10/msg00064.html
> 
> I'm working on this. It will be done this evening (around
> 20061101T0100Z UTC). The only issue i see that far is the column names
> format. You probably don't want to confuse lmi users by using
> different culmn names in GUI and in configurable_settings.xml.

Exactly. Using different column names would create confusion.

> I guess
> it should be the same list of column names. Please correct me if i am
> mistaken about it.

It should be the same list. You are not mistaken.

> Example (column names are arbitrary):
> 
> <configurable_settings>
>  <!-- column names separated by space or new lines -->
>  <calculation_summary_colums>
>    Outlay AnnGAIntRate_Current TermPurchased_Current
>    COICharge_Guaranteed
>  </calculation_summary_colums>
> </configurable_settings>

Even though those names are ugly, they're what we should use
here, now, for consistency. Later, we can change them. Your
approach is correct: keep them the same now; then we'll
refactor everything that uses them; and then change them
once and only once. That'll be delicate because we need to
preserve backward compatibility. We'll do it later.

> I do remember that you have scheduled to change column names used in
> lmi GUI, to correspond more to the information contained in format.xml
> file.

That adds to the delicacy of any change. If we use wider
names, we may need to widen input fields. That's nothing
we want to do under time pressure, so we'll defer it.




reply via email to

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