-----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-----
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
