[reportlab-users] Spreadsheet Table

[Robin Becker]

On 23/02/2010 18:37, Tomasz Świderski wrote:

> Andy Robinson wrote:

>> On a separate topic, I bet people will immediately want to use this

>> with various kinds of database query output. What do you think about

>> adding formats to cell styles, so that a column could contain numeric

>> data but still be specified to look like "$1,234.00" in the style?

>>


I would prefer a complete separation of issues here. We already handle various 
alignment issues for string values. I suspect that whatever the abstract value 
of a special type like Formula represents it can also provide a __str__ method 
that results in its correct formatting. At present it is assumed that 
non-flowable cellvalues are strs (and indeed Formula.__call__ seems to assume 
that); It's difficult to see why cell style etc etc are being used in the call 
function. It's clear that these formulas require some extra information to 
evaluate themselves, but that information seems to come from the table instance. 
I know that activerows0 is not currently on the table, but it probably ought to 
be. I think it should be possible to push the logic for creating a string value 
from a formula into drawCell. There logically Formula should be treated as a str 
and the conversion should look like

cellval = cellval(self, colNo, rowNo)

self is the table on which everything required by the formula should be present.

Currently there is a bit of a conundrum present in the spreadsheettable code in 
that it appears as though width and height are obtained prior to drawing the 
formula cells. In my view this cannot in general be true unless these are fixed 
externally. That means effectively automatic widths are probably not going to 
happen in this model.

I don't think it's sufficient to put out an overflow indicator; in a spreadsheet 
that's acceptable, because I can adjust the column width manually. If my gas 
bill total ends up as ***** it's useless. The formatted cell value should not 
care how wide the cell is unless it's able to do something useful with it. 
Currently we just draw the generic strings whatever and let them overflow. Other 
actions are possible ie truncate, raise an error, shrink to fit etc etc.



> It could be implemented as:

>

> 'FORMAT', (sc, sr), (ec, er), callable

>

> where callable will take string as argument and return formated string.

> Callable behavior will be up to users. For example:

>

> def dollar_format(cell_value):

> try:

> return '$ %.2f' % float(cell_value)

> except Exception:

> return cell_value

>

> or

>

> def upper(cell_value):

> return cell_value.upper()


both of these could be added as formatting methods to a particular formula type.

Using the FORMAT approach is useful, but it should apply to all cells. That 
would mean that data could be ints/floats/strings or other types and the Formula 
__call__ would need to return the right thing for its conversion. If that's the 
case then there is little distinction between simple and non-simple cell values; 
the formatting would need to be done early so that we could establish widths etc 
etc etc.


>

> It would complicate col widths calculation a bit but it's doable.

>

> And this don't have to be limited to numeric data - for example format

> callable which capitalize every word etc.

>

> Tomasz Świderski

........
-- 
Robin Becker