lmi
[Top][All Lists]
Advanced

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

[lmi] Calculation summary column selections [Was: Calculation summary an


From: Greg Chicares
Subject: [lmi] Calculation summary column selections [Was: Calculation summary and costly IRR calculations]
Date: Fri, 27 Oct 2006 19:40:48 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

On 2006-10-18 15:01 UTC, Greg Chicares wrote:
> On 2006-10-18 14:22 UTC, Evgeniy Tarassov wrote:
>> On 10/18/06, Greg Chicares <address@hidden> wrote:
>>> That brings up another question: how should we express which
>>> columns are to be displayed on the calculation summary? I had
>>> originally thought of using a separate xml file--today's
>>> 'configurable_settings.xml':
>>>   <calculation_summary_columns>
>>>     some_column_name
>>>     some_other_column_name
>>>     ...
>>>   </calculation_summary_columns>
>>> That's very flexible, but requires editing the xml, which may be
>>> more than we want to ask end users to do.
>>>
>>> However, it sounds like you've come up with the idea of using the
>>> supplemental-report column selections for the calculation
>>> summary. That makes it easy for end users to change the
> 
> [My guess was incorrect--you were expressing the selections in
> the xslt file--but perhaps it was a felicitous misunderstanding,
> because this might be a nice feature.]
> 
>>> If that's what you've done already, then let's leave it alone for
>>> now: it might be good enough. We can play with it and see how
>>> suitable it seems.
>> It is the way to go, right? I'll do the modification and test it.
> 
> Sure, as long as it isn't too much trouble.

Evgeniy--First of all, is it premature to comment on the new
xml files you committed today? I'd rather avoid pointing out
things that you're already aware of and working on. (For
example, the supplemental report doesn't seem to appear any
more in Print | Preview, though I haven't looked into it and
this might be a cockpit error.)

I did notice xsl code that I think intends to select columns
for the calculation summary this way:
 - always use a half-dozen hard-coded columns;
 - add any columns selected for the supplemental report.
Actually, we'd rather not hard-code any columns, but instead
make them all configurable.

The original idea above

>>> 'configurable_settings.xml':
>>>   <calculation_summary_columns>
>>>     some_column_name
>>>     some_other_column_name
>>>     ...
>>>   </calculation_summary_columns>

would be perfect except that we don't yet have a GUI for
editing that file. We distribute a default version of that
file, which seems like the best place to represent default
column selections.

As an alternative, we discussed using any columns selected
for a supplemental report. That idea arose by accident, but
it had a certain charm and I didn't want to dismiss it too
quickly. The real advantage is that we already have a GUI
for that. The disadvantage is that the column selections
really should be distinct for the calculation summary and
the supplemental report--so this would be a kludge.

The ideal is to add <calculation_summary_columns> to
'configurable_settings.xml' and provide a GUI so that users
can change the selections as easily as they choose columns
for a supplemental report. But the selections would be made
in different places: column selections are a property of
 - the input file, for a supplemental report; but of
 - the system, for the calculation summary.
I wonder whether wx offers some easy way of adding a GUI
element for that: for instance, does it support comboboxes
in menus? (I should know, but don't.) Ultimately, the best
thing would be a "Properties" dialog for editing all the
'configurable_settings.xml' settings, but that's beyond our
reach for the current task, so I'm wondering whether there's
something we could do quickly and easily for just this one
entity. A menu isn't ideal for choosing perhaps a dozen
items from a list several dozen items long, but maybe you
have a better idea that's really simple.

Above all, we need to get this firmly specified soon: we
can't spend much time implementing alternatives that we
may decide we don't want to use after all.





reply via email to

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