gnc:html-build-acct-tree

Christian Stimming stimming@tuhh.de
Fri, 30 Mar 2001 00:53:57 -0800


-----BEGIN PGP SIGNED MESSAGE-----

On Thursday 29 March 2001 21:38, Robert Graham Merkel wrote:
> It turns out that it would be highly convenient for the balance sheet
> report if gnc:html-build-acct-tree could return a total.  To do so,
> we could either simply get gnc:html-build-account-tree to return a
> pair containing both the table and the total information.

I don't like this idea. The function gnc:html-build-acct-tree should 
return some html stuff, and that's that. If you would additionally like to 
have some balance number, then please use some function that calculates 
total balances, but not the html-build-something function which only 
should deal with html stuff. I would like to maintain a separation of 
tasks as good as possible.

So if you like to get the total balance, then why don't you use e.g. 
gnc:accounts-get-comm-total-assets with the same options you would use for 
gnc:html-build-acct-tree, or you could additionally write a wrapper for 
that. Since the balance calculation is not at all concerned with html 
stuff, it clearly belongs into report-utilities.scm. 

Yes, I know this might involve some duplicated calculation, but I'm more 
concerned of confusing the html and the non-html API here. The real 
performance bottlenecks lie somewhere else and not in the calculation of 
one total balance. (nb: There are tons of duplicate balance calculation in 
html-build-acct-tree anyway, which should be eliminated first [without any 
API change required] before you need to bother about this one.)

> Another possibility I've been kicking around is adding a user-data
> field to the html-table data structure, which we could put the total
> into and whatever needs it could easily extract data from.  

I don't like this either. This would make the html-table not a 
"html-table" but a "some-important-data-table". You can make that but I 
would rather like a pretty clear distinction between real data and the 
html end-product. You can, of course, invent your new data type 
"some-important-data", and provide functions to convert this one into 
html, and ignore gnc:html-build-acct-tree at all.

> Christian, if I'm going to use multiple instances of these kind of
> tables to assemble into a balance sheet, it doesn't look very good if
> I can't line them up.  Obviously, there needs to be some way of
> specifying column widths in the function call.  What do you suggest we
> do about it?

There is no way of lining them up unless the columns are in the *same* 
table. (Maybe you could hack around by adding the html-table-data of the 
one table to the other, but this is *really* a hack). If you use two 
tables one upon the other, I'd suggest to bear with the misalignment. If 
you use two tables side by side, it won't be an issue anymore. You can't 
specify a column width in our current HTML 3.0 which is the only thing 
gtkhtml can display.

> Additionally, the existing exchange-function code uses
> weighted-average prices.  For a balance sheet, I would argue that it is
> more appropriate to use the most current (or closest) prices
> available.  This was my thought initially because of stock prices, but
> I would argue that this would also apply to any foriegn-currency
> holdings also.  What do you think?

Sure, add whatever you like. My weighted average was thought as a very 
first way to calculate the exchange rate, and should just be the first 
thing to get things going. Just add a second way of doing that stuff to 
commodity-utilities.scm (or wherever you like), and ideally you could 
provide an option to let the user choose the preferred way of getting the 
right exchange rates. But this depends on the API the pricedb provides for 
us. Dave just told me rlb is writing more documentation on it, so let's 
see.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)

iQCVAwUBOsRJpWXAi+BfhivFAQENCAQAloteFEKiYqQoyXu5p0W3Q54aMIOct0DJ
Q2cHUP7+6f3Z927UPPpi8hgfA7wtrSgkWGys0a/bABIzsVMlQ6CVDEtlW4W9Amda
eNhetsjKdoG99lFrZ8S4V6gY7W2Sagh6Q6hLSfrJMLk0Y00pr7XPzZp2Clhl6FFe
u+k/Datcblg=
=+8il
-----END PGP SIGNATURE-----